Some Kodi settings to help with Live TV Buffering

Alucard

not a member
Aug 14, 2015
491
6
0
yes i do
Below are some advanced settings to help with Live TV buffering. This will slow channel switch but helps with buffering issues. It is not 100% but will help quite a bit.

The following will need to be put in your advancedsettings.xml file. If you are not sure where that or what that is, please visit the Kodi Wiki for more information.

<pvr>
<minvideocachelevel>65</minvideocachelevel>
<minaudiocachelevel>65</minaudiocachelevel>
<cacheindvdplayer>true</cacheindvdplayer>
</pvr>

Below contains some Advanced Settings for cache/buffer settings. The file names have the general settings based on how much memory your device has. Copy the file to one of the following locations based on your OS. You will need to rename the file to advancedsettings.xml. Only use this if you do not have a advancedsettings.xml already. If you do then add the above to it instead.

Windows:
C:\Users\<UserName>\AppData\Roaming\Kodi\userdata

Android:
/sdcard/Android/data/org.xbmc.kodi/files/.kodi/userdata

Updating Fire TV and Fire Stick.
I am assuming that you do not have a advanced settings.xml file yet.
1. Download the zip.
2. For Fire Stick extract the advancedsettings_1Gig_Mem.xml, for Fire TV extract the advancedsettings_2Gig_Mem.xml. Rename it to advancedsettings.xml
3. Now you need to copy the file to your fire stick to /sdcard/Android/data/org.xbmc.kodi/files/.kodi/userdata on your Fire Stick/TV.
3. Restart Kodi.

Now getting the file to the Fire Stick can be done several ways.
1. If your computer is shared on your network, then you can use the Kodi File manager
2. Assuming you used Amazon FireTV Utility to side load Kodi, you can use the Push File To Download Dir option and send the file over that way. Then you can use the Kodi File Manager to move it to the correct location.
3. Side load ES File Explorer and use that as a File Manger to copy the file from your computer as in #1. Or you can enable the FTP Server in ES File Explorer and use a FTP Client to copy the file over.
 
Last edited:
no there is 2 one says cache one says buffer cache:0 B:99% mine always says 99% on the buffer but 0 cache ive played other streams and seen the cache not be 0...all live streams show 0 for me..but streams from like genesis i get some cache
 
fernetmenta who coded the fuction say
"There are live streaming protocols like hls or rtmp which don't have caching before demuxer. It won't make much sense to cache a real time stream because the server won't buffer either. Means that if a client don't read a data packet in time, it is lost. Like the name real-time suggests, a client also can't read data in advance and put it into a cache."
and
"check pvr section of advanced settings:

<minvideocachelevel>5</minvideocachelevel> <!-- Cache up to this level in the video buffer buffer before resuming playback if the buffers run dry. -->

This post-demuxer cache can hold up to 8 seconds of video. "

this also means cachemembuffersize setting is useless.
there is no holy grail setting that will fix buffering in a instant. tweaking can help though.
 
Last edited:
fernetmenta who coded the fuction say
"There are live streaming protocols like hls or rtmp which don't have caching before demuxer. It won't make much sense to cache a real time stream because the server won't buffer either. Means that if a client don't read a data packet in time, it is lost. Like the name real-time suggests, a client also can't read data in advance and put it into a cache."
and
"check pvr section of advanced settings:

<minvideocachelevel>5</minvideocachelevel> <!-- Cache up to this level in the video buffer buffer before resuming playback if the buffers run dry. -->

This post-demuxer cache can hold up to 8 seconds of video. "

there is no holy grail setting that will fix buffering in a instant. tweaking can help though.
Good info +1
 
it also means if you cant get the data fast enough but fill the buffer you will have holes in your bufferstream from missing packets the server can not throttle the streaming speed when it is realtime. like it for example can when streaming a moviefile, you can pause and let it buffer and still have a non-broken stream in the buffer, you can not do that with a fixed realtime stream. the contents of the buffer will still be broken because the speed is fixed and the net cant keep up.

its the same as if the stalker client had recording option you could pre-record a hour if you wanted to but the pre-recording will have missing parts and skip like hell if you have buffering in the first place.

apparently there is a 8 second post-demuxer cache you can tweak around if your bandwidth is fluctuating.

basically what fernetmenta says.
if they haven't forgot themselves. heh
 
