Problems With Live TV Recordings Stopping Early

[hamah 6]

This past weekend I wanted to record all 4 days of The Masters golf tourny. Each day I would schedule a recording that should have been for the entire broadcast that day plus padding at the end to make sure I didn't miss anything. Maybe 5 to 7 hours per day. Everyday I ran into problems and the recording would be terminated short of the expected end time. While I wasn't able to capture anything from the first 2 days I did grab some screenshots and logs for the last 2.

What caused these failures? Something I did? Perhaps a scheduled recording can't be set for that long? Maybe by starting to watch the live channel as it's being recorded caused the recordig to. terminate? Any help would be appreciated.

 

The scheduled recording for April 12 for 7 hours

The resulting 6 hours recorded of 7 scheduled

 

While I didn't include a screenshot of the recording scheduled for April 13 here is the resulting 39 minutes of the scheduled 7 hours.

 

The logs:April 12 recording-conversion-c3c51bdc-bc51-4abe-bfd8-e3f6daa239ef_1.txtApril 13 recording-conversion-25f185fc-8b24-422c-b096-02bb2c01407d_1.txt

 

[Luke 40086]

HI, please attach the main emby server log as well. Thanks.

[Carlo 4552]

April 12th, it looks like it recorded 6 hours (05:59:57.71 technically).

17:00:03.494 [hls @ 0x2600a40] Failed to reload playlist 0
17:00:03.495 elapsed=05:59:57.51 frame=647460 fps= 30 q=-1.0 size=15081216kB time=06:00:03.55 bitrate=5718.7kbits/s throttle=off speed=   1x    
17:00:03.495 [https @ 0x27da180] Opening 'https://RemovedURL' for reading
17:00:03.697 [hls @ 0x2600a40] Failed to reload playlist 0
17:00:03.697 Seek to start failed.
17:00:03.697 https://RemovedURL: Operation not permitted
elapsed=05:59:57.71 frame=647460 fps= 30 q=-1.0 Lsize=15081323kB time=06:00:03.55 bitrate=5718.8kbits/s throttle=off speed=   1x    
video:14339497kB audio:253414kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 3.346913%
EXIT

At 5pm the playlist no longer loaded, ending with an operation not permitted error. I'm betting the broadcast was over, hence the URL was removed.
If/When the playlist is no longer available, we should try the original link contained in the m3u as it may redirect to a different URL.
We should also check the recording schedule for the broadcast when we get a status of the playlist no longer available, to see if the provider removed it due to the broadcast being complete. In the case of channels using redirects or different URLs for each broadcast the concept of padding is useless once the playlist is removed.  This could also make pre-padding a bit tricky as well since the URL could/would change. The coding logic may need to keep trying the original URL in the m3u for the exact time it is and handle the missing/removed playlist dynamically.

 

April 13th, it looks like it recorded only 39 minutes and change (00:39:21.82) ending with this error sequence.

11:39:28.051 [hls @ 0xaf4a40] Media sequence changed unexpectedly: 5082 -> 0
11:39:28.051 elapsed=00:39:21.82 frame=70920 fps= 30 q=-1.0 size= 1676544kB time=00:39:20.36 bitrate=5818.7kbits/s throttle=off speed=0.999x    
11:39:28.051 Seek to start failed.

@Lukeis the "Seek to start failed" message in both logs Emby trying to load the beginning of the playlist for some reason which likely isn't available?

[hamah 6]

3 hours ago, Luke said:

HI, please attach the main emby server log as well. Thanks.

Here the 2 server logs that I hope will help. I used Channel and Time when creating the recording schedule and not Guide, Search, or Keyword. is it still possible that Carlos is correct and the URL was removed at the end of the scheduled broadcast time? If so I suppose my other option would be to split the recordings up into 2 parts to follow the regularly scheduled program times?

April 12embyserver-63880099200.txtApril 13embyserver-63880185600.txt

Edited April 16 by hamah

[JanS48 2]

Greetings - I'm a newbie here but in working 'a lot' on emby for the past month I've learned quite a few things. All IPTV providers are NOT created equal. I currently have two with very distinct requirements.  The 1st one I used allows for 1 connection at a time from any machine but the 1 connection I found only allows for 1 stream at a time so recording on one channel and watching another is a nada. As soon as you start watching one the recording 'sometimes' still continues but will skip and sometimes have repeating segments.
in looking at your post you may need to check with your IPTV provider and ask about connections and how many simultaneously connections you can have going on.
2) My second IPTV provider has a strict rule that you can only access from a given (device) mac address - the 1st one you use but the good news is they allow for 5 simultaneous connections/streams so it is possible get two flawless recordings while watching a different  channel. I can even have android clients view channels while recording.
I don't want it to sound like my recordings are great - they are not and I will be posting about that shortly.  I too have similar issues with recordings not respecting an extension of time or in my case they do not start at all. I'll be posting about that shortly.  My 2 cents for your situation check what your IPTV provider is providing you.
Jan

 

 

[hamah 6]

Thanks for your input. I have 2 services connected to Emby. Both allow 4 simultaneous streams and neither look at MAC so connections can come from anywhere. I see inconsistent results when recording. Sometimes the recording respects the time period scheduled and sometimes it does not. I provided the logs as requested but haven’t seen any follow up so I’m not sure what might be causing the issues. 

[Luke 40086]

Hi, are you still having an issue with this?

[hamah 6]

Hi Luke, to be honest I've not looked at it the issue lately. I had uploaded 2 server logs per your request hoping there might be additional info there that might help. I'll try to revisit this at some point soon.

[Luke 40086]

On 6/22/2025 at 3:15 PM, hamah said:

Hi Luke, to be honest I've not looked at it the issue lately. I had uploaded 2 server logs per your request hoping there might be additional info there that might help. I'll try to revisit this at some point soon.

OK that would be great, thanks.