Any way to remux LiveTV encoding from *.TS to *.MKV in realtime for DVR?

[sausageDeltaFruit]

I have nothing but trouble with the *.ts files that the DVR recording of Jellyfin LiveTV generates.  This is made even worse when attempting to watch a recording live.  Seeking FF/RW never seem to work, and constantly get stream errors that terminate playback.  Not sure if it's due to OTA hardware transcoder, playback client or what, but I just want to get away from TS all together.

Is there a way to either:
1) Change the output format of the jellyfin DVR recording task to write directly to an MKV instead of TS?

2) Remux the real-time disk write to use the MKV container instead of TS?

• Original jellyfin writes to the native TS container.
  
• When record is started, secondarily trigger an FFMPEG task to watch the TS file as written to disk and remux to MKV as data is written to file?
  

I'd say #1 is far more efficient, cutting out the middle-man TS file, but not sure if that's possible.
For #2 - is there a way to trigger an action when a recording starts the way a post-processing script can be called?

Recently, I started using a DVR post-processing application script to remux and change containers w/out reencoding once recording is complete, but I'd really like to do this in real-time so I can watch a show while it's recording

I'm using HDHomerun Extend and typically Roku Ultra devices for playback.  I can watch through the HDHomerun directly, but it doesn't allow DVR functions on live TV.  I know I've seen the Roku devices have codec "quirks" that cause a multitude of problems, but they play the remuxed MKV versions just fine, no transcoding needed.

Thoughts/suggestions/other solutions?

[TheDreadPirate]

Your post-processing script is THE solution. AFAIK, there are no settings to change the recording container.

[gnattu]

I recommend against remuxing it unless you want to fix all the potential issues as well yourself. The recorded ts may contain invalid data from time to time due to the nature of livetv, and changing its container with ffmpeg may result in weird problems like out of sync audio/video.

[sausageDeltaFruit]

Your post-processing script is THE solution.  AFAIK, there are no settings to change the recording container.

Unfortunately, post-processing is not actually a solution for me b/c I'm looking for a way to do it near real-time (with a minor I/O delay), not simply after a recording is 100% complete.  Lets just say I have a high value, opposite sex, long-term roommate with substantial legal footing who demands reliable live TV watching capabilities.

I figured there'd be a way to hook into the recording trigger at the very least.

I recommend against remuxing it unless you want to fix all the potential issues as well yourself. The recorded TS may contain invalid data from time to time due to the nature of livetv, and changing its container with ffmpeg may result in weird problems like out of sync audio/video.

Yeah, I realize TS is a bit dodgy, but for me, MKV remuxed seem to be far more reliable in general.  I do see some TS encoding jank in the ffmpeg remux output logs, so I keep the original TS around for a short time in case I have no other option.  Given that seeking within TS files just plain never works, I have to do something or else DVR function is completely worthless.

[macthaidhg]

Maybe get a decent client for watching .ts files? I am using Chromecast with Google TV, and I find seeking of recording .ts files to be just as snappy as a transcoded .mkv. Post processing doesn't have to be as much of a burden as you are making it out to be. Just don't skimp on server CPU and your transcode will be completed fairly quickly. Just tell your roommate to wait x amount of time before viewing a recording and the mkv should be available for viewing.

[swartech]

I am also experiencing the audio sync and seeking issues that @sausageDeltaFruit reported.

I have attempted the post processing method that @TheDreadPirate recommended by following the JellyFin documentation, and can get a successful mp4 re-encoding with audio sync'd. However, the post-processing will not trigger automatically after a live TV recording. I can manually run the post processing script as such:

root@<hostname>:# scriptfile.sh "</absolute/file/path/filename.ts>"

I've verified permissions and the path(s) and looked in the log files for clues as to why it will not execute automatically.

[TheDreadPirate]

Is the script readable and executable by the jellyfin user? Is the script located in a place Jellyfin has access to?

[swartech]

Is the script readable and executable by the jellyfin user?  Is the script located in a place Jellyfin has access to?

Yes, the scripts folder permissions is octal 751 and the scripts themselves are 755 and the jellyfin user and group are the owner of both. I am using the suggested method of a 'runner' shell script to invoke a python script that actually does the transcoding. I also tried the shell script version of the transcoding and both (python|shell) will run as root with the path to the '.ts' file specified. I tried to run the scripts as the 'jellyfin' user but I believe shell login is not enabled for that user. Is there somewhere else logs for the 'post-processing' engine can be found? I was not able to find any logs in the /var/logs/jellyfin folder pertaining to the execution of post-processing.

[TheDreadPirate]

I just use a straight bash script.

Code:

#!/bin/bash
INPUTFILE=$1
NEWFILE=$(echo "$INPUTFILE" | sed 's/\.ts/\.mp4/g')
/usr/lib/jellyfin-ffmpeg/ffmpeg -y -fflags +genpts+igndts -i "$INPUTFILE" -map 0 -codec copy -max_muxing_queue_size 2048 -avoid_negative_ts make_zero -max_interleave_delta 0 "$NEWFILE"
rm -f "$INPUTFILE"

[swartech]

[quote="TheDreadPirate" pid='44081' dateline='1732642337']
I just use a straight bash script.

Hi @TheDreadPirate, thank you for providing your post processing script. I am able to successfully run the post-processing task after live recording when placing the script files in the /var/lib/jellyfin directory. I believe the systemd.service and the jellyfin user in /etc/passwd restricted script execution to this directory. I discovered this through trial and error.