long livetv recording wont resume playback/skip forward

[Tau512 15]

its the start of the BTCC motorsport in the UK which is probably one of the longest single-program EPG broadcasts around.

while we originally started watching the recording almost-live, we've stopped & turned TV off and came back to it throughout the day. this means mid-recording playback resume.

now we're around the 3h30min mark of playback (off around 8hours) then emby is refusing to play back via any frontend; androidTV, sheild or web based.

in an effort to figure out whats going on i play from the start of the recording and it immediately playbacks, however skipping forward manually (about 1 hour) appears to just make emby upset and refuses to actually play back.

i've attached the transcode log of this attempt.

server is linux and there doesnt appear to be any excess resource usage - system resources all seem good (nvidia-smi, disk space and general system resources)

theres another 30mins of the EPG broadcast so once finished i'll try again & try transcoding via handbrake to see what result those give.

ffmpeg-transcode-cf4b97c1-0eef-4534-afc5-cd55fe0d21bb_1.txt

[Tau512 15]

recording worked as expected after it finished. Since i wasnt getting chapters with the UP arrow during recording i assume theres an internal post-processing jobs occuring which has regenerated a seek table or something to assist with seeking/resume playback.

anything i can do to stop this happening or is it just something to live with?

 

[Carlo 4561]

I too have seen this happen on long recordings but have never figured out a cause or fix for it but find that once it's done recording it is fine.
It almost seems like one "bit" flipped wrong will cause issues if you catch it just right doing a FF.  Of course the longer the recording the more chance of something like this happening.

I wish I had something better to tell you but I don't other than just try and "play" without pause/ff as much as possible during playback of long recordings while it's recording. Of course the other thing is just record and watch later but with live events that's not always desirable.

[Tau512 15]

thanks for the openness - shame it's one of those issues but i'd rather have it confirmed as such so we know for the future.

just an fyi incase it helps in the future: unless i've not understood correctly, i record to BTRFS (transcodes are on XFS) which checksums blocks as it writes. This should ensure bitflips on the recording storage do no occur and the data is consistent. all storage is SSD.

emby hardware is desktop teir so no ECC ram which i know bitflips could occur in but i'd expect that to be solved by retrying the playback. The same with my transcode storage; temporary XFS space which would be recreated on a new transcode job.

i would agree the symptoms do feel like corruption somewhere though that gets resolved somehow after the recording finishes.

 

[Tau512 15]

i had a thought about this last night and it seems like it'd work based my experience of emby so far - clearly i'm not the only one whos experienced or will experience it.

Could Emby's transcode method work as a solution where it'd create lots of segments (seems to be around 100kb for transcoding) and use those to playback currently recorded TV and not suffer from seek issues on long duration recordings? i guess technically it wouldnt matter if those segments are 100KB, 100MB or 1GB other than inode limits on the filesystem when you store a lot of content.

i guess the logic behind libraries might need to change as it'd detect every file as unique rather than part of the same recording... although if there is an internal seek job being ran after recording stops which fixes the seek issue, maybe there could be one to join all the segments into one file to keep libraries happy?

... just throwing some ideas out there....

[Carlo 4561]

Not sure I follow what you're suggesting.

[Tau512 15]

See if i can clarify things - bear in mind this is a Linux server but i assume the same across all OS's.

i'm assuming that the seek issue with the suspect 'bit flip' is directly related to file size. From my understanding, the longer (and thus bigger filesize) the recording, the more chance of the issue occurring.

Contents of the transcode folder below (in this case, the aformentioned BTCC recording). note that each segment of this transcode job is around 900KB. i assume the .3u8 file is appended to every time a new .ts file is created. Timestamp certainly confirms this with 18:32 being current time at the time i grabbed the info.

