PVR-500 times messed up

[bgowland]

I had this problem about a year ago with some pre-release drivers and now I'm seeing it again.

Recordings that are 10mins long show they're about 1min when playing back (GB-PVR and WMP). Recordings that are 30mins long show as being about 10mins etc. etc. Generally they playback OK but using FF/RW etc. makes things go a bit strange.

I'm using the latest drivers from shspvr but I've also swapped back to older drivers of various versions and still get the same thing.

Looking at the lastgraph.grf, I see an Encoder of some sort connected from the 656 pin on the capture filter then to the file writer. I don't remember seeing that Encoder before and it doesn't appear in graphs when my PVR-350 is being used. Maybe it's supposed to be there?

I'm confused as to why this suddenly started happening a few weeks ago when I don't remember having changed anything significant on my system.

Cheers,
Brian

[sub]

Sounds like the timestamp bug. Read: http://forums.nextpvr.com/showthread.php?t=14006

Looking at the lastgraph.grf, I see an Encoder of some sort connected from the 656 pin on the capture filter then to the file writer. I don't remember seeing that Encoder before and it doesn't appear in graphs when my PVR-350 is being used. Maybe it's supposed to be there?

Yes, this is correct. The devices based on the conexant blackbird design (like PVR150 & 500) use a separate encoder filter.

[bgowland]

Sounds like the timestamp bug.

Thanks, I'd done a search for PVR500 related problems but it hadn't occured to me to search on the PVR150.

Things are looking better although still not quite right. I did three recordings in parallel. The one on my 350 showed perfect time. The two on the 500 showed times of 36mins 42 secs and 36 mins 51 secs - both were 30 min recordings with 2min prepadding and 5 min postpadding. On playback both stutter and pause for the first few seconds.

What does HcwTimeStampIssue2 do? I notice in the thread you mention, this is set to DWORD 0x0. What happens if I set it to 0x1? If I set it to 0x1 should I set the other to 0x0? What happens if I set them both to 0x1?

Never mind - don't answer those questions. You know me - I'll just try it anyway just for the fun of it.

Cheers,
Brian

[sub]

What does HcwTimeStampIssue2 do? I notice in the thread you mention, this is set to DWORD 0x0. What happens if I set it to 0x1? If I set it to 0x1 should I set the other to 0x0? What happens if I set them both to 0x1?

To be honest, I dont really know the specifics of what either setting does. I do know that 0x0 is enabled, 0x1 is disabled...seems backward to me, but I'm only the messenger.

[bgowland]

To be honest, I dont really know the specifics of what either setting does. I do know that 0x0 is enabled, 0x1 is disabled...seems backward to me, but I'm only the messenger.

Thanks - so no point in setting them both to 0x1 then. ..and that means it's the HcwTimeStampIssue2 that is actually being used.

I'll keep an eye on the recordings and if they continue to show as being slightly short and have the jerky start then I'll play with the other setting.

Cheers,
Brian