resume playback position problem

[johnsonx42]

ok, final comment - the problem appears to be in the NPVRTSReader, not in Unmanaged.dll. I've reverted back to the original 1.5.33 NPVRTSReader (dated 2010-10-11) and all the problems are gone, but of course the 12:48 resume position problem is back.

[ShiningDragon]

1) the timeline still corrupts to -35791934 if I just let it play to the problem point, but it appears to keep playing correctly as long as I don't skip.

Exactly this i can confirm too (just tried to watch a recording). At the first three tries i had the comskipfiles at the recording, so i thought that there could be a problem. I removed the from comskip generated files and started npvr again. Same behaviour.
Skipping is another thing. I had configured that every skip should take 5 minutes (300 seconds). In the first quarter of the video this seems to work, then every skip degrades in length: 2 minutes, 1 minutes, 30 seconders, 15 seconds and so on.
If i don't touch any kind of skipping, than i got the mentioned timelinedisplay, but the video plays.

EDIT: i have collected additional information on this behaviour. I don't think that this is a reader problem. The error seems already happening on recording! Because it's not possible to watch the recording within nPVR (after getting the timeline "-35791934" audio and video aren't synchron anymore) i have tried vlc player (videolan.org). VLC doesn't display the current time / full time of the recording. This is an indication for a not good recording. This could explain the stuttering while watching live tv over network too!
Something is not right with the generated .ts files. Something is missing or there's bad information, i don't know.

[johnsonx42]

bump; sub, I just want to make sure you've seen this. the 11-3 version of NPVRTSReader.ax you posted is badly broken. I've gone back to the original 1.5.33 version which works fine but of course still has the 12:48 resume position bug.

edit: a further comment - I think the 'point of corruption' is based on byte count rather than time; the recordings I watched in the logs I posted were all 720p HD, but I'm sure the Sesame Street recording from PBS uses a lower data rate as they have 3 SD sub channels as well. that jives with the 'point of corruption' being around 18 minutes in the Family Guy and House recordings, but just past 30 minutes in the Sesame Street. Perhaps you are overflowing a variable?

edit again: ah, yeah, I just looked again and all three blow up the first time it goes past 2gb or 2147483648 bytes.

[sub]

Its on my list to look into, but I've been busy with day job stuff the last couple of days.

[johnsonx42]

no problem, it's fine as is... not being able to resume is a minor inconvenience but obviously something that needs to be fixed one o' these days. Since I moved the patch you posted I wanted to make sure you saw that it didn't work right. I put the original version of the TSReader into my cumulative patch, so that will fix up anyone who installed the 11/3 version.