Has anyone found a solution to this cause its still causing me problems and would really like it if I didnt have to restart the service every time gbpvr hits that error.
Are you using a C# wrapper provided by Jon who builds the USB-UIRTs? If you are I have found that the wrapper I was given (written by another USB-UIRT forum member) will stop responding after a random number of remote key presses. Tested it on 2 different machines.
I think that the problem is the wrapper rather than the USB-UIRT dll. I tried to write a program using the C# wrapper and found that it would crash with an unspecified error after a while.
Please let me know if GB-PVR uses this wrapper and I will investigate it further.
Im using it for both right now. I dont have to use it for a reciever too, but I would rather. Its one less device to have to mess with and one less wire being routed out of sight but still usable.
Jskyboo Wrote:Im using it for both right now. I dont have to use it for a reciever too, but I would rather. Its one less device to have to mess with and one less wire being routed out of sight but still usable.
I suspect to work around this problem, I suspect you'll have to use it as one or the other.
I think the problem stems from two different processes trying to share the USB-UIRT. Gbpvr.exe uses it as a receiver. GBPVRRecordingService.exe uses it as an IR Blaster. The USB-UIRT doesnt seem to like this.
You could also try adding the following to config.xml to see if it helps
sub Wrote:I think the problem stems from two different processes trying to share the USB-UIRT. Gbpvr.exe uses it as a receiver. GBPVRRecordingService.exe uses it as an IR Blaster. The USB-UIRT doesnt seem to like this.
Well is there anyway you could test this by making GBPVRRecordingService.exe pass its send command through gbpvr.exe thereby making it one process? Like as a test case. Then we may know if thats the real reason or not. I know that passing the command is way too trivial for gbpvr but it would be a good thing to code just to check for the problem.
Jskyboo Wrote:Well is there anyway you could test this by making GBPVRRecordingService.exe pass its send command through gbpvr.exe thereby making it one process? Like as a test case. Then we may know if thats the real reason or not. I know that passing the command is way too trivial for gbpvr but it would be a good thing to code just to check for the problem.
Unfortunately I dont have any time I can spend on this at the moment. I'm fairly sure this is the problem.
sub Wrote:Unfortunately I dont have any time I can spend on this at the moment. I'm fairly sure this is the problem.
Well see when it happens to me the recording service isnt having to change the channels at all. Its just sitting on one channel. So that answer just doesnt seem very logical. I have to go out of town tomorrow but when I get back Ill try disabling the change channel function so that gbpvr is only using it to recieve and see if it still errors up. If it does then that clearly is not the problem.
Every time it record a file it sends tells the USB-UIRT to change channels, regardless of whether it is already on that channel. It has no way to know you left your cable box on the same channel as when it started the previous recording.