Problems With Live TV Recordings Stopping Early

[hamah 7]

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 42077]

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

[Carlo 4560]

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 7]

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, 2025 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 7]

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 42077]

Hi, are you still having an issue with this?

[hamah 7]

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 42077]

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.

[hamah 7]

ok, I am still having issues with Live TV Recording terminating early.

I have tried again by recording The Open Championship Day 2 (Friday). I set it to record the program after it had started and the recording terminated prior to the scheduled ending. No padding of start or start times were used. I simply searched for the program in the guide and selected Record vs. Play. The program was scheduled from 4PM-9:30PM. The program recording stopped prematurely at 7PM. I had done a few things I thought might have impacted the results so I did not capture screenshots or logs for this recording.

Things I did that I wondered about impacting the recording were to start to watch the recording as it was happening and to rewind it to the beginning. Is it possible to watch the same program as it is being recorded? Can you rewind to watch from the beginning as the program continues to record? Can you then FF to "catch up" to the recording? While this is typical for STB-type DVRs  I wasn't sure if if you could with Emby. I think I was also was watching a different Live TV channel/program while recording. I do have 2 separate feeds each with a different M3U. Would this be a problem?

I then decided to try to set a Series recording for Day 3 (Saturday) and Day 4 (Sunday). These was done using the standard "Record Series" from the Guide search results. Again no time padding was done for start or stop times. All options were left as default. The program was scheduled to run from 4AM-12PM but terminated at 10A (last modified Date shows 10:00:07).

I have attached recording conversion and Emby server logs for today's event. While I'm not sure it's relevant, I also attached a ffmpeg-directstream log.

Day 4 (for Sunday) still shows as scheduled for recording. Perhaps I should try to manually set the channel and record start/stop times rather than using the guide? 

embyserver.txt recording-conversion-12342385-5c49-482f-9344-b39fb58823e4_1.txt ffmpeg-directstream-b9d31eae-271f-44db-a396-7aee137c5ada_1.txt

Edited July 19, 2025 by hamah

[TMCsw 246]

Is it possible the drive you have  'transcoding-temp' on gets filled up? When that happens emby will stop recording (yes recording use this space while the show is still recording) and will usually free up this space after a bit, so it can be hard to see that this may be your problem...  if that is the case you need to find a more space for this directory (use a ssd for best speed, but a good old HDD with ample free space may serve you better).

[hamah 7]

Thanks for that idea. Emby server (4.8.11) is installed as a package on my Synology DS423+ NAS. I have a single volume with just under 3TB available.

[hamah 7]

The Open Day 3 recording stopped 2 hours early (logs previously provided)

The Open Day 4 that was scheduled to record as an episode in the series today failed as the channel was offline.

Last night I tried another program recording. UFC 813 on TNT Sports 1 was scheduled using the guide from 7PM-11PM July 19 and appears to have completed successfully based on the recording name and the last modified date of the recording in the file system. Again no padding for start or finish was added nor were any other options changed. While this doesn't prove much at least it shows that under certain conditions the guide and/or M3U does work. I've attached a few logs that I think are relevant to this recording. 

As of now I've no idea why the recording for Day 3 of The Open (previous attempt logs are attached above) terminated prematurely. The Day 4 scheduled recording only had 2 minutes showing the channel to be offline (which is understandable). I will try Day 4 again using scheduling from Search (and the M3U?) . The search results show that on TSN 2 there is re-run coverage  from 8PM to 11PM tonight (Sunday July 20). Based on the results from recording UFC 318 last night I suspect this will be successful (assuming the channel is online of course). 

I'm also going to randomly record a channel for a 7 or 8 hour duration using Channel and Time rather than Search or Guide. So far I don't think I've ever successfully recorded an event longer than 4 hours using any of these 3 Create Recording options (the 6 hours recorded for Day 3 stopped early).

I'll update this thread after these recording events are completed. 

embyserver-63888566400.txt embyserver.txt recording-conversion-b836eb24-5b2e-4f0c-af24-8685cffee362_1.txt

[hamah 7]

Well, the long recording test failed (logs attached). The recording was set for 11:50A-7:50P today (Sunday July 20). The resulting recording was 1:22 which should mean the test failed around the 1:12PM mark. Interestingly the last modified time was 2:46PM so a lot was happening after the recording stopped and the file was finally closed. I noticed the same Seek to start message in the recording-conversion log that Carlo had seen back in April.

I'm suspicious that the issue is simply an unstable IPTV service but I don't know enough about what is going on or how to read the logs to tell for sure.

I'm going to try again later tonight or tomorrow. I'll also be trying to answer some questions I have on recording multiple shows at the same time and playing one show while recording another show etc. Let me know if there is any more info needed or specific testing you would like me to try.

I will still post the results of the Day 4 recording that was scheduled for later tonight using the Create Recording / Search option

embyserver.txt recording-conversion-84866efd-9cab-4768-80f8-1aa4627aa2ac_1.txt

Edited July 21, 2025 by hamah

[hamah 7]

The Day 4 recording created from Search, which was to record from 8PM-11PM, terminated early. The recording went for 2.25 hours instead of 3 and  terminated at 10:15. Logs are attached. I'll wait for feed back before attempting anything further.

embyserver.txt recording-conversion-8769dccf-4dd8-41a5-918d-6d40ffdb8845_1.txt

[Luke 42077]

On 7/21/2025 at 2:05 AM, hamah said:

The Day 4 recording created from Search, which was to record from 8PM-11PM, terminated early. The recording went for 2.25 hours instead of 3 and  terminated at 10:15. Logs are attached. I'll wait for feed back before attempting anything further.

embyserver.txt 78.05 MB · 1 download recording-conversion-8769dccf-4dd8-41a5-918d-6d40ffdb8845_1.txt 962.45 kB · 1 download

Does your provider have an mpegts output option? That would make things a lot simpler.

[hamah 7]

17 hours ago, Luke said:

Does your provider have an mpegts output option? That would make things a lot simpler.

They do not

[Luke 42077]

OK we are looking into it. Thanks.

[hamah 7]

It turns out that there are MPEG-TS URLs for both of my IPTV services after all. Was there something you'd want to test? or have me check out. I was told that the M3U is the preefered option for "unreliable" (Internet) delivery.

[Luke 42077]

HI, yes I would give that a try. Thanks.

[hamah 7]

On 8/1/2025 at 11:08 AM, Luke said:

HI, yes I would give that a try. Thanks.

Have you had an opportunity to look into this further? I did try using MPEG-TS for a 3 hour scheduled recording....I got 6 minutes before it stopped recording. I've attached the log for this latest attempt.

Any help would be appreciated as Live TV DVR functionality is pretty key (to me anyway).

 

Thanks

embyserver.txt

Edited September 13, 2025 by hamah

[Luke 42077]

On 9/13/2025 at 1:33 AM, hamah said:

Have you had an opportunity to look into this further? I did try using MPEG-TS for a 3 hour scheduled recording....I got 6 minutes before it stopped recording. I've attached the log for this latest attempt.

Any help would be appreciated as Live TV DVR functionality is pretty key (to me anyway).

 

Thanks

embyserver.txt 83.58 MB · 0 downloads

Hi, does it only happen if you play the recording in progress? Just trying to narrow it down.

[hamah 7]

no. I've set it to record and left it alone and watched it record in progress. 

[Luke 42077]

OK. Are you still having an issue with this?

[hamah 7]

20 hours ago, Luke said:

OK. Are you still having an issue with this?

Yes, while I haven't done further testing than what I show above I was still having the issue last time I tried (leaving the recording in progress alone and not trying to play it while recording).