Live TV Buffer Setting?

[EmYaj 25]

Is there anywhere in the settings or files where a buffer for livetv streams can be set?  I'm not sure what it is by default, it seems like maybe just 1 or 2 seconds, but I've had some issues where cpu usage spikes (unrelated to emby) for a few seconds can cause issues and if I could increase the live tv buffer to something a little bit higher it would probably be able to absorb these short spikes in cpu usage.

[Luke 42077]

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[838Joel 63]

I'm interested since I have some issues also! I'll keep an eye on this thread!

[EmYaj 25]

10 minutes ago, Luke said:

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

could be a little trick to catch this happening but I'll do my best and report back. 

Does the "enable throttling" setting have an effect on live tv "converting to a compatible container" ?

I'm guessing its safe to assume that theres no setting for buffer length of livetv?

[kikinjo 281]

there is no live tv buffer setting

[EmYaj 25]

5 minutes ago, kikinjo said:

there is no live tv buffer setting

thanks for letting me know.  it seems to try to hold a few seconds so maybe its just hardcoded or whatever... was hoping it'd be a hidden setting in a file somewhere

[EmYaj 25]

7 hours ago, Luke said:

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

Hey, livetv is freezing a lot right now - It's weird because glances is reporting emby using 100% cpu but theres plenty of cpu to spare.  When Plex is busy, this value will go up to 300-400%  but Emby never seems to use more than 100%.  This value is reported by glances, I'm not sure exactly how it is calculated.   I've included a screenshot and also a screenshot of htop showing 100% cpu but also showing that the cpu is not 100% utilized.. again, not sure exactly how these are calculated and other apps seem to be able to use several hundred %'s.  Emby is hitting some sort of artificial limitation that I'm not sure where it comes from.  Attached logs as well.  Hopefully someone can point me in right direction.  Thanks!

Emby is running in a docker container on Ubuntu 22.04 and on latest version of Emby server 4.8.6.0

embyserver(10).txt ffmpeg-directstream-3b2f9c2e-7366-47cc-a684-fc6b7a736ea2_1.txt

Edited May 16, 2024 by EmYaj

[EmYaj 25]

Quick update - everything mentioned above only seems to be an issue with livetv specifically - I have several people watching livetv.  I have all user accounts set to allow audio transcoding and allow changing of container formats but i do not allow video transcoding.

just as a test i enabled video transcoding on my own account and for the first time I saw emby using 500% cpu but if I open a whole bunch of livetv streams to point where they start to fail, the emby process maxes out at 100% just like described above.  Is it possible that something to do with livetv and/or the changing containers process is limited to single core for some reason?

[EmYaj 25]

Apologies also - I attached the wrong ffmpeg log above.  I believe this is the correct one that had the issues.jammin1911-ffmpeg-directstream-e3a6b847-37f6-4810-a3f1-b5ffc5019251_1.txt

[Q-Droid 989]

The Live TV buffer adjuster is called the "skip back" button. Think about it, if you want a longer live TV buffer that means an even longer startup for the stream to play. By that I mean longer than it already is.

 

[Q-Droid 989]

9 hours ago, EmYaj said:

Quick update - everything mentioned above only seems to be an issue with livetv specifically - I have several people watching livetv.  I have all user accounts set to allow audio transcoding and allow changing of container formats but i do not allow video transcoding.

just as a test i enabled video transcoding on my own account and for the first time I saw emby using 500% cpu but if I open a whole bunch of livetv streams to point where they start to fail, the emby process maxes out at 100% just like described above.  Is it possible that something to do with livetv and/or the changing containers process is limited to single core for some reason?

Live TV is a single stream with no read ahead. I would think it's difficult to multi-thread a process with a slow single stream source. Difficult or wasteful. I doubt there's anything to gain from multithreading.

Edited May 16, 2024 by Q-Droid

[Q-Droid 989]

Do you have enough up and downstream bandwidth to handle the number of users? Is your transcoding temp path location local (host), network (NAS), slow (HDD) or fast (SSD)?

There's no transcoding going on, just stream copy so the CPU overhead looks pretty high.

[EmYaj 25]

1 hour ago, Q-Droid said:

Do you have enough up and downstream bandwidth to handle the number of users? Is your transcoding temp path location local (host), network (NAS), slow (HDD) or fast (SSD)?

There's no transcoding going on, just stream copy so the CPU overhead looks pretty high.

Thanks for all of the responses Q-Droid!  Cache and Temp are on an SSD, it's a slow'ish one that benchmarks around 550MB/s but I believe should be OK.

To clarify this is multiple Live TV streams, probably around 8 of them when the logs and screenshots were taken.

After looking at it for a while, there is one particular process that seems to be the culprit.  In my htop screenshot above, the process at the top of the list seems like some sort of "main" emby thread even though it looks the same as the rest of the ffmpeg processes.  Even when the server is completely idle with no streams, this process stays alive. (You can see in the screenshot it has used dozens of hours of CPU time and it was restarted within the last couple of weeks).  It seems like what is happening is as more streams are started by users, this process uses more and more CPU up to a maximum of 100% (or the equivalent of 1 core).  All of the other processes seem to be free to use over 100% if needed, but they also only tend to last minutes or hours (as you can also see in the screenshot).   

What is this main Emby/ffmpeg thread and is it possible that for whatever reason it is limited to 1 core?

[Q-Droid 989]

That would be the main parent process for the Emby server. When you say alive do you mean busy or just running? It will run for as long as the server is up. If you restart Emby another with a new pid will take its place. 

Let's say you're using an IPTV provider. If not then disregard the WAN downstream portion. When you have 8 streams going it has to pull 8x bitrate (aggregate, assuming similar streams) from WAN, write 8x bitrate and files  to temp, read and write 8x bitrate and files for segments, read 8x bitrate from segment files  and send 8x bitrate to users, LAN or WAN. Some of the reads/writes/reads can use file cache though the I/O operations are still happening. This amount of work means any weak link in the chain can introduce a bottleneck. The bitrate itself is usually not a problem, it's a trickle for most resources but you could have many small operations which are less efficient than big ones. 

[EmYaj 25]

18 minutes ago, Q-Droid said:

That would be the main parent process for the Emby server. When you say alive do you mean busy or just running? It will run for as long as the server is up. If you restart Emby another with a new pid will take its place. 

Let's say you're using an IPTV provider. If not then disregard the WAN downstream portion. When you have 8 streams going it has to pull 8x bitrate (aggregate, assuming similar streams) from WAN, write 8x bitrate and files  to temp, read and write 8x bitrate and files for segments, read 8x bitrate from segment files  and send 8x bitrate to users, LAN or WAN. Some of the reads/writes/reads can use file cache though the I/O operations are still happening. This amount of work means any weak link in the chain can introduce a bottleneck. The bitrate itself is usually not a problem, it's a trickle for most resources but you could have many small operations which are less efficient than big ones. 

Yea it is definitely a hardware issue, something is bottlenecking but still at the end of the day why would this main parent process for Emby be capped at 100%/1-core like it seems to be?  When the server is slammed and having issues, this process will *always* be jumping around between 95-105% and never more.  This seems to be the root of the issue.  I could try switching to an nvme drive but I'm not entirely convinced that this is not a cpu threading issue because of it getting stuck at 100% (out of a maximum 800%) every time its busy....

[Q-Droid 989]

You already have threads showing in the output and they are busy too. While the trascoding itself (or remux) per stream might not be  parallelized those individual sessions may be threaded so no need for the main server process to carry the full load of all sessions. The bottleneck could be something else that needs to be found.