Would a slow SD card harm streaming performance?

One of my OSMC boxes (RPi2) is set up primarily for music streaming. It uses a slow (class 4) SanDisk 16GB SD card and is connected to the internet via powerline:

Most of the time the device works just fine. But maybe once or twice an hour there will be a pause in playback (like it is buffering).

I always assumed this would be a problem with network speed, and maybe it is, but it occurred to me today it might also be related to the slow SD card. Is that possible?

Is there a definitive way to test? I already tried a couple of speedtest apps, and I get similar down/up speeds as on my PC attached to the main router. But since the second router is connected by powerline, I guess it is possible to have intermittent noise or interference. So I am not sure there is an easy way to validate the network part. If a slow SD card is a possible culprit, I could just try replacing it to see.

The easiest way to exclude the network performance as a bottleneck would be to put one or more files on the SD card or a USB stick

I thought of using a powerline as well for my pi behind the TV but initial tests proved just that…i had occasionally slow speeds. I dont know why…but i was really not satisfied with it.
Eventually i set an AP on the balcony, and use a wifi stick on the pi. I can stream 1080 with no problems.
sudo apt-get install wavemon to install a program to ‘find’ the sweetspot, on where to place the AP. It gives a live feedback of the dbm the wifi stick has with the AP.

And just play them on a continuous loop? And also watch that loop continuously to catch the rare / intermittent gaps? :grinning:

yup, its a live feedback for wifi connection with the AP.

Nobody can tell me if a slow SD card could theoretically harm streaming speed / performance?

I don’t mind trying a new card. But won’t bother if someone definitively could tell me that SD card speed is completely unrelated and could not be contributing to this issue.

If the movie is not located on the SD card, i dont see why it should affect the performance.

OK, thanks. That’s what I was trying to learn. I did not know if streaming is literally direct to output, or if there is an intermediate step that buffers locally on the SD card. I guess if there is any buffering, it would be done in RAM?

There is one thing you can try to figure out whats wrong.

  1. Put your ‘stream/movie/music’ on a usb stick, and play it directly from the pi.
  2. Remove the powerline and connect a wifi stick and stream the same music over wifi
  3. Do the same thing but with a cable (LAN) connection, not a wifi or powerline

This way you’ll know for sure, whose fault it is.

My guess is the speed with the powerline isnt that high, I dont know what type of stream you are sharing…mp3, ogg etc…but try a movie instead…does it do the same thing ? Or any other online addon like youtube…If it’s caused by low bandwidth then those things should stutter and buffer as well.
If the usb method, or the LAN cable method does not cause you problems, then its not the cpu, ram etc…its the powerline, that gives low speeds.

Buy a class10 card.

By default, Kodi caches a small amount of data to ensure there is little to no buffering.
Try reading and writing simultaneously to a class4 card and let me know how that works out. :wink:

@CaNsA, does that include USB type installations? Or does it use the usb then ? I thought the whole buffering was done in Ram…

If you are streaming with a USB install device, then you are using precious USB bandwidth that is needed for network data. Don’t forget that eth0 is slapped on the USB.

Caching - Depends if you specify ram or local storage in the advancedsettings.xml,

1 Like

@CaNsA - thanks for all your helpful replies. I went ahead and ordered a Samsung EVO class 10.

I am not at home right now to check my advancedsettings.xml, but have not changed this setting myself so it should be using default. Do you know what default is? It sounds like you are indicating it is the SD card, but I thought it would generally be RAM for this type of operation?

Doesn’t this suggest I could get around the slow SD card by using RAM for cache instead of the card? (Just curious, as I said I went ahead an ordered a new card anyway.)

By default RAM is used for buffering the video.
However there will be occasional sdcard accesses when playing video (e.g. log messages or loading of skin resources when pressing buttons). It is just possible that a big delay from the sdcard could cause a playback issue.

I don’t think it’s likely that the sdcard is the cause of streaming issues, but it is not impossible.

1 Like

So I tried a Class 10 SD card (Samsung EVO 16GB). I have not had a chance to test extensively, but I was listening for an hour or so yesterday and still noticed a couple of gaps.

But today I just saw this post about “micro dropouts”. It sounds kind of similar to what I am experiencing. In that thread, @popcornmix suggested setting buffermode=1 (Kodi page). I will try this when I get home and see if it helps my setup too.

I have found that my RPi machines on hard wired network can manage thruput at 98Mb/Sec. Connect two RPi machines on the same switch and run iperf. (client on one machine and server on the other). That test is only HDX but then so is streaming video.
You may have loss in your powerline connections. IF you are making errors the protocol will be making retrys and the total thruput suffers.

As some have pointed out buffering can be either in RAM or in SD or USB memory. Even though my network performs nicely I still allocate 20MB of RAM for buffer.

Tom S

It’s always hard to say with this kind of intermittent problem, but I listened for about an hour again last night (after setting buffermode=1) and did not notice any streaming issues this time. So this is definitely promising.

I will continue to monitor and report back once the new setup has a little more history.

Update: I used the unit on-and-off for the last several days and have yet to encounter another incident of music buffering or lag. I think it is fair to say that setting buffermode=1 in advancedsettings.xml has resolved the problem.