net stop usbser gives me "The requested pause, continue, or stop is not valid for this service." And I don't think its a problem in windows.
I have experimented a bit and my current conclusion is that the problem only occurs when windows is in standby and IR Toy receives a infrared signal. If it does not receive anything during standby it works afterwards and I can succesfully send ir commands from winlirc.
Maybe my solution is to solder the receiver part off while I am only going to use the transmitter
@asdf that was also my initial idea. I tried "devcon restart" on it, the device was removed and the driver was reinitialized but after a short while the driver failed with an exclamation mark. This makes me guess that its an erroneous state on the USB stack on the device and not a bad state in windows.
@ian: the microchip usb stack was replaced for a reason? Maybe either JTR or Honken could comment on whether the stack is robust against host going into standby? And maybe they had an idea of how to solve this issue?
Any news on this issue? I am sorry to say that this makes the ir toy unusable for any real world usage. I was going to use it for my htpc, but it will cost me a fortune having it on 24/7 just to make the ir blaster happy.
I am having similar problems using the latest firmware v22 and windows xp. Same symptoms winlirc cannot initialize the device after resume from standby and I am unable to open a terminal connection with putty to the device. It need to be unplugged / plugged before working again.
I can see that you have been quite busy since my last post, thanks a lot for looking into the issue!
I have tested the work-around adding additional codes to the end, using "2" works but sending takes a long time (seems like it waits for timeout or something) using "50" also works and has no impact on the duration. Thanks for the hint, this is useful enough for me to get on with my android client.
I am sorry to bump this thread, but I am at a standstill with my project as long as this issue remains. I haven't been able to dig any deeper into the root cause of the problem. Have you tried the configuration I posted? Do you have any other hints or ideas of what I could try to solve or identify the issue?
Sending certain recorded buttons on windows XP causes winlirc/dll to freeze. I can see that the signal is transmitted (receiver receives the volume command) but then it dies. I have to kill winlirc and reconnect irtoy. Other recorded buttons works without any problems. This problem seems only to happen on XP as I have not experienced it on my windows 7 box with exactly the same winlirc/dll files.
Heres a small excerpt from the configuration file (PowerOn works, Vol+ doesn't): begin remote
name RC004SR flags RAW_CODES|CONST_LENGTH eps 30 aeps 100
gap 113364 begin raw_codes name Vol+ 810 938 810 938 831 917 1706 938 810 938 853 895 810 938 853 1791 1706 917 810 938 853 895 831
I have tried all sorts of things now, some more vodoo than engineering - hope my colleages don't read this ;-)
Eventually I googled the usbser.sys as I am beginning to suspect issues on XP not present on W7 being the culprit here. I found this guy who had a problem with the USB CDC driver on XP where ReadFile would sometimes return 0 bytes only after a timeout, and a subsequent ReadFile would return the actual data. If you have the time dukey maybe you could cast a glance at what hes writing: http://www.lvr.com/forum/index.php?topic=315.0
I am experiencing a problem when sending raw codes in winlirc on a Windows XP machine (tested on two different XP machine)(this apparently does not happen on W7).
Sending a raw code the first time works and I receive transmit complete 'C'. The second time the program 'hangs'. Seems like ir toy does not respond anymore. I have narrowed it down to raw codes with 23 entries causing winlirc to send 48 bytes to ir toy. I don't know if this has any relation to the 8 byte issue reported earlier?
I would be grateful for any hints on how to debug the issue further, or if anybody has an idea of what is going on here.
I don't know if its related to the issue reported by lupin in viewtopic.php?f=29&t=2974 as he's transmitting codes in RC5 format. Maybe its the same?
I have discovered it is only when the raw code contains 23 entries. This leads to a package length of 48. It seems that the first transmission is alright and I receive transmitComplete 'C'. The next time I try sending it freezes in the send function.