ls -lah /mnt/btrfs-ssd1/emby/transcode/transcoding-temp | sort
...
-rw-r--r-- 1 emby emby  6.0K May 11 18:32 0CB8F9.m3u8
-rw-r--r-- 1 emby emby  636K May 11 18:27 0CB8F9_4564.ts
-rw-r--r-- 1 emby emby  744K May 11 18:27 0CB8F9_5901.ts
-rw-r--r-- 1 emby emby  770K May 11 18:27 0CB8F9_5936.ts
-rw-r--r-- 1 emby emby  796K May 11 18:27 0CB8F9_5902.ts
-rw-r--r-- 1 emby emby  820K May 11 18:27 0CB8F9_5903.ts
-rw-r--r-- 1 emby emby  848K May 11 18:27 0CB8F9_5900.ts
-rw-r--r-- 1 emby emby  918K May 11 18:30 0CB8F9_6410.ts
-rw-r--r-- 1 emby emby  941K May 11 18:30 0CB8F9_6418.ts
-rw-r--r-- 1 emby emby  964K May 11 18:30 0CB8F9_6411.ts
-rw-r--r-- 1 emby emby  987K May 11 18:32 0CB8F9_6456.ts

 

contents of the BTCC livetv recording folder. note that the -1 suffix is the stop & restarted recording i did in the hope this would fix or aid diagnostics. total *.ts filesize is 8.8GB

ll -lah "/mnt/btrfs-ssd1/emby/recordings/Live  British Touring Car Championship"
total 8.8G
drwxr-xr-x 1 emby emby  636 May  9 16:59  .
drwxrwxr-x 1 emby emby 1.1K May  9 11:11  ..
-rw-r--r-- 1 emby emby  761 May  9 16:59 'Live  British Touring Car Championship 2021_05_09_10_50_00 - Thruxton - 1.nfo'
-rw-r--r-- 1 emby emby 1.6G May  9 18:16 'Live  British Touring Car Championship 2021_05_09_10_50_00 - Thruxton - 1.ts'
-rw-r--r-- 1 emby emby  761 May  9 11:11 'Live  British Touring Car Championship 2021_05_09_10_50_00 - Thruxton.nfo'
-rw-r--r-- 1 emby emby 7.2G May  9 16:59 'Live  British Touring Car Championship 2021_05_09_10_50_00 - Thruxton.ts'
-rw-r--r-- 1 emby emby  90K May  9 10:49  poster.jpg
-rw-r--r-- 1 emby emby  167 May  9 11:11  tvshow.nfo

 

What would happen if we applied the same transcode behavior to all recordings (or a per-recording setting to allow segmenting) where splitting up the .ts files into segments would reduce/eliminate the chances of seek issues with long-duration recordings? For example 500MB per segment. This would result in 18 segmented files.

With the current emby behavior, we would see 18 separate videos in the library to playback which isn't ideal. As i've just discovered typing this up, i assume we'd then need a m3u8 playlist file to be generated to allow a single "recording" to be visible in the emby client view as well as code change to facilitate this somehow.

a moot point i think now but: my previous thought in my last response was when the recording finishes, emby would then join these 18 segments into a single file but (the bit i discovered while typing up) that could cause issues with remembering resume location or nonlive-playback-while-still-recording issues.

does this make sense now?

Edited May 11, 2021 by veehexx1

[Tau512 15]

oh, i also found something slightly annoying too; the 'autowatch' flag appears to be triggered by % remaining. seems perfect for 30-60min shows, but with this BTCC recording, it appears to mark it a bit too early.

maybe use % but up to a maximum of, say, 4 minutes? 2 minutes would probably be plenty.

Just a bit of feedback on that one

 

[Luke 42088]

On 5/11/2021 at 2:20 PM, veehexx1 said:

oh, i also found something slightly annoying too; the 'autowatch' flag appears to be triggered by % remaining. seems perfect for 30-60min shows, but with this BTCC recording, it appears to mark it a bit too early.

maybe use % but up to a maximum of, say, 4 minutes? 2 minutes would probably be plenty.

Just a bit of feedback on that one

 

We'll look at improving that. Thanks for the info.