2.3.6 Slow Resume from Skip Forward

[mikeh49]

With 2.3.6 I still have a problem with delayed resume from forward skipping, either the "small skip" or the "large skip" when playing .ts files recorded by NPVR.

Background: I have a low power system (Sempron 2800/9600Pro/Win7) in the downstairs family room that I use to play recordings from two other NPVR boxes by way of the Videos menu. The videos of interest are all either GBPVR or NPVR recordings. The programs are US clear QAM MPEG, and the GBPVR recordings use the ATI or dvr-ms mux. The NPVR recordings are .ts. This low power system plays the recordings just fine, smooth video, no sync, etc.

On the low power system, there is frequently (at least 2/3 of the time) a long delay in restarting the video after a forward skip. This existed in 2.2.6 as well. With 2.3.6, skipping while paused now works great, no delay in restarting at the new point. Also, I have not seen a problem in reverse skipping. In the logs attached, the two forward skips of Combat Hospital took 37 secs and 22 secs to restart the video. I added a comment in the logs at these two points, noted by >>>>. The image jumped to the new point "immediately", but remained still for the 37 or 22 secs until motion resumed. There was no audio until motion resumed.

This does not exist on either of the other, higher power, NPVR boxes on 2.2.6.

The dvr-ms recording (MI-5) skips just fine, either direction, and these recordings have always been fine.

I note in the log that the .ts file uses the AC3 Audio Renderer, while the dvr-ms file uses the default direct sound device. Maybe that program does not have AC3 audio, so perhaps not significant.

Hopefully this can be fixed.

Thanks.

[ShiningDragon]

Mhm, this problem seems to be finally fixed with this release on my machines. I can even jump 600 seconds within 1-2 seconds without waittime (before every jump added ~10 seconds waittime ...).

Which decoders are you using?

*all is fine with the database*

[sub]

You can ignore those database errors. This is normal in the first log after a version upgrade. It just shows it reapplying all the database changes. Most of these database updates have already been applied in previous versions, and result in the error message. The new 2.3.6 changes apply fine. Subsequent runs of the app wont do these database updates.