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

Quote: 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

Quote: 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

Quote: 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?

rjoek · 09-16-2005, 11:16 AM

So do you have plans to fix the XMPCR issues?
I can't compile your open source code without some effort, it seems (had planned on fixing your XMPCR code myself). Where do you suggest I go from here?
Are there really only 4 or 5 people affected by this??

guino · 09-16-2005, 12:09 PM

I'll take the time to do some more testing with the XMPCR as soon as I have time.. I've been travelling for work for the past 2 weeks and I'll travel again this week, so don't expect anything very soon but it is on top of my list of things to do. You can PM me with the issues you have with the source code, but most likely you don't need to meet all the requirements to RUN the source code inside VB and debug the issue you're having.. to COMPILE is that you need all nice an neat.. If you find a solution, you can just send me the changes and I'll put on the main sources and compile it for everyone.

IntellaWorks · 09-16-2005, 12:25 PM

For testing purposes, RJ try doing what guino did for testing his software. Hibernate (or resume), unplug device, resume (come out of hiber) then plug back in. Do you get the same results as the original problem? Or did the problem go away?

The reason I ask is because if I were writing the software I'd want to work with a known. And the feedback might help him fix the problem faster.

Guino: I haven't investigated this problem too deeply so forgive me if I'm way off. If the users have XMPCR configuration checked off in RR, you may be able to capture the hibernation or resume request by hooking into the messaging que and holding it for a bit while RR manually disable's the usb device (I.E "remove it saftley")

Goodluck all!

rjoek · 09-16-2005, 01:52 PM

Thanks for the comments, both of you. I am happy to test this as Guino has implemented it (standby, unplug device, resume, plug device back in), but ultimately the real issue is whether it can work as it would be used in a real environment (standby, leave device connected OR cut power -- as in from a powered USB hub, then reconnect/power-on, then resume). Now that Guino has an XMPCR it will only take his time for him to fix it.
And I really appreciate your time, Guino. I understand that you have many other more pressing things to take care of, so I will try to work on it myself. You are simply much, much, much faster than me!
As for 'testing data', I am happy to send a PM with a recap of everything I have experienced with this issue, so that you can develop a solution a little better.
Thanks, as always.

skippy76 · 09-23-2005, 08:48 AM

Hi guys,

I've just upgraded to the latest verison of RR and I'm finding that my XM(PCR) is not working anymore through RR. I have the port correctly set in the config... Anyone else having these problems?

Thanks

Andrew