Still having XMPCR problems

**rjoek** · 09-10-2005, 12:32 PM

Guino: thanks for taking a crack at fixing the XMPCR resume issues in your latest release. I am still having problems. Since I'm assuming you have tested 09-09-05 with the XMPCR I sent you, I would guess my problems are related to the fact that I have my XMPCR connected through a hub (also assuming you did not do the same when you tested it).
It's hard describe the problem, as it is very erratic. But the worst of it is if I tune a station for the very first time (with XMPCR mode checked in the config utility) it works. When I try to suspend while tuned to a channel, it doesn't come back. But, whereas with previous releases I could then exit and re-enter the XM screen to get it to tune no problem, now when it comes out of standby it does not tune at all. Ever again. The only way I was able to get it to tune again was to change the config to uncheck the XMPCR mode box. Then it will tune, and will operate as before when coming out of suspend (doesn't re-tune automatically but will do so if I re-enter XM mode).
Hope this makes sense, as I said it's hard to describe. Any idea what's going on? As I have said before, FrodoPlayer does not have these problems. I guess I'll just have to go back to using FrodoPlayer, as much as I like RR.

**guino** · 09-10-2005, 01:21 PM

I'll make some more tests as soon as I have some time, but have you tried to plug it in directly onto a USB port to see if it works with the hibernate ? Honestly the way I tested was: Press hibernate while on XM, unpluged the USB cable while hibernated, resumed from hibernation, then pluggged the USB cable again and from what I could tell, it re-connected fine.

**guino** · 09-10-2005, 02:18 PM

Please give it a try on the "patch" I posted today.. I added something else for the XMPCR startup...

**rjoek** · 09-10-2005, 05:11 PM

OK, tried your 'patch'. Exact same behavior. May I ask what you changed from 8-30-05 to 9-9-05, and then from yesterday to today? Your testing method seems reasonable, but of course not practical in a real life application. No one would ever disconnect their XMPCR cable every time they shut off their car.
I could see how having mine connected through a hub would make a difference but I will need to pull my PC out of the car to test the direct connection. I'm not going to do this anytime soon as I'm about to leave for a long trip. But when I get back I'll give it a try.
Is what you changed recently equivalent to exiting the XM screen and then re-entering it? Because that works on resume with an XMPCR. I have gone back to using the 'XMD mode' setting and that is satisfactory.
Let me know if I can do any more testing for you.

**rjoek** · 09-10-2005, 05:16 PM

Originally Posted by guino

I'll make some more tests as soon as I have some time, but have you tried to plug it in directly onto a USB port to see if it works with the hibernate ? Honestly the way I tested was: Press hibernate while on XM, unpluged the USB cable while hibernated, resumed from hibernation, then pluggged the USB cable again and from what I could tell, it re-connected fine.

Ah: another difference I didn't try. When I turn my car off my Opus puts my machine in standby (via TTL to power button). This is different from the way you test. I'll try having RR tell the machine to standby instead and see if it works. I know for a fact that USB resume behavior is different for the two different standby methods above, as I have noticed this when using 'Scheduled Task' to perform unattended updates without turning the ACC on (bypassing Opus start up, instead having the PC issue the startup request).

**rjoek** · 09-10-2005, 05:34 PM

Never mind. Treid this, still same behavior. For your testing in the future though I think it would make the most sense to do the equivalent of pressing the power button on your computer (what the Opus does), which in turn tells XP to enter S1 (or S3, whatever) state. This will be most accurate to how most people have their systems configured, I would guess.
Sound right?

**guino** · 09-10-2005, 09:22 PM

When you hibernate/standby windows basically DISCONNECTS all USB devices and then assumes that whatever is plugged in the USB has just been reconnected -- this varies with the driver, but for the XMPCR this is exactly how it goes.. that's why I test it by unplugging/re-plugging the cable..

**gork** · 09-11-2005, 12:01 AM

Originally Posted by guino

When you hibernate/standby windows basically DISCONNECTS all USB devices and then assumes that whatever is plugged in the USB has just been reconnected -- this varies with the driver, but for the XMPCR this is exactly how it goes.. that's why I test it by unplugging/re-plugging the cable..

While this seems like the case, many machines do not power off the USB ports, so the XMPCR stays on and active. You can't guarantee the state it will be in on a resume from hibernate or suspend, and the USB/serial drivers are poorly written from this standpoint also. Frodo at one point a couple years ago posted some updated FTDI drivers that seemed to help the issue, but not entirely.

I worked around the issue of my USB ports staying powered when the machine was off by putting a relay on the 5V line to the ports. Now my USB ports turn off whenever the machine hibernates or shuts down. This is the same as essentially unplugging my device every time the machine is in hibernate or suspend BUT with one critical difference; the USB port is plugged back in *before* the machine resumes. This will result in a different behavior than plugging the USB device in after windows has come back up from resume.

I see absolutely no way to properly test this behavior without actually having a real XMPCR unit. RR has never once worked properly for me with hibernate and an XMPCR and I have tried everything. The best I can get from it is the behavior where when I resume, I have to go back into the main menu and then back into the XM radio to get the audio going again. (This is with a very old build of RR by the way) But even with this behavior the computer will sometimes hard lock. I'm pretty sure it's due to the behavior of the comm port driver (which is the FTDI USB serial device driver in this case)

RR doesn't work with the XMPCR and hibernate currently even in the current build and moreover causes (at least on my machine) hardware freezes occasionally when attempting to talk to a com port. While this freeze issue is most likely a FTDI driver bug, all I know is that Frodo's XM program will work great with standby and RR will not. And I am pretty sure we won't see an updated or fixed FTDI driver any time soon. RR may work fine with an XMDirect on a USB/Serial interface but it's a whole other ball game there!

**rjoek** · 09-11-2005, 11:40 AM

Well, now he actually has an XMPCR. I sent him one. Thanks for the backup, Gork.
Guino, dude, I'm just trying to help you. It seems most logical to test an application IN EXACTLY THE SAME WAY as it is used. Your coding capabilities are obviously far superior to mine. But I don't think you're going to solve this problem unless you reproduce how an XMPCR would be used in a real environment.

**rjoek** · 09-11-2005, 11:44 AM

Originally Posted by gork

I worked around the issue of my USB ports staying powered when the machine was off by putting a relay on the 5V line to the ports. Now my USB ports turn off whenever the machine hibernates or shuts down. This is the same as essentially unplugging my device every time the machine is in hibernate or suspend BUT with one critical difference; the USB port is plugged back in *before* the machine resumes. This will result in a different behavior than plugging the USB device in after windows has come back up from resume.

Oh -- and that's the reason why I use a (powered) USB hub. I got the idea from the thread that Gork started, that he refers to above. It also allows me to cut power to non critical USB devices so I can leave my machine in S1/S3 for days (perhaps much longer, I've never really had an opportunity or reason to test this).
I also have been echoing the comments about Frodo's apps working fine with XMPCR, especially for standby and resume. Perhaps Frodo would be iwlling to look at your code, Guino, and tell you what you are doing wrong?