Live TV Not Staying Running

[skillsjr123 2]

Hello Everyone.

The issue I'm facing is revolving around Live TV on my Emby Server. The problem is that the streams can't stay running consistently. The streams will suddenly freeze up and I have to back out of the channel and then come back in. It will then freeze up again after some time has passed. It's not a consistent time, but happens what seems randomly. I'm trying to deal with it, but I can't really get logs too often. It also have the issue where streams sometimes won't stream at all, but instead keep trying to load and won't come through. It's only after I restart the server that they actually start playing again. From what I can tell, the link is fine cause I can stream the channels without any issues and no disconnects/freezes. It's only when doing it through Emby that I seem to start having issues.

Anyone have any ideas?

ffmpeg-directstream-0901fae1-0e91-4d1d-b6ef-6f6178debe9f_1.txt ffmpeg-directstream-55797273-d464-432e-b5c1-e5cad125a0c1_1.txt ffmpeg-transcode-aaaba7c9-56dd-4ae5-b881-4e6a82f1a232_1.txt embyserver.txt

[Luke 42077]

Hi, are you able to play in the Emby web app?

[skillsjr123 2]

I've tried it in the web app as well. It will still freeze there as well. @Luke

[skillsjr123 2]

The platforms I've tried it in is: Roku, Fire TV, Android TV, Android App, iPhone App, and Web App.

[Luke 42077]

OK we are looking into this. Thanks.

[skillsjr123 2]

On 1/8/2025 at 1:39 PM, Luke said:

OK we are looking into this. Thanks.

Do you have any updates on this @Luke?

[Luke 42077]

On 1/26/2025 at 11:01 PM, skillsjr123 said:

Do you have any updates on this @Luke?

Hi, we're still looking into it. Thanks.

[skillsjr123 2]

Ok I have a follow-up @Luke. I'm still facing the issues with the Live TV function of my Emby Server. Here's what I've done to try to troubleshoot it thus far:

