Problems With Live TV Recordings Stopping Early

[iON22 0]

In case it is helpful, I too have seen very similar behaviour (virtually exactly as Hamah has described) and it has occurred inconsistently over the past 3 or 4 months.

My setup includes Emby on a Mini-PC server used solely for Emby with a dedicated internet connection. In other words, there is one modem that is used by Emby and all other internet traffic in the house is through a second modem and account. There is a VPN running on Emby server, but I have tried two different VPN companies with the same results.

As I said, it is inconsistent and unpredictable. For example, on Saturday Nov 1, 2025 I attempted to record 3 hockey games (at different times, not concurrently) and they ALL crapped out after 19mins, 43mins, 9mins. I wondered if it was due to the high demand of streaming a hockey game, but it also occurred (and has in the past) during the recording of the pre-game show that same day. 

Then, last night (Nov 2, 2025) I setup a test to record a hockey game between 1am and 3am and then 4 thirty-minute episodes of a sports highlight program in the hours after. All of them recorded successfully in full. In the past I have wondered if it might be due to high server demands so I have conducted other tests in the middle of the night when server demands would be low, but I see similar failures with recordings.

I don't want to hijack Hamah's excellent reporting and feedback, but if there is something specifically I can provide to assist I am happy to do so.

Is there something that I could search for in log files to see if it appears and to keep an eye for?

[Luke 42077]

@iON22

HI there, can you please provide a specific example?

How to Report a Problem

Thanks !

 

[iON22 0]

I am sorry Luke, I thought I did site a few specific examples. I have read the "How to Report a Problem" a few times already and I am unclear on how I can describe my process more specifically when the programs I recorded are now in the past.

I do not recall the specific channels, however, the unsuccessful program recordings I cited were all on Nov 1:

1. 6:30pm - Sporstnet 1 - Hockey Central
2. 7:00pm - SportsNet 1 - Toronto Maple Leafs vs Philadelphia Flyers
3. 7:00pm - SportsNet 360 - Montreal Canadians vs Ottawa Senators
4. 10:00pm - SportsNet 1 - Chicago Blackhawks vs Edmonton Oilers

The programs I did record successfully were on different channels I do not recall and they were done between the hours of 

Can you be more specific about what you need to know?

I don't know if you want to see logs but I can tell you I do not see any log files (none) between Nov 1, 2025 12:39pm and Nov 1, 2039 10:31pm. I see ffmpeg_directstream at 12:39pm and the next log is titled embyserver-63897638400.txt. 

[Luke 42077]

HI ,the logs would tell us if it tried to record, how long it recorded for, why it might have stopped early, etc.

[iON22 0]

Hi Luke,

Sorry for my delay responding.

I have attached the Emby server log but unfortunately I do not see any ffmpeg-directstream logs for around the time I mention (Nov 1, 2025 6:30pm thru 10:30pm).

I do see some Error Reports in that file but I am not able to decipher them.

This behaviour was witnessed again last evening (Nov 5) between 7pm and 11pm. In case it helps, there was another scheduled recording that successfully recorded for the full 30 mins at 6:30pm.

If this caused by a poor internet stream, I was wondering if it is possible to instruct the record function to re-connect and re-start the stream a set number of times before abandoning the task?

 

embyserver-63897638400-Nov 1 2025 10pm.txt

[iON22 0]

Also, I have a copy of the file that was created for the 6:30pm - Sporstnet 1 - Hockey Central recording in case you can use it to analyze what happens during the recording process. 

This file is interesting to me because Emby shows it as 3mins long, however the file is 1.9GB which seems excessive to me. The file starts to play, bu then freezes and and just buffers at the 2:42 minute mark.

However, because of the size of the file it may be difficult to upload.

[Luke 42077]

Hi, by any chance did you play the live recording while it was happening? Also was there a recording conversion log?

[iON22 0]

Hi Luke;

My sincerest apology. I have been travelling and have not been able to respond.

I am not sure if I tried to play and record at the same time, but it is very possible. I can't say for sure. I also may have tried to watch something else while the recording was going on.

The logs from that day are gone. I believe I did save all the logs for that day (Nov 1) around that time (6:30pm - 7:30pm). I see a number of logs titled "hardware detection" and a number of them named "ffmpeg-directstream".

I have attached a bunch of them in case they can be helpful. 

