v17 source too slow for continuous playback, despite setting larger cache with memorysize
#1
Let me start off by apologizing if this has been addressed and I am just not finding the correct setting.
I am normally very adamant about finding the solution on my own through forums/google but after 2 days of looking for the answer I am asking for help.

I am unsure if this bug has been reported, or if there is a hidden setting to correct it.

I have been using Kodi for many years, I do not think I experienced this issue prior to version 17.

Running Ubuntu 18.04.1 with Kodi 17.6

machine: core i3-2120 3.3GHz dual core with hyper-threading, 8GB ram

The media source directory is mounted from a remote server using sshfs.

here is my advancedsettings:

xml:
<advancedsettings>
  <cache>
    <buffermode>1</buffermode>
    <memorysize>268435456</memorysize>
    <readfactor>10</readfactor>
  </cache>
</advancedsettings>

If the bitrate of the file is low enough, then I will not experience the issue.

So I understand that the issue is the limit of my network capability, however this is not the issue.

The issue is that some of the videos, while close to the limit of my network, would still play perfectly fine, if Kodi would simply try pausing for long enough to buffer ahead.

In my recent testing, when Kodi attempts to buffer, I get the progress dial in the center of the screen, the number goes from 1.. 2.. 3.. 4.. 5.. 6.. I am assuming this is a percent of 100?
Once it gets to about 6% it gives me the message "source too slow for continuous playback"

At this point it will attempt to drop frames to continue playing, however the result is that the video ENDLESSLY stutters along at about 3FPS with no audio.

However if I manually hit the pause button, wait a couple minutes, then hit play, the movie will play WITHOUT ISSUE, sometimes it will play through the entire movie too! other times I have to pause a couple more times.

What can I do to tell Kodi that I do NOT want it to try and work around "source too slow for continuous playback" and instead just attempt to try buffering longer instead of giving up at 6%

with ctrl+shift+o pressed, I can tell during the buffering phase that its loading up more video just fine, the "Forward" stat continues to increase, which I am assumming is the video buffering ahead into the cache.

If somebody could tell me how to get Kodi to not Give up on buffering at 6% I would really really really appreciate it. I do not even care if it means waiting 10-15 minutes for the video to buffer ahead before resuming playback.

Also I am willing to provide any logs, or try a settings, or test a development build, whatever is required, thank you!
Reply
#2
(2018-09-17, 16:33)xekon Wrote: machine: core i3-2120 3.3GHz dual core with hyper-threading, 8GB ram
HD 3000 graphics, unless you have a discrete graphics card in it as well... What sort of video are you trying to play? A debug log (wiki) would help.

(2018-09-17, 16:33)xekon Wrote: If the bitrate of the file is low enough, then I will not experience the issue.
Creating a big cache usually is because of poor network performance IMO. I'm running a i3-3225 on a gigabit network. I never had to do cache buffering in my advancedsettings.xml file.

(2018-09-17, 16:33)xekon Wrote: The media source directory is mounted from a remote server using sshfs.
Hmpf... Is encrypting the data on the far end taking too much time?
Reply
#3
v17 is end of live -> any discussion about v17 in the dev section of the forum is dead end.

don't mount remote folders via sshfs. kodi won't notice that this is remote and will read with a packet size of 4k. that is way too small for a good performance for network shares
Reply
#4
and ssh is the worst protocol for this. Try http(s) if you're server is outside your LAN.
Reply
#5
Thanks for the replies everyone!

I installed the nightly build of kodi (18) instead of 17.6

Before it would only try buffering once, and then it would say "source too slow for continuous playback", and after that the next time the buffer ran out it would just stutter at 3FPS with no audio.
Now with 18 after buffering and receiving the message "source too slow for continuous playback" once, the next time it runs out of buffer it will buffer again! EXCELLENT, this is what I wanted Smile

After FernetMenta mentioned the packet size of 4k, I decided to try and benchmark different methods.

So I used tcpstat, with sshfs directly mounting the filesystem, I actually seemed to get better throughput than with SFTP network media location option that is in kodi 17.6.

I see that SFTP was removed from 18 anyway, Now I am wanting to test the other encrypted methods, to compare performance.
The ones I have not tried are:
FTPS server
WebDAV server (HTTPS)
Web server directory (HTTPS)

However I am curious about some things, I know that SSL is encrypted by nature, and I have setup webservers before with both Apache and NGINX, however that was for web sites or web applications.
I am not sure what would be the most secure/efficient way of setting up a server to simply be an HTTPS file host, and how do you set it up to enforce/require a password for the HTTPS

On the subject of the packet size of 4k, what if you had an SSHFS connection to a directory directly in the OS(like I was originally doing), but then in kodi you add that location as a Network File System, and use the machines own IP address, then kodi should understand that its a network location and use a larger packet size? or maybe there is another way to get kodi to use larger packet sizes for certain folders/media sources. I aks this because I really like using SSHFS, it is an elegant solution, and if implemented properly should perform just as well as https from what I have read....
Reply
#6
FWIW, and probably may not apply to you, but it might to others reading looking for an answer.

I also received the "source too slow for continuous playback" warning. After years of no issues, it started occurring for no reason that I could see. Win10, local network and SMB path to a drive on the network.

