Player Buffer Size

[pir8radio 1292]

So, my live IPTV sometimes freezes, i know why, some of the servers I get streams from have times where they stream slow for a few mins, either due to bandwidth, my wifi or whatever... 

 

But I was able to pretty much get rid of my issues by changing "Player Buffer Size" to Large...      I assume this is an ebr question, but why do you not default to large?   I don't notice any slower tuning time.. and i'm sure thats probably the reason to keep people from freaking out..   But My good channels tune just as fast,  my crappy skippy channels do take a few seconds longer to tune, but then I don't have freezing issues...   I would think people would rather have longer tune than the crap freezing ever x seconds...       

 

Since I know you wont default this to LARGE...   how about server side settings to force client side changes?    I have old people that dont know what to do, they get on a channel that skips and they are like F-This its broke.     lol    SO it would be nice for me to force this for all of my users...   

Edited April 20, 2020 by pir8radio

[ebr 14903]

As you pointed out, this does impact channel tuning - which is a major factor for most people.  If you have good streams, the larger buffer is not required.

[thegrunge 29]

I also have on my side some m3u8 links which do not give enough advance to the current reading, I have to pause a few seconds when I start the channel to correct the problem. However with vlc player this problem is not present with the same link. There would be no way to add buffering time of e.g. 15 seconds or more? In some cases that would be an interesting option!

[ebr 14903]

2 minutes ago, thegrunge said:

I also have on my side some m3u8 links which do not give enough advance to the current reading, I have to pause a few seconds when I start the channel to correct the problem. However with vlc player this problem is not present with the same link. There would be no way to add buffering time of e.g. 15 seconds or more? In some cases that would be an interesting option!

Have you tried adjusting these settings in the app?

[thegrunge 29]

I am using the iptv 1.1.9.0 plugin and I do not see any options neither if I am using m3u in live tv?

[ebr 14903]

The settings are in the Android TV/Fire TV app.  There is one for buffer size and one for live TV start time.

[thegrunge 29]

I am using the iptv 1.1.9.0 plugin and I do not see any options neither if I am using m3u in live tv?

 

Realy? I will check this evening I had not seen this in my firestick. where more precisely in video adjustment? And can this solve my problem with the iptv application?

[thegrunge 29]

I am using the iptv 1.1.9.0 plugin and I do not see any options neither if I am using m3u in live tv?

 

i found the solution to name de good name channel on zap2it.com now the live tv see the channels with all program content  Thank!

Edited January 26, 2021 by thegrunge

[neik 835]

On 1/25/2021 at 9:01 PM, ebr said:

The settings are in the Android TV/Fire TV app.  There is one for buffer size and one for live TV start time.

Any idea on migrating this to other apps besides ATV (e.g. mobile apps like Android/iOS)?

I guess, especially on mobile data a larger buffer could help with bandwith variation.

[ebr 14903]

8 hours ago, neik said:

Any idea on migrating this to other apps besides ATV (e.g. mobile apps like Android/iOS)?

I guess, especially on mobile data a larger buffer could help with bandwith variation.

Have we actually proven it to make a positive difference in any specific situations?

[pir8radio 1292]

just to hop on here....  my original request was for a server side option to force a specific buffer.   Since my older users do not understand that stuff to change it on the client side.   I am the server owner/admin not them.      But the positive difference I personally have noticed, is larger buffer corrects or hides bad IPTV streams, or minor stream glitches that wouldn't normally effect other players. 

[Luke 37006]

It's best that we look at the actual problem that you're having because it's not possible to set the player buffer size on most platforms.

[neik 835]

3 hours ago, Luke said:

It's best that we look at the actual problem that you're having because it's not possible to set the player buffer size on most platforms.

In case of IPTV I am not sure how you can really help when the source itself struggles to keep up for some seconds, which the bigger buffer could cover.

[ember1205 23]

On 1/27/2021 at 4:46 PM, neik said:

In case of IPTV I am not sure how you can really help when the source itself struggles to keep up for some seconds, which the bigger buffer could cover.

I recently added a couple of IPTV-based channels for QVC directly into Emby. The 'Live' channel in the US has a pretty bad stuttering problem when playing back through Emby but not through VLC. The other versions seem to play fine but picture quality is pretty bad.

 

Adjusting the playback buffer size from Small to Large not only didn't help, but it made the problem significantly worse. There are basically two "buffers" with IPTV - one at the server which is filled from ffmpeg transcoding the incoming content and then a second one at the client. In this specific situation, the problem is being cause by a lack of content getting transcribed on the server to be sent to the client. What happens is that the server buffer fills, content starts flowing to the client, the client buffer fills, and playback starts. Then... the server buffer empties due to lack of content. This trickles down to the client and ITS buffer empties out and playback pauses. The server is still refilling its buffer at this point which translates to an extended wait before the client will receive and buffer enough data to start playback again.

 

Given that this specific M3U8 file plays perfectly fine on VLC, I am starting to wonder if the problem is actually ffmpeg on my server. I run openSUSE as the server OS, and it is known to need a fair amount of "third party" packages to be installed if you are planning on using it for a variety of media processes (the SUSE team purposely avoids including a lot of packages that could lead to things like violation of DRM). I have read a number of discussions about certain modifications being made to the ffmpeg package (install from source and build by hand instead of leveraging the repository-based, pre-built package). I am going to look into some changes of that package to see if I can affect different results.

[thegrunge 29]

J'ai déjà eu aussi ce problème, la seule solution pour l'instant est de mettre la chaine que vous écoutez sur pause 10 secondes. c'est fatiguant, mais je n'ai pas trouvé d'autre solution. 

Je n'ai pas ce problème avec les chaines tv gratuite, et nouvellement avec le service iptv apollo, mais je devais toujours mettre sur pause 10 secondes avec mon ancien service iptv. La pause de 10 secondes créer un buffer suffisant

I also have this problem, the only solution for now is to pause the channel you are listening to for 10 seconds. it's tiring, but I haven't found any other solution.

I don't have this problem with free tv channels, and new with apollo iptv service, but I still had to pause 10 seconds with my old iptv service. The 10 second pause creates a sufficient buffer

Edited December 30, 2021 by thegrunge

[Luke 37006]

What I would suggest is lowering the in-app quality setting to a low enough value to ensure a smooth stream.

[ember1205 23]

6 minutes ago, Luke said:

What I would suggest is lowering the in-app quality setting to a low enough value to ensure a smooth stream.

This is 0% helpful until / unless the problem has been determined to be related to local network bandwidth or similar. In the case where an IPTV stream suffers interruptions or slow-downs from the provider, causing the -server- to be unable to collect enough content, reducing the transcoded quality offers no benefit. Additionally, it will cause ALL content to be reduced in quality when one is trying to solve an issue that applies to only a subset of media.

[ember1205 23]

I did some additional testing regarding the specific stuttering problem I'm seeing with the "Live" version of the QVC channel.

 

I created a brand new VM using Ubuntu linux, installed Emby, set up the channel stream, and experienced the exact same stuttering issues.

I took a snapshot of my Windows 10 VM, booted up, installed Emby (and the additional software it needed), set up the channel stream, and experienced the exact same stuttering issues. I then shut down, reverted my snapshot, and booted back up.

 

For reference, the Windows VM has VLC on it and it is capable of playing that same live channel stream with zero stuttering issues. So, the problem is not at all related to the operating system but rather to the Emby software itself or something that's packaged with it.

[thegrunge 29]

@ember1205Il n'y a rien à faire j'ai deja tout essayer, a part mettre sur pause 10 secondes quand on debute l'écoute d'une chaine tv quand le probleme se presente.

there is nothing to do I have already tried everything, apart from pausing for 10 seconds when you start listening to a TV channel when the problem arises

[ember1205 23]

For the very specific channel that I am chasing this down on, pausing like you describe has zero benefit. The problem with this particular channel is the way that the content is coming from the provider to the server itself. When streaming the channel directly to VLC, there is no issue because all content from the provider is being streamed directly to the client and the client buffers it correctly. When the server gets put into the middle, and it is creating a buffer on the server FIRST, that's where this breaks down.

 

This is just a theory, but I expect that the problem is because the server is trying to flush the buffer at a regular time interval and that sometimes results in the buffer being too low on data to continue to stream to the client before refilling (because the stream of data is not flowing from the external source to the Emby server at a constant rate - it comes in bursts). If there were a "per-channel" setting that would allow for the buffer at the server to be completely disabled, I suspect it would work fine.

[thegrunge 29]

J'ai une autre théorie, connaissez-vous les user agent? il arrive que les fournisseur tv reconnaisse que vous utiliser leurs postes pour un serveur. Dans ce cas essayer ce user agent dans emby. c'est ce que j'utilise, car j'avais des coupure avec certains fournisseur le poste stoppait tout simplement. 

I have another theory, do you know the user agent? sometimes tv providers recognize that you are using their workstations for a server. In this case try this user agent in emby. This is what I use, because I had cuts with some supplier the post simply stopped.

Mozilla/5.0 (X11 ; Linux x86_64 ; SMARTEMB Build/3.8.9068) AppleWebKit/537.36 (KHTML, comme Gecko) Chromium/89.0.4389.105 Chrome/89.0.4389.105 Safari/537.36

 

Edited January 5, 2022 by thegrunge

[ember1205 23]

I looked -very- closely at the M3U8 URL that was in use for this channel and noticed that it started with "nl." which could indicate that it's coming from a different country. I checked its IP Address and searched it, and found that I was correct - the IP belongs to AT&T in Europe/Asia. 

I changed the URL for the stream to be one that "should" be logically closer and found an immediate improvement in how long it would play (although now, instead of pausing, it completely dies).

I tried making the header change you suggested and that allows it to play longer still, but it still completely died after about 3.5 minutes.

I looked closely at the new URL, and realized it was a UK channel (SMH). Did more digging and located a stream for a US version of the channel and things seem to be playing correctly now although it's at the lower resolution again.

[thegrunge 29]

@ember1205pouvez-vous m'envoyer l'url en privé que je test de mon coté. possible que le format soit en cause

can you send me the url privately that i'm testing on my side. possible that the format is in question

[ember1205 23]

Not sure I'm understanding the ask... There are a number of different URL's for M3U8 files for QVC. I've only been able to find US-based ones so far that are 480p resolution. There's -one- that's 720 that I haven't been able to find yet.

[thegrunge 29]

I don't know what qvc is but hey if I had one of it's m3u8 link I could check on my side if it's stable. do you use the IPTV plugins or add the link directly in emby