Recording NOT stopping at finishing time (logs attached)

[sub]

- are there any issues with having multiple muxes registered (once I fix the problem)?

If you have multiple versions of the Cyberlink mux installed, it'll only use the first one listed in the MuxChecker.

[mixedup]

thanks sub - this give me a few paths to follow up

[mixedup]

hi Sub - some more info:

* Channel 9 is the only channel that seems to be affected

* Note also when it doesn't stop recording it is not possible to stop it via the client interface, rather a recording service restart is required.

* Channel 9 signal strength seems to be ok I think(?) (Strength 83%, Quality 95%) - full details at http://forums.gbpvr.com/showpost.php?p=1...ostcount=3

* Changing version of the BDA driver DOES have an impact - very interesting - seem below however the trade-off I have
[INDENT]
* BDADriverV1.2.3.8_WHQL
- Latest driver
- Experiences channel 9 not "unlocking" when recording finished
- Quality is good

* BDADriverV1.2.2.7
- an older driver I had
- Channel 9 does not seem to have the "can't be unlocked" issue
- BUT with this driver the video quality is choppy
[/INDENT]

Any further ideas/comments?

Thanks

[sub]

* Note also when it doesn't stop recording it is not possible to stop it via the client interface, rather a recording service restart is required.

Reproduce it then zip and attach the logs and I'll take a look.

* Channel 9 signal strength seems to be ok I think(?) (Strength 83%, Quality 95%) - full details at http://forums.gbpvr.com/showpost.php...34&postcount=3

I was meaning more of a momentary signal problem, but it was only guess based on the symptoms. There may be some other reason your card or mux stops producing data.

[cliffodell]

Might be the dual-core? I had a problem similar, and in perusing the forums (GB-PVR and SnapStream) found a reference to a Windows setting that controls which processor(s) is/are allowed to execute the code. We set that to cpu-0 only and that seemed to cure the problem. "Affinity" setting.

[mixedup]

Reproduce it then zip and attach the logs and I'll take a look

The logs already attached would have included me trying to cancel the recording, but then having to restart the recording service. However just to be sure I'll do another log capture shortly and post these.

We set that to cpu-0 only and that seemed to cure the problem. "Affinity" setting.

Ummm...yeah I've been getting concerned it could be related to this.

cliffodell - would you be able to post more detail on this and how to try what you were suggesting? Hopefully there was a way to lock down a particular application (e.g. gb-pvr) to 1 CPU?

sub - know anything about the potential impacts on dual-core and whether this could affect an application? is this whether having a multi-threaded application comes into play?

Tks guys

[sub]

The logs already attached would have included me trying to cancel the recording, but then having to restart the recording service. However just to be sure I'll do another log capture shortly and post these.

What date/time? I cant find it in your logs.

sub - know anything about the potential impacts on dual-core and whether this could affect an application? is this whether having a multi-threaded application comes into play?

I doubt your problem relates to dual-core issues. I'm using a dual-core machine myself. Issues you'll likely see with dual core, if any, is stuttering during playback. From your description so far, the problem is more likely buggy Twinhan drivers or hardware.

[mixedup]

What date/time? I cant find it in your logs.

Thanks sub - logs are attached and here are some notes to assist (dates are today - basically just did the test then):
7.20am - was supposed to stop recording
7.25am - tried 2x to stop the recording through the client i/f without success
7.26am - restarted recording service (removes it from PENDING recordings list)
Notes
- Actually the recording was only 20sec long when I went to play it and looked at it, and on disk was 91MB (i.e. Channel Nine_20060806071000-2.mpg).

From your description so far, the problem is more likely buggy Twinhan drivers or hardware.

FYI - The tuner card was straight out of my old PC which was working fine with GB-PVR. Re the two versions of drivers, I actually am not sure whether I was using the old or the new previously. It would be interesting to know.

Is there a way I could look at my previous GB-PVR configuration to tell what version of BDA driver I would have been running then?

Tks again

[sub]

FYI - The tuner card was straight out of my old PC which was working fine with GB-PVR.

Yes, but I know from past experience that if it stops midway through a recording like this, its either the device (or its drivers) or the mux. Even if it was working fine in your old machine, the device or its drivers may not like something about your new machine.

Is there a way I could look at my previous GB-PVR configuration to tell what version of BDA driver I would have been running then?

Just look at the properties Windows device manager.

[mixedup]

PS. I wonder if there is a piece of software I could use as a test harness to lock onto a channel via BDA drivers, and then release? i.e. to simulate what GB-PVR is doing when it starts and stops recording