v4.0.4 glitch issue with overlapping recordings on same channel

[Stereodude]

I set my recordings to pad by 3 minutes pre and post and if I record two show back to back on the same channel the first recording gets a glitch when the second recording starts. For me, NextPVR has always had intermittent minor glitches when overlapped recordings start going back to when it was still gbpvr. However, it's gotten MUCH worse with 4.0.4 compared to 3.6.6 or other older versions I've used. Older versions didn't always have a glitch and if there was one it was contained within a single GOP and was a minor playback annoyance I lived with. With 4.0.4 the disruption is several seconds long. During playback with MPC-HC (using LAV filters) it manifests as several seconds of the program repeating and worse it messes up my commercial editing flow (see below).

The resulting recordings often can not be processed correctly by Avidemux and that's my editing tool for commercial removal. About 50% of the time the saved output from Avidemux abruptly cuts at the spot of the recording glitch. The issue with truncated Avidemux's output did not happen with recordings from NextPVR 3.6.6 or earlier versions.

So a specific example:

I record Lucifer on Fox from 8:00-9:00pm on Monday night and The Gifted from 9:00-10:00pm. So at 8:57pm there is a several second glitch in the recording of Lucifer when the recording for The Gifted starts. FWIW, the glitch is not in the recording of The Gifted (at the very start)

Here's a trimmed .ts snippet (~10MB) of the above mentioned glitch. Just unzip it with 7-Zip and see how it plays. This particular glitch resulted in truncation by Avidemux.

This issue is bad enough that I plan to revert back to 3.6.6 from 4.0.4.

I'm using multiple HD HomeRun tuners recording broadcast ATSC OTA in the US on a gigabit network. The recording system is running Windows 10 Pro on a 4C/8T Intel Xeon E3-1231 v3 CPU with 32GB of ECC RAM and the recordings go to a 1TB Samsung 850 Evo SSD that is not used for anything but "DVR" space. The system is basically idle and should be more than capable for basic headless "DVR" duty.

[gromgsxr]

yeah i see this behaviour as well i did bring it up before but never heard back about it

[theluckyman]

I got same issue like yours sometime my recording is stuck recording so the longer u record like more than 3 or 4 hours it started to ignore other channels/times and i keep getting "recording service not running at recording time" few times a day it is pretty getting annoying. idk if nrecord being lazy sometime or maybe NTray.exe? so i had to keep reboot 10 or 15 mins before premiere nights of recording to avoid any problems... so is it possible to stop reboot pc everytime? because i always record second airing sometimes because first airing get issue... that's why i record twice a night just in case...

[Stereodude]

yeah i see this behaviour as well i did bring it up before but never heard back about it

That's unfortunate. I'm going to proceed with my rollback.

Edit: I uninstalled 4.0.4 from the Control Panel, and installed 3.6.6, but it still reports being 4.0.4 when I right click and do about in the GUI.

[mvallevand]

That's unfortunate. I'm going to proceed with my rollback.

Edit: I uninstalled 4.0.4 from the Control Panel, and installed 3.6.6, but it still reports being 4.0.4 when I right click and do about in the GUI.

The version number is stored in config.xml. It is also the version of the database structure which usually isn't a big deal and it saves reinstalling tuners channels etc.

Martin

[Stereodude]

The version number is stored in config.xml. It is also the version of the database structure which usually isn't a big deal and it saves reinstalling tuners channels etc.

Martin

Oh, well that would explain that. The good news is that 3.6.6 works as it did before. It's a shame NextPVR is regressing.

[pkscout]

I see this as well, although for me it's a small stutter in playback. I've been meaning to pull log files to post, and I'm wondering exactly which ones would be useful. If we would all pull some logs for sub, then he would be able to actually look at the problem. Without them we're just pissing into wind and sub would be flailing around trying to duplicate the problem.

[sub]

I see this as well, although for me it's a small stutter in playback. I've been meaning to pull log files to post, and I'm wondering exactly which ones would be useful. If we would all pull some logs for sub, then he would be able to actually look at the problem. Without them we're just pissing into wind and sub would be flailing around trying to duplicate the problem.

Do you see this on playback of a recording? If so, can you please supply a short sample recording on somewhere like Dropbox or OneDrive, and let me know the download link? I'll check it out here.

[pkscout]

Do you see this on playback of a recording? If so, can you please supply a short sample recording on somewhere like Dropbox or OneDrive, and let me know the download link? I'll check it out here.

I do see it during playback in Kodi. I don't use NPVR for playback (don't even have the codecs installed), so I can't confirm whether it's just a Kodi playback issue, but it definitely happens right at the recording overlap. Anyway, I'll go hunt one down and see if I can trim the recording and post it somewhere.

[pkscout]

Do you see this on playback of a recording? If so, can you please supply a short sample recording on somewhere like Dropbox or OneDrive, and let me know the download link? I'll check it out here.

OK, here's a link to a trimmed file with the issue.

https://drive.google.com/open?id=1R1dGlU...QorFGQkrg7

You'll notice right after the elevator doors close and the scene changes that it hiccups and then "goes back in time."

And just for completeness, here's a trimmed version of the other overlap recording that started.

https://drive.google.com/open?id=1FZk0iL...qKCiNHAmra

You can see when you look at the two of them that the hiccup happens right when the other recording starts.

P.S. the timecode on the trimmed files seems to be messed up (in VLC it reports 0:00 and never shows any time incrementing). That is 100% due to the software I used to trim the MPEG2 file. I don't have any timecode problems in the original files.