Recordings in plex aren't working correctly

[themarf]

Hi all, been using NextPVR for a few months and things have been going well.  Recently I've started to have an issue where more times than not a recording becomes corrupted after a certain point.  Typically I watch recordings thru plex and they are usually ok.

Logs attached, example recordings starting @ 19:00.  Around 20:51 something seems to happen and I'm not sure exactly what.  Both recordings end up unplayable for me after about that time.  Recordings are fine up until then.  It doesn't usually solve the issue but I tried the fancy NextPVR UI client and they seemed to work.  Usually this isn't the case though.

Plex shows one recording as 17hr 31min and the other as 1d 2 hr.  So something is getting messed up somewhere and I'm looking to figure out how I can try to resolve.  I don't think the issue lies with NextPVR but I've tried about everything I can think of.  The recordings started less than 5 hours ago from the time of this post so there is no way they can have that length.  Only have about a year of docker exp under my belt so it's possible there is some sort of simple config issue that needs to be resolved.

Server: NextPVR running via docker on Unraid (12700k, 32gb RAM, 1TB ssd cache).  Happy to provide additional specs as needed.  Thanks in advance.

Marf

[sub]

Plex shows one recording as 17hr 31min and the other as 1d 2 hr.

This can be pretty normal. NextPVR just records an exact copy of what is sent from the source.

Some players do a fairly simplistic guess at the duration of a file - they just look at the first timestamp of a file, and the last timestamp, and decide the difference must be the duration. Unfortunately there are reasons that might not be the case. Broadcast TV timestamps can jump or wrap midway through a broadcast. They sometimes do this when switching to local news etc. (you can also get this sort of thing from IPTV channels if the providers encoder died and was restarted during that time)

If you can't convince Plex to fix this shortcoming in their player, you can probably work around it by remuxing the files in PostProcessing.sh using ffmpeg. Remuxing effectively fixes the timestamps in the file, so they start an zero, and increase in an orderly fashion until the end of the file.

If you wanted to supply a sample recording with problems, i can take look if there is anything obviously wrong. You'd need to provide a download link for the file.

[themarf]

If you wanted to supply a sample recording with problems, i can take look if there is anything obviously wrong. You'd need to provide a download link for the file.

Hi Sub!

Here is a folder with all files for both recordings contained within.  Let me know if you have any issues accessing. Here is a link.

Appreciate your help.  I have heard nothing but great things about how helpful you are around these parts.

Thanks, Marf

[mvallevand]

I only check one file but it clearly stars new timestamps starting 3793895704 bytes (131 minutes) into the file. If you split the file into 2 at this point I expect both would be playable.

I did see something in the logs though and I am not sure why NextPVR is logging this.

2024-04-30 20:51:25.497 [DEBUG][350] HTTP input source starting
2024-04-30 20:53:34.886 [DEBUG][350] HTTP input source starting
2024-04-30 22:21:51.815 [DEBUG][350] HTTP input source starting

I am guessing the stream is getting interrupted and needing to restart. Maybe changing this to true in config.xml <UseFinalM3U8>false</UseFinalM3U8> but it might make things worse if the provider is not stable.

I tried a remux and it wasn't great.

Martin

[sub]

Maybe changing this to true in config.xml <UseFinalM3U8>false</UseFinalM3U8> but it might make things worse if the provider is not stable.

He's using .ts IPTV channels, rather than m3u8, so that setting won't do anything in this case. He could try switching to m3u8 to see if this type of stream is more reliable with his IPTV provider.

Not uncommon for IPTV streams to a steaming pile of crap though. Often most channels work well enough for a very short viewing, but can't be relied on to stay up consistently for an hour+.

[themarf]

He's using .ts IPTV channels, rather than m3u8, so that setting won't do anything in this case. He could try switching to m3u8 to see if this type of stream is more reliable with his IPTV provider.

Is there an easy way to check or change this configuration?  Still relatively new to NextPVR.  I will say I've had about 85-90% success ratio with recording hockey games since September from my IPTV provider.  Just seemed to have a few with issues in a row so it motivated me to look into it a bit.

When clicking on my devices in NextPVR I cannot see how it was imported but I'm pretty sure I imported m3u link.

[themarf]

Ah, found the setting Martin mentioned in the config.  I will keep that in mind to try.

1. So I did a bit of digging and talking with some users in the IPTV discord for my specific provider.  Another user was having similar issues (with recordings going to jellyfin) but when he converted them from .ts to .mp4 things seemed to work (before & after pics below).  Wondering if its a product of everything being re-encoded and the format is irrelevant.
   
2. I was thinking of trying to have NextPVR auto transcode to .mp4.  Or would it be better to have it transcode after it's done recording?
   
3. If the latter I understand that I need the .sh script in /scripts, but I'm not sure on how to call since I'm running docker via Unraid.  I think I need would need to install it somehow first.
   
4. I have an intel quicksync cpu, is there a way to have nextpvr use that for transcoding.  I do have the intel gpu and hardware transcoding working for plex, would the process be similar for NextPVR by adding a device?  Attached a pic of how I did this for plex.
   
5. I think after I solve this I need to delve into the parallel & post processing scripts as I'd really like to get comskip working.
   

Sorry for the mess of questions. Still quite new to all this and trying to figure it out. Feel free to make me clarify anything.

Thanks again Martin & Sub for your help.

[themarf]

Just found the custom NPVR image with comskip and ffmpeg installed. That might simplify a lot of my questions. Will attempt to play with it.

https://forums.nextpvr.com/showthread.php?tid=61999

[mvallevand]

For the one sample I looked at the container was not the issue, garbage in garbage out whether you remux or transcode. Just because the timestamps are correct at the beginning and end of the file doesn't mean a file will play smoothly.

The biggest problem is probably you need to work with Plex. They are likely transcoding your ts file for playback on-the-fly anyway and if it isn't playing well your expectations from Plex or Jellyfin could be too high. Some NextPVR clients do attempt to correct for the timestamp issue and many handle ts files much better than Plex or Jellyfin.

NextPVR VAAPI will not be much different the QSV on normal Linux not sure what is enable in sub's Docker though. You will need to investigate Docker and h/w ffmpeg decoding.

I personally would not recommend auto transcoding and would work it into your post processing script, especially since you are considering comskip. You could even try jellyfin's custom ffmpeg in a script (again subject to Docker, bare metal is preferred)

Martin