1. Disabled and enabled hardware acceleration (This didn't appear to have any effect)
2. Turned up the "Constant Rate Factor" of my two encoders (H.264 and H.265) (This didn't improve the freezing, just made the quality look slightly worse)
3. Forwarded port 8920 (8096 was already forwarded) even though my server install doesn't use HTTPS, figured I'd still try it (this didn't fix anything)
4. Edited my router for a couple settings:
   1. Disabled my IGMP Proxy (this didn't seem to have any effect)
   2. Edited my IGMP Version to force V3 instead of V2 (this didn't seem to have any effect)
   3. Enabled QoS and forced my server to be prioritized above everything else (this didn't seem to have any effect)
5. Upgraded my server off of the stable version and onto the latest beta version (I use a docker container for it in Unraid).

Upon looking at the logs again, I found that every so often, it needs to open what looks like an auth link, then will open an hls link directly afterwards twice (as seen below):

 

However, at the end of the stream when it freezes I get the auth, but no hls like above:

 

I had noticed this happen almost every time the stream freezes on me, so I installed Wireshark as a docker container and tracked all the traffic on the host. Here's what I saw for the communication between my server and the IPTV provider when I opened the channel to start watching (everything crossed out in blue is my IPTV provider and the red is my server LAN IP):

 

Here are some tcp.streams from the above graphic:

tcp.stream 15:

tcp.stream 18:

tcp.stream 19:

 

Here is what I can see later on down the line just before the Live TV fully connects and starts playing:

 

This looking at a single TCP stream at the beginning of the stream:

 

I see that very often there are large chunks of duplicate packets that get sent between my host and the IPTV provider:

 

The Dup ACKs move all the way up to 145, and then reset themselves again:

 

It will also report multiple streaks of packets being received by my host Out-Of-Order every so often as shown below:

 

Here is what it looks like at the end of that TCP stream:

 

Here is what that traffic looks like outside of that TCP stream (Green is my TV that I was watching it on and White is my router):

 

This is what it looks like at the end of the stream when it freezes (Yellow is the Docker Container IP):

 

The following are some notable TCP streams from the above image:

tcp.stream 128:

tcp.stream 129:

tcp.stream 130:

tcp.stream 131:

 

Basically the way I'm seeing it is that tcp.stream 128 persists while tcp.stream 129 and 130 try to reauthenticate. However, they obviously don't and then we are left with tcp.stream 131 which is where the stream freezes. I'm unsure at this point as to what exactly is causing this issue. It could be the provider, but it could also be something within Emby that can't find the site after a certain amount of time and the auth never gets finalized. The strange thing is that sometimes it will go 5 minutes before a freeze and sometimes it will go 4 hours without a freeze. Here's my full workflow as of now:

 

I have Emby Premium with a Lifetime Subscription. I use it for IPTV mostly. I have two IPTV links that come in from the same provider and get combined into IPTVBoss (with Emby Support) to help me with the EPG integration. It then exports the M3U and XmlTV links to Dropbox. I use those two links as the TV and Guide Data Sources for Emby.

 

Based off of all the info I have within this post, what are your thoughts as to the cause of my freezing. I've waited very patiently for almost 1.5 months since my original post, but both myself and my users are getting very frustrated at the freezing that occurs. At this point, do you think it is your application (Emby), IPTVBoss, Dropbox, or my IPTV provider that is causing this issue?

 

Please let me know when you can. Thanks.

[skillsjr123 2]

@Luke @Carlo I've seen you both talking about this in other posts. Could someone take a look at this most recent data from me? Maybe it could help out? If it truly is Emby causing this problem, then that's fine and I'll continue to wait for a solution. However, if it is one of the other parts of my setup, then that's fine too. I would just like to know so I can pursue the other vendors if it's them that's causing the problem. I'm only trying to help any way I can so we can get this resolved, which is why I spent 4 hours gathering data and writing the previous post. It's been 2 weeks since my most recent update and it's been radio silent, which makes me think that all the time I spent on it went to waste.

[Luke 42077]

@skillsjr123are you still having an issue with this? I notice your logs always end with a 404 response. I think this means one of two things. Either the stream url changed on the fly and is no longer valid.

Or, more likely, it could be a defensive measure from your provider and a form of them blocking you. For example maybe there's something happening that they don't like, such as too many connections coming from Emby (via ffmpeg), and so they just pull the rug out and block all use of that stream and start sending back 404's. That seems most likely to me right now.

[skillsjr123 2]

@LukeYes, I am still having an issue with this. It does seem to be very random. I'm glad you specified though. I'll reach out to my provider and see what they say. I'll give you an update when I can.

[Luke 42077]

Please let us know what they say. Thanks.

[skillsjr123 2]

Ok so here's the finale for everyone still wondering. @Luke

I had attempted to reach out to the provider, but they weren't working with me. So I worked with IPTVBoss' discord community to get this solved, so shoutout to them. As a troubleshooting step, I had originally tried Plex to see how that worked, but they still had the same issue. So I had also tried to add a tuner as well (Threadfin), but that also didn't stop the freezing from happening.

It was then mentioned to attempt to add m3u8 to the end of my input link from the provider, instead of hls. Changing this did help, but I still had the occasional freeze here and there. I also started to get the following in my logs:

"[q] command received. Exiting."

 

I ran it past everyone in the discord and they all said that should usually only ever come up when you purposely exit your stream (which I was not doing). At this point I was not using a tuner, and instead was taking the stream directly from IPTVBoss. I use Roku TVs, which from what I read from your various forum posts seems to not be as supported as others at this time. So I made some changes to the settings of the App in hopes of fixing this:

1. Changed the time format from 24 hours to 12 hours AM/PM
2. Changed the video quality from "2160P 4K(UHD) - 110 Mbps" to "Auto"
3. Changed the "Are you still watching?" prompt from "Yes" to "No"
4. Changed "Allow HEVC at 60FPS" from "No" to "Yes"

These changes allowed the stream to run with a freeze every hour or so. I had found a post that mentioned to use HLS-Proxy as a middle-man from Threadfin to Emby, but everyone else said that shouldn't be necessary as none of them needed it. It was then asked if I had a reliable system, but I said I definitely did per this exact post:

"I have a R720 Dell server running Unraid.

I have two Xeon E5-2690 chips with 8 cores/16 threads (16 cores/32 threads total). This alongside 92 GB of DDR3 ECC RAM. Also run dual power supplies on it.

There are six 10TB drives total. I run two of the drives in parity and have 40TB of usable storage. I eventually plan on expanding with another two 10TB drives for a total of 60TB of usable storage.

I run no graphics card on my server currently. As of now, I've never needed it. My server was handling 10 transcoded streams at one time before with Plex without any issues, so I don't think server power is the problem.

As for internet, I have 1 Gbps UP/DOWN and it is quite reliable. Luckily it's a local internet company and it's only gone down once in the last year."

 

They agreed that my hardware/internet should definitely not be the issue here. It was mentioned to try using FFMPEG commands to test my connection, but that, too, barely held a good connection at all. So the final thing I did was to change the way IPTVBoss accepted my stream link. It was changed from a single M3U link to XC authentication. This allowed me to actually choose TS as an output option instead of changing the end of my provider link. As a result, my logs completely changed how they looked and no longer have an hls auth link every 4-5 minutes. It showed a solid stream that only asked for Authentication at the beginning of the log. It was also very reliable, as I could now run streams that were usually not reliable at all (crashed every 5-10 minutes).

I also had one more issue that I needed to figure out. I have multiple credentials provided to me through the provider. So therefore, when they were input in the following way:

 

They showed duplicates of every channel (even though all the channel numbers and guide data are exactly the same):

 

How I ended up solving it was the following steps:

1. Browse to each M3U and limit it down to the specific number of streams that were purchased for it.
2. Browse to each M3U and set a tag to be added to all channels (IPTV1, IPTV2, etc..)
3. Browse to each user that you have granted access and limit their number of streams to the amount you'd like
4. Go to Parental Controls for each user and set that tag as an allowed tag

After that, all the channels showed up as a single channel and not duplicates.

 

So that's the gist of it. Hopefully this info can be used to help people in the future.

Edited April 6, 2025 by skillsjr123

[pdclark 10]

8 hours ago, skillsjr123 said:

It was changed from a single M3U link to XC authentication. This allowed me to actually choose TS as an output option instead of changing the end of my provider link.

Can you please explain this part further? I too frequently end up with 5 minute recordings as a result of 404 errors. Thanks

[skillsjr123 2]

5 hours ago, pdclark said:

Can you please explain this part further? I too frequently end up with 5 minute recordings as a result of 404 errors. Thanks

Ok so I'm going to assume you use IPTVBoss in this instance. Here's my understanding of how this all works:

You buy the provider's stream and they send you an email with your login details. That will have two different sets of items listed. One will be the Xtream (XC) information (username, password, url) and the other will be the M3U link. This will ONLY provide the raw streams and will not provide the guide data. Sometimes they'll also give you EPG data with it, but that's rare in my experience.

You'll then want to input this link into an IPTV editor of some kind. I used many different IPTV editors and none of them really worked super well until I found IPTVBoss which is pretty reliable. Their program requires you to install it locally on something (Windows, Mac, Docker, etc..), as opposed to others who have websites dedicated to it. Regardless, these editors perform two functions:

1. They allow you edit the streams in the provider's link for only the streams you actually want. My provider gives me like 21,000 different channels from all over the world. I use the IPTV editor to cut it down to ~500 that my family and I would actually watch.
2. They provide up to date guide (EPG) data. You'll have to use their service to match up the streams to the specific guide data so it's listed properly when you use Emby to watch it.

For your question, I'm going to use my setup (IPTVBoss) as an example to more easily show what I'm talking about:

• When you first start out with IPTVBoss, you'll need to input a source for your IPTV:

• These sources allow you to input any of the following types of links: M3U, API (XC), or CUS. Previously, I had tried to use the M3U link given to me by my provider. Their links are structured as follows: http://provider-domain.com:80/playlist/username/password/m3u_plus?output=hls. My link (with all the important stuff taken out) is down below:

• When you use IPTVBoss to input the links, it'll give you the following for providing the M3U source:

• When I used it previously, I just filled in the Name and source link fields. This was due to my username and password being embedded into the M3U link. Whatever you do for the rest of the fields is personal preference. This is what was causing my issues with the 404 error/freezing. One step that I used to attempt to fix this was changing my output from hls to m3u8. This forces the stream to be converted from HLS to TS (MPEG-TS). Here's essentially what this means for your stream:
  
  -HLS - This takes the stream from the provider and delivers it to the device playing the stream in roughly 10-second segments. The device watching the stream would then put all of the segments back together again and then allow you to watch the stream. This allows the stream on the receiving device to adapt based on the network conditions of the home it lives in. This also allows for the stream to be supported on many different devices due to the protocol (HTTP) being so widely supported. However, it can create latency and doesn't support many Codecs.
  -TS - This takes the stream from the provider and delivers it to the device playing the stream in a single stream. This is the most stable version of receiving the stream, but does not adapt to changing network conditions. This is the version that all of the people in the IPTVBoss discord recommended as they said HLS is far too unstable to provide a good experience.
  -Think of it like this. The provider is capable of sending the stream in three different qualities:
  1 - Lowest quality
  2 - Medium quality
  3 - Highest quality
  -HLS is capable of adapting and switching between the three based on your changing network conditions. TS will only come in as the medium quality, but will be one solid stream.

 

• My first iteration of adapting this was to take the link from the provider and change the output=hls to output=m3u8. From the logs I could tell that the stream was coming in as TS, but the issue was that it was still using HLS for authentication as if it was still coming in as an HLS stream. I was still getting freezing and it was buffering often. So instead, I changed it to use the XC link instead. Here's what that looks like from IPTVBoss:

• Here you can actually specify the server itself and the username/password separate from each other. From the logs in this setup, there won't be any authentication during the stream. This provides a single, uninterrupted stream that is reliable and stable. From here, IPTVBoss will export your edited channels/guide data to Dropbox as an "Application" within Dropbox. You'll then use the two Dropbox links (provided by IPTVBoss) to be input into Emby for your stream.

 

And there you go, that's essentially how I got it to work without any buffering/freezing/404 errors. Try that out and let me know how it works. I'll happily answer any other questions you have as well. Thanks

[pdclark 10]

Thank you for the detailed explanation!