0

I am running a Kodi media center, more specifically OSMC, on a Rapsberry Pi 2 in my living room which sources its movies, shows etc. from another Pi thats located in another room (the rest of my home network equipment is also located in that room). The Pi in the living room is connected via a power line adapter to my home network since this is the best solution in my rented apartment without using wifi or having cables all across the apartment.

Now, when I watch some movie in my living room, at times I run into the issue of the stream beginning to stutter. At first I was blaming the poor connection over the power line but after this was happening more often I wanted to do something about that.

My Kodi cache settings were already set way higher than it would be required for the amount of data streamed for any of my movie rips (see excerpt of my advancedsettings.xml below) so I didn't investigate too much in that direction. Then I did a quick check on a few movies where the stuttering appeared and noticed they all had an overall bit rate of >10 Mbit/s (which, to my surprise, is quite a low mark considering a 1080p/x264 encoded movie with a decent DTS audio stream can easily exceed this bit rate). Since I configured all my video sources in Kodi to use SMB I logged onto the Pi in the living room via SSH and mounted one of my hard drives directly with the following command:

mount -t cifs //host/hdd4 mount/

After that I fetched a chunk of one of the movies affected by this issue and monitored the network throughput during that time:

dd if=mount/Media/Movies/Stuttering.Movie.mkv of=/dev/null bs=1M count=300 &>/dev/null & speedometer -r eth0

The ouput of speedometer showed me a constant RX rate of ~6-7 MiB/s, which is far from perfect but would be enough for all my rips and would ensure Kodis buffer never runs dry. Watching the throughput while playing back the same movie in Kodi showed me a RX rate of only ~1-1.5 MiB/s constantly, not even a spike close to 6 MiB/s at any time. This would explain why certain movies are stuttering when the rate at which Kodi buffers a movie barely equals the movies current bit rate.

I'm aware that a Raspberrys ethernet port shares its data lines with the USB controller (which could possibly cause a drop) but since the movies are streamed from a different system on the local network I would expect the data to come in at max speed during playback. Also I can't imagine that Kodi is using some transfer method that's causing such a massive drop in buffer speed but I invite everyone to proof me wrong :)

Could anyone explain to me what's causing this limitation in transfer when playing back a movie directly in Kodi compared to fetching it directly via dd (or some other command) like I did? Am I getting it totally wrong or is there some other magic going on behind Kodis curtains?

These are the aforementioned cache settings in advancedsettings.xml from my living room Pi:

<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
    <cache>
        <buffermode>1</buffermode>
        <memorysize>62914560</memorysize>
        <readfactor>100000</readfactor>
    </cache>
</advancedsettings>

Tinkering around with those values (like setting the readfactor to a value of 1000) didn't change anything and I don't want to set the buffermode to 3 as I don't want to cause unnecessary wear on the SD card.

Any help is highly appreciated!

  • "I don't want to set the buffermode to 3" -> Dunno what the difference there is supposed to be (not a user), but note that dd of course does write straight to SD and this may be an advantage vs. buffering to RAM on a system where the latter is taxed. Have you looked at system metrics other than the transport speed? Anyway, if it does make it faster, it seems beyond foolish to not use it in order to "save for my grandchildren" a $10 SD card, or even a $50 SD card, since what is the point in paying for something you don't like to use... – goldilocks Mar 4 at 14:29
  • @goldilocks Dunno what the difference there is supposed to be (not a user) Then why not look it up and start discussing from there on? Look here for clarification. […] but note that dd of course does write straight to SD[…] That's not true in my case, as I'm writing to /dev/null so effectivelly nowhere. Have you looked at system metrics other than the transport speed? Not yet since the network transmission is the first bottleneck I've observed. But I'd be thankful if you'd give some commands… – Arno-Nymous Mar 4 at 16:39
  • @goldilocks … to tinker with. I'm not that deep into the internals of Kodis caching mechanism or what's happening exactly when I press "Play" on my remote and Kodi fetches the file from that other Pi. I just noticed that drop in transmission speed when Kodi handles file caching so I wanted to get to the bottom of why Kodi won't use all the available bandwith. And I was hoping that some experienced user could give me a hint on what I might be missing out. Such advice like "Just cache the file to SD instead and be happy" doesn't satisfy me. Besides, caching to SD card is not faster,… – Arno-Nymous Mar 4 at 16:52
  • @goldilocks … it slows down everything even more (which kind of makes sense). "[…] it seems beyond foolish to not use it in order to "save for my grandchildren" a $10 SD card[…]" Uhm, I think it's not up to you nor anybody but me to decide what I spend my bucks on :) Just to make it clear: it's not about the money, I just want to understand it. – Arno-Nymous Mar 4 at 16:55
  • Fair enough. I was trying to stress a point because paranoia about SD card corruption/wear has run a bit rampant here & in the pi community generally; I think people latch onto it because it seems like a solid piece of information -- that is never backed up by anything but personal anecdotes. Don't get infected by it ;) – goldilocks Mar 4 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.