hardware_detection-63897966775.txt hardware_detection-63897967873.txt ffmpeg-directstream-daf5d1ea-2fc2-4116-9f1f-4877d3a01a26_1.txt ffmpeg-directstream-2629e7eb-df9c-4393-8bbf-ab342dfbe118_1.txt ffmpeg-directstream-34870516-5326-4cb2-b34c-358db5d0459f_1.txt ffmpeg-directstream-ba6f4d68-8fbc-404f-abd0-ef80b6199d33_1.txt embyserver-63897967635.txt hardware_detection-63897967667.txt ffmpeg-directstream-dcbe56e8-5ef7-43a0-8097-7413843b0a0c_1.txt ffmpeg-directstream-f99affdf-1c6a-426f-893e-c37ca1bc4235_1.txt ffmpeg-directstream-6335c2ba-dd0f-4e82-843c-2241c4c94c0a_1.txt embyserver-63897967835.txt ffmpeg-directstream-d8c30872-f5ad-49bf-8b76-eb454da82ebd_1.txt ffmpeg-directstream-b7e8c11f-1369-41e5-b3d4-7672b4371744_1.txt ffmpeg-directstream-783a2cbd-2040-4f3c-ad2c-5c4e1d2f6d40_1.txt ffmpeg-directstream-5c2c25f8-b0af-45ff-ab23-8b1dcce5c68f_1.txt hardware_detection-63897980969.txt hardware_detection-63897967468.txt hardware_detection-63897966674.txt

[iON22 0]

Any progress with this?

I am still experiencing routine drop off of recordings. This past Saturday, every NHL game I recorded dropped off a short time into the recording.

[iON22 0]

Any progress with this Luke?

Also, can you clarify how this works. I was replying to Hamah thread also titled "Problems With Live TV Recordings Stopping Early" but now they seem to be separated into two threads. Is this common? Did you separate them?

[iON22 0]

To try and avoid the anticipated issues with longer recordings, I split Saturday Hockey Night in Canada (HNIC) games into half our segments starting at 7:00pm EST through to midnight. I also scheduled a few other 30min programs (news, talk) both on Saturday night and Sunday..

Every single recording (I believe) I scheduled over the weekend (sports, news, or talk) was cut short and they all lasted anywhere from only a few seconds to a few dozen minutes. 

I was not watching while recordings were done.

For what it is worth, tests I conducted by setting up Channels DVR did not fail.

I have attached logs in case they are useful.

Then, I scheduled a couple of recordings for the early morning hours overnight and they both recorded fine in there entirety. One was 35mins and the other was 2hrs and 31mins, so go figure.

embyserver-63901267200.txt hardware_detection-63901240959.txt hardware_detection-63901236583.txt hardware_detection-63901236564.txt embyserver-63901180800.txt hardware_detection-63901226251.txt hardware_detection-63901240978.txt

Edited December 15, 2025 by iON22
Added add'l info on succesful recordings

[Luke 42077]

Hi, can you find out why your provider is sending back a 555 response error code?

2025-12-13 01:13:52.289 Info HttpClient: Http response 555 from http://host4/x_path1_x/x_path5_x/x_path13_x/x_path14_x after 97ms. Headers Access-Control-Allow-Origin=*, Date=Sat, 13 Dec 2025 06:13:53 GMT, Server=Apache2, Transfer-Encoding=chunked

 

[iON22 0]

Hi Luke,

I am waiting for a response from the provider to your question. 

This is beyond my "pay grade", as they say, but I would like to understand better so that I might limit the messages i need to bother you with. In other words, if I can become better at recognizing if the issue is with Emby or the server resource then i can avoid wasting you time or possible provide you with better information. So, if you don't mind:

1. The 555 error code would be coming from my IPTV provider NOT my internet access provider. Correct?
    
2. A quick read online seems to indicate 555 error code is not standard and therefore the server admin is the only one that could really say why that code was sent. Is that correct?
    
3. I see in your response and in several places in the log URLs that resemble ".....from http://host4/x_path1_x...." The URL domain ('host4' or host2') is clearly not normal so I suspect that is a result of the "Anonymize log contents" in Emby log page. Is that correct?
    
4. Are you suspecting that recording stoppages might be a result of detecting a stutter or stream interruptions? If so, could the stoppages be delayed until a longer disconnection (or a larger number of disconnections) were detected?

It might also be important to mention I use a VPN with WireGuard Protocol but I have also tried OpenVPN UDP and TCP with little difference. I have tried various VPN providers as well.

[Luke 42077]

Quote

The 555 error code would be coming from my IPTV provider NOT my internet access provider. Correct?

Yes.

[Luke 42077]

Quote

A quick read online seems to indicate 555 error code is not standard and therefore the server admin is the only one that could really say why that code was sent. Is that correct?

Yes correct.

[emveepee 132]

The http 555 errors have been showing up in Kodi recently too for some XC users from different providers.  No user or provider is offering any explanation what the error means.

[Luke 42077]

@iON22 did you find anything about that?

[iON22 0]

I did ask the provider but the response was useless. I could not decide if the response seemed evasive as if it was a secret, or the agent was just inept and unaware.  

I have not had time to tinker with recordings much through the christmas break but I did just look at the log files I have available (just covering the past few days) and there was one Response 555 error. Unfortunately, I am not sure of when I conducted last recording.

Is it possible these could be sent if my system makes too many concurrent connection attempts. My provider only allows 2 concurrent connections but it is possible I had attempted to exceed that with schedule recordings or watching via different player apps.

[Luke 42077]

Quote

Is it possible these could be sent if my system makes too many concurrent connection attempts.

It is possible, yes.