A few weeks later the drive died. I replaced it and have not received the warning again.
My Signature
Links to : Official:Forum rules (wiki) | Official:Forum rules/Banned add-ons (wiki) | Debug Log (wiki)
Links to : HOW-TO:Create Music Library (wiki) | HOW-TO:Create_Video_Library (wiki)  ||  Artwork (wiki) | Basic controls (wiki) | Import-export library (wiki) | Movie sets (wiki) | Movie universe (wiki) | NFO files (wiki) | Quick start guide (wiki)
Reply
#7
(2018-09-18, 06:22)Karellen Wrote: FWIW, and probably may not apply to you, but it might to others reading looking for an answer.

I also received the "source too slow for continuous playback" warning. After years of no issues, it started occurring for no reason that I could see. Win10, local network and SMB path to a drive on the network.

A few weeks later the drive died. I replaced it and have not received the warning again.
 AYE! good info for other readers that find this post, and the symptoms are similar, for me its an internet speed limitation, for you it was your drive dying. In my case I can watch the files from the TV that is actually at the file server location and there are no issues, so it is definitely related to the throughput limit of my connection.

The nightly build of Kodi 18 solved my stuttering issue, now kodi is buffering properly when it needs to.

The only thing I have left to do is to get the most that I can out of my connection, after reading @FernetMenta  and @wsnipex  comments about the performance of https vs sshfs I want to do what I can to make the most of my connection.

I would really like to try using sshfs with kodi using a larger packet size if that is somehow possible, I am just not sure how I would accomplish that. (since to Kodi, the folder will appear as a directory on the local system instead of a network location.)

Maybe there could be a way to mark local folders as actually being network locations, so that the proper packet size is used?
Reply
#8
fyi: we didn't really remove ssh support in v18, it was moved to a binary addon. If you use our nightly ppa, you can install kodi-vfs-sftp

enabling password protection on a web server is trivial, if you already have some experience with nginx, that's what I'd suggest. Tons of tutorials out there.
Same for SSL, letsencrypt makes it pretty easy as well.

as for sshfs mounts: try man sshfs. there are several options available that might improve throughput.
e.g.:
Code:
       -o large_read
              issue large read requests (2.4 only)
       -o max_read=N
              set maximum size of read requests
       -o direct_io
              use direct I/O
       -o workaround=LIST
              colon separated list of workarounds

               none   no workarounds enabled

               all    all workarounds enabled

               [no]nodelaysrv
                      set nodelay tcp flag in ssh (default: off)
Reply
#9
I have been testing the latest nightly build of Kodi 18 for about a month, and so far I LOVE IT!

I have also been experimenting more with the advancedsettings, cache settings

I have been trying to adjust my cache settings so that it behaves similar to disk caching: (which works GREAT for playback, but ide prefer to not tax my drive needlessly.)

<advancedsettings>
  <cache>
    <buffermode>1</buffermode>
    <memorysize>0</memorysize>
    <readfactor>9999999999</readfactor>
  </cache>
</advancedsettings>

but instead of memorysize 0 I am trying to adjust it so that it uses ~80% of available memory or so, instead of writing to my hard drive.

The wiki says that memorysize will consume about 3x the defined size in RAM.
So I set my memorysize to about 2GB which should consume about 6GB of my available 8GB

<advancedsettings>
  <cache>
    <buffermode>1</buffermode>
    <memorysize>2100200300</memorysize>
    <readfactor>9999999999</readfactor>
  </cache>
</advancedsettings>

However this does not appear to be the case, using codec info (ctrl+shift+o)
I am seeing a cache size of about 751MB (forward:751.1 MB)
and htop is showing that my entire system is using only 1.64GB, thats ALL processes not just kodi, which is still short of the 2GB memorysize that I set.

I can keep increasing memorysize to get a larger cache size of coarse, but I am wondering why its not using the 3x like the wiki states.

I hope others can understand why this concerns me, its because the wiki states that too much ram usage results in a kodi crash.... so while I can increase it, it worries me to do so blindly knowing that according to the wiki it should be using 3x the defined amount.

Appreciate any response on this, for the time being I am just going to keep increasing the memorysize until I get close to the 6GB that I am aiming for.
Reply
#10
was looking at the numbers again, and 751 mb forward, is actually about 1/3 of the defined ~2GB memorysize, so maybe the defined memorysize is the actual consumed memory size? instead of x3 like the wiki states?

I am running Ubuntu 18.04.1 64 bit with the nightly build of Kodi 18

I found another thread where somebody experienced the same thing:

https://forum.kodi.tv/showthread.php?tid...memorysize

For anyone that reads this thread, I got a forward cache of 1.5 GB on my 8GB system with the below settings (the largest I could get it to do):
htop showed total system memory usage at 2.65GB, which means kodi cache was using about 1.9GB or so total.

xml:
<advancedsettings>
  <cache>
    <buffermode>1</buffermode>
    <memorysize>4289999999</memorysize>
    <readfactor>9999999999</readfactor>
  </cache>
</advancedsettings>
Reply

Logout Mark Read Team Forum Stats Members Help
source too slow for continuous playback, despite setting larger cache with memorysize0