Last edited:
Well not sure what makes you thing that the server does not buffer. It has too, the Live Stream that Stalker uses is a HLS stream which has adaptive bit rate based on the connection. Saying the buffering on the client side does nothing is incorrect also, it just depends why the stream stops. If your not buffering the stream and the stream stops for any reason then Kodi will pause and wait. If your buffering a stream let's say for 10 seconds and it stops for 3 seconds and resumes then Kodi will continue to play. If you loose frames during that time then you will see this as a video glitch. The only time you will see Kodi pause is of the buffer empties before it has a chance to load up again. I rather see video glitches then Kodi completely stopping the video.
 
Last edited:
the server does not buffer and the stream is not adaptive if it was there would be no buffering just worse quality. come on its adaptive as in vbr. and its rtmp remove your lib and you wont be able to playback.

i agree with your example though except those times i had buffering on live-tv not movies i usually lost frames or skipped forward to the reason is you need to deplete the 8 seconds of buffer before getting buffering, and by that time the live tv has moved forward..
i did not say there was no buffer and it couldn't help tweaking it. i am just saying this buffer behaves differently because it is real time tv. and this should mostly work when the bandwidth is fluctuating and behaving as in your example.. filling, depleting in a timely fashion that keeps up with the buffer and if it does that there is no buffering
it was a response to the stuff we see and experience ie buffersize showing 0 and not seem to use cachemembuffersize setting.
sorry if i explained it in a confusing way. i see can now its not easy understand what i wrote. just read what fernetmenta says intead.
 
Last edited:
example: I can unplug the router from the Ethernet connection in the wall and the stream will continue to play for around 8 seconds, if I replug the router within that period the stream will continue to play without any buffering or skips. but if I unplug it more than 8 seconds (drain the buffer to cause buffering) the stream freezes, I can actually replug it again and the stream will continue but NOT from where it was, but where it now is coz the tv is offcause live.. ie. one buffering, one skip.

that means i can loose the connection to the server but i will have buffering 8 secs later, lets say i wait 2 seconds for the buffer to fill again that means i passed the 8 seconds of buffering and the video will not start where it left. that way you would get further and further behind and it wouldn't be realtime, match the epg, etc. a tv-show has to start and end at a certain time if your video stops and buffers and take off where it left it will fall behind the realtime stream there has to be a skip every time live tv buffers, and is as you say less noticeable than a freeze.

ever wondered why you cant pause and let the buffer fill with any livetv streams as you can when streaming a movie file.
the live stream have to follow a schedule to be live in kodi therefore large caches aren't allowed. the recoding function has to handle time shift viewing.
 
Last edited:
example: I can unplug the router from the Ethernet connection in the wall and the stream will continue to play for around 8 seconds, if I replug the router within that period the stream will continue to play without any buffering or skips. but if I unplug it more than 8 seconds (drain the buffer) the stream freezes, I can actually replug it again and the stream will continue but NOT from where it was, but where it now is coz the tv is offcause live..

ever wondered why you cant pause and let the buffer fill with any livetv streams as you can when streaming a movie file.
when i first started playing around with external players in kodi i got MPV player to pause these stalker streams and it kept filling the buffer but now whn i use mpv player it doesn't do it anymore...i know ya can depends on the player...
 
Last edited:
when i first started playing around with external players in kodi i got MPV player to pause these stalker streams and it kept filling the buffer but now whn i use mpv player it doesn't do it anymore...i know ya can depends on the player...
yeah it does depend on the player, the rtmpdump command for example can save or playback the stream.
i just think they made kodi pvr plugins like that a protocol for keeping realtime tv, and then its up to the plugin to provide time-shift and recording trough a different method. its always been a problem to record or save live streams in kodi, don't ask why, but i never seen it, i seen it requested many times though.

edit: read my edit lol, that's my best idea why. keeping it realtime or within 8 secs. as the kodi-team writes "You won't expect caching for your TV via SAT or cable, do you?"
 
Last edited:
I think we are saying the same thing just differently.. ;)

As for rtmp, I am not to sure. If you look at the stalker code, it does not do any rtmp calls and I believe the stream urls that are being returned are m3u8 streams. Just play a stream in VLC through the Stalker Client and look at the VLC logs and you should be able to tell what protocol it is using.
 
i think so to alucard.. and you're right channels seems to be http live streaming. they are fixed resolution though encoded with vbr in h264.
anyway both are pretty much treated similar ie. as live streams.
 
Last edited: