Not changing channel when recording starts late

[wtg]

I ran into a problem what I think is part of the resume recording feature.

My PC blue screened on me just a few minutes before a recording was supposed to start, but I didn't notice it until a few minutes after the recording should have already been underway. So I restarted the PC and the recording service started the recording. However, when I started to watch it in-progress, I realized it was on the wrong channel. It doesn't appear that the recording service tried to change the channel on the STB.

I cancelled the recording and then selected the program from the Guide to watch it, and the STB's channel was changed as expected.

I've attached the logs.

Thanks!

[sub]

Can you post the matching GBPVRRecordingService.exe.log?

[wtg]

Whoops... sorry I'm spreading mis-information. According to the other log, it did try to change the channel. Hmmm... I wonder why it didn't work?

Code:

2008-02-21 17:11:29.093    INFO    [5]    Found new programme requiring recording: Fallen
2008-02-21 17:11:29.250    VERBOSE    [5]    Changing to channel (GBPVR.Backend.Common.ExeChannelChanger): 642
2008-02-21 17:11:29.265    VERBOSE    [5]    Running: C:\Program Files\devnz\gbpvr\HaupBlast.exe 642
2008-02-21 17:11:29.406    VERBOSE    [5]    Requesting IRecordingSource to start recording: \\Cav\drive_f\Video\Recent Recordings\Fallen\Fallen_20080221_17051920.mpg
2008-02-21 17:11:29.484    VERBOSE    [5]    DirectRecordingSource about to start recording  oid:2 channel:642
2008-02-21 17:11:33.640    VERBOSE    [5]    recording started
2008-02-21 17:11:33.640    VERBOSE    [5]    Programme is now recording
2008-02-21 17:11:33.656    VERBOSE    [5]    RecordingFactory.save()

[wtg]

Sorry I jumped to conclusions. I knew one could usually see the channel change in the log... I was just looking in the wrong log.

[sub]

If you machine was bogged down with other activities required because of the restart (like running dumpprep.exe or similar), then the extra disk/cpu usage may have been enough to stuff up the delicate timing required sending IR signals correctly.

[martint123]

delicate timing required sending IR signals correctly.

I don't think this applies as it's handled by the dedicated Zilog chip on the Hauppague board. - Unless the driver hasn't been downloaded to the chip at this point.

[sub]

I dont know - its only a guess. I have no idea what happens behind the scenes of the Hauppauge call to send a specific channel numbers via the IR Blaster. If there is hardware that handles it, it may not be handling all the digits in one go meaning load could still be a problem when needing to send multiple digits.