2010-02-17, 02:27 AM
Sorry for posting if this hasn't been answered already but I couldn't find a solution and I didn't want to buy an ir blaster since the HD-PVR comes with one.
I was having problems recording and getting the short .ts and .mpg files with the 1212, using the built-in ir changer. It seems that the HD-PVR cannot record and use the blaster at the same time. To verify, I ran a capture graph with rctvcap and then changed channels with wintv2tme; the bling lights go off momentarily during the channel changing before it recovers.
For me, the problem is that gbpvr runs the wintv2tme in a nonblocking mode, immediately going on to run the capture graph. The combination of executing the wintv2me simultaneously with starting the capture is too much for my device to bear, and it freezes up or times out.
I fixed my problem by writing a pre-launcher .exe that holds for 15 seconds before running the real wintv2tme .exe. I configured the launcher as my ir changer. This gives the capture time to spin up, and though the bling lights still go off momentarily, the recording can continue because the box is not trying to do both at the same time.
It might be a useful enhancement to have an option in the config.xml, when exec()ing an .exe channel changer, to pause for a given number of seconds before the capture starts. Either that, or if the program calls CreateProcess() to run the changer .exe, to WaitForSingleObject() before begining the capture. In the case of the wintv2tme, it seems to return before the channel is actually changed anyway , so perhaps waiting a fixed number of seconds would be best.
I was having problems recording and getting the short .ts and .mpg files with the 1212, using the built-in ir changer. It seems that the HD-PVR cannot record and use the blaster at the same time. To verify, I ran a capture graph with rctvcap and then changed channels with wintv2tme; the bling lights go off momentarily during the channel changing before it recovers.
For me, the problem is that gbpvr runs the wintv2tme in a nonblocking mode, immediately going on to run the capture graph. The combination of executing the wintv2me simultaneously with starting the capture is too much for my device to bear, and it freezes up or times out.
I fixed my problem by writing a pre-launcher .exe that holds for 15 seconds before running the real wintv2tme .exe. I configured the launcher as my ir changer. This gives the capture time to spin up, and though the bling lights still go off momentarily, the recording can continue because the box is not trying to do both at the same time.
It might be a useful enhancement to have an option in the config.xml, when exec()ing an .exe channel changer, to pause for a given number of seconds before the capture starts. Either that, or if the program calls CreateProcess() to run the changer .exe, to WaitForSingleObject() before begining the capture. In the case of the wintv2tme, it seems to return before the channel is actually changed anyway , so perhaps waiting a fixed number of seconds would be best.
