video skips back when playing

[yanivf]

I’m a bit of a newbie, so I apologize if this has already been answered elsewhere.
Some of my playback files freeze, and the audio skips back a few seconds. I’ve tried playing the files through different players, and they all behave strangely, which led me to believe that the issue might be with the encoding itself. I noticed that FFmpeg was from 2023, so I updated it to the latest version.
I also wanted to tweak the TranscodeArgs since my hardware is fairly powerful (Core i9, RTX 4090, 128GB RAM), but I don’t think the settings are taking effect.

When I check the log (nrecord.log), the only parameters I see are as follows (i replaced the name of the show):
C:\Program Files\NextPVR\Other\ffmpeg.exe -re -y -i "M:\PLEX\_TV_\SomeTVShow_2025-04-04_22350030.ts" -vf fps=1/10,scale=220:124 -f mjpeg -flush_packets 1 "M:\PLEX\_TV_\SomeTVShow_2025-04-04_22350030.thumbnail"

here are the changes directly from the config.xml that I made -
<TranscodeHLS> 
  -y -v error -hwaccel cuda -hwaccel_output_format cuda -i [SOURCE] -f mpegts
  -c:v h264_nvenc -preset p5 -rc vbr -cq 19 -b:v [BITRATE] -maxrate [BITRATE] -bufsize 2M
  -c:a aac -b:a 128k -ar 48000 -ac 2 -s [RESOLUTION] -aspect [ASPECT] -g 60 -sc_threshold 0 [TARGET]
</TranscodeHLS>

<AnalyzeDuration>default</AnalyzeDuration>
<VideoEncoder>NVIDIA</VideoEncoder>
<TranscodeArgs>
  -y -v error -hwaccel cuda -hwaccel_output_format cuda -i [SOURCE] -f mpegts
  -c:v h264_nvenc -preset p5 -rc vbr -cq 19 -b:v [BITRATE] -maxrate [BITRATE] -bufsize 2M
  -c:a aac -b:a 128k -ar 48000 -ac 2 -s [RESOLUTION] -aspect [ASPECT] -g 60 -sc_threshold 0 [TARGET]
</TranscodeArgs>

[mvallevand]

Depending on the player NextPVR won't even use ffmpeg to transcode recordings unless you set "Recording Auto Transcode" The settings for those are hardcoded so they can't be changed. What you see in config.xml is for web player transcoding of Live TV and recordings on disk and even then if the source is IPTV typically they are just remuxed. I think there are some in config.xml that aren't even used.

That thumbnail file you show is for skipping in the NextPVR web player and UI clients and NextPVR.exe only. Often it helps for those clients but they can have problem with a bad source. If you don't used those clients you cant turn that off.

For a problem file it is best to upload it to an file share like GoggleDrive or OneDirve so we can look at it. You can also zip and upload the matching .timing file for an initial look.

Martin

[yanivf]

Hi @mvallevand,

Here is an example of a video recording that failed - https://1drv.ms/f/s!AoIrlVDr4zCPpowVXJXM...A?e=gLYlKt

Around the 23:30min mark is when, depending on the player either skips or hangs.

Thanks for the help

[mvallevand]

Which clients are you talking about? There are some missing packets in the file for sure and some clients are better than other at playing them.

Importantly the timestamps do go backwards in the file and jump around too. The source is really bad.

Martin

[yanivf]

Thank you, @mvallenvand!

Is there anything I can do on my end to help resolve the issue? I'm trying to understand how the source might be affecting the recording and causing the timestamps to be out of order. I’ve noticed this behavior not just in this recording, but in others as well.

In the logs, I see the following messages, but I’m not entirely sure what they mean:

- decode_slice_header error non-existing PPS 0 referenced
- decode_slice_header error no frame!

- [out#0/hls @ 0000023a6cf60fc0] Codec AVOption look_ahead (Use VBR algorithm with look ahead) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some decoder which was not actually used for any stream.

[out#0/hls @ 0000023a6cf60fc0] Codec AVOption sc_threshold (Scene change threshold) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some decoder which was not actually used for any stream.

For context, my playback clients include:
- Plex Web
- Plex on a Roku device
- My Plex server is running on a Windows machine. I’ve also tried using other clients, including the NextPVR web client, and the issue still appears.

[mvallevand]

Not knowing your source no but a better source would make sense. I suspect it is a url designed not to seek. I have used Pllutotv URLs that were really bad but the NextPVR two pass remux to mp4 option made recordings seekable but with live they the could die.

Martin

[yanivf]

@mvallevand, were can i enable the NextPVR two pass remux to mp4 option? I tried selecting the mp4 in the transcode menu but the mp4 behaved in similar way.

if it's through postprocess script would you mind sharing it with me. Would love to try it.

[mvallevand]

The missing packets probably make it impossible to do anything with this stream. Post processing can't do alchemy.

Martin

[yanivf]

Thank you, Martin.

One thing I can't get my head around is that all the recordings have the issue, however watching the stream live, I don't see any issues.

[BrettB]

One thing I can't get my head around is that all the recordings have the issue, however watching the stream live, I don't see any issues.

Did you ever post a set of logs? Or even indicate what type of tuner(s) you are using?

One difference between recordings and watching live is the order that the tuners are used. By default, recordings work DOWN the prioritized list of tuners and watching live works UP the prioritized list of tuners. So, if you have more than 1 tuners, typically different ones would be used. Your problem may be a simple as a bad splitter (or a bad tuner card).