v17 libnfs on RPi1 too slow for bluray files
#16
The Pi1 has always been on the edge for BluRay playback.
A Pi2/Pi3 has a much easier job of things.

Have you had success with the same file and same network on a previous version of librelelec?
Reply
#17
Same file - it is very likely it worked with earlier Leia builds. I do recall watching enough of the film to decide it was a little too odd for my taste at the time, which would suggest that it was not having a buffer underrun every minute.
Same network - not possible to say unfortunately since I did move last year. Having said that, the laptop used as NFS server is the same device and the cable modem is the same connect box branded for Germany (unitymedia) instead of Switzerland (UPC).
Reply
#18
Here is the top screenshot in case it is interesting:
Image
Reply
#19
(2019-01-02, 23:04)belegdol Wrote: Here is the top screenshot
You can also use the 'i'-button in our editor menubar (next to the smiley) to automagically upload your screen captures or other graphics/pictures.
There is no need to let Google know which pictures people click on. Wink
Reply
#20
Thanks for the tip, I did not see that yesterday. Post edited.
Reply
#21
(2019-01-02, 21:50)belegdol Wrote: Same file - it is very likely it worked with earlier Leia builds.
If you can identify an earlier build (e.g. through historical Milhouse releases) that behaves better then we can investigate.
There have been some changes related to chunksize used for reading network data (with intention of making things better) that could conceivably have harmed things.

But it's also possible a change in network conditions has made things worse - confirming an older build plays better would be useful.
Reply
#22
I can definitely try - is there an easy-ish way of downgrading?
Another idea I have been pondering was to see if the core actually hits 1GHz and trying overclocking beyond that.
Reply
#23
(2019-01-03, 13:02)belegdol Wrote: I can definitely try - is there an easy-ish way of downgrading?
 
See https://forum.kodi.tv/showthread.php?tid=298461 and "7 LibreELEC Settings add-on Development Updates"
Reply
#24
I downgraded all the way down to 8.2.5. Unfortunately all my settings are gone now which invalidates the comparison somewhat. Having said that, the CPU usage is hovering more about 90 than 100 % now and it takes longer until the buffer is empty. It does still underrun eventually. Interestingly enough, for a share mounted with:
Code:
ro,udp,rsize=16384
dd is still faster than when the video is played. Please have a look at this, the first peak is dd and the second one is the video being played:
Image
I used the following dd syntax:
Code:
dd if=movies/video.mkv of=/dev/null bs=16k count=8192bs=16k count=8192
Reply
#25
(2019-01-03, 20:20)belegdol Wrote: dd is still faster than when the video is played. Please have a look at this, the first peak is dd and the second one is the video being played:

That isn't too surprising. Pi1 is mostly CPU limited, so the arm being busier (when playing the video) is likely to lower the maximum throughput
(the usb hardware in the Pi requires a fair amount of CPU interaction to keep packets flowing).

If you were to say that dd was still faster when done in parallel with the arm playing the same video from, say, the sdcard, then that may be more telling.
Reply
#26
Out of curiosity I downgraded all the way to Jarvis and libreelec-7.0.3. To my surprise, I was able to play the video without stuttering with the same settings. Here is the network graph:
Image
Same file played with Leia (libreelec-8.95.1):
Image
With Krypton (libreelec-8.2.5) the buffer underruns the same way it does with Leia.
Reply
#27
(2019-01-04, 20:11)belegdol Wrote: Out of curiosity I downgraded all the way to Jarvis and libreelec-7.0.3. To my surprise, I was able to play the video without stuttering with the same settings.

An unfortunate trend with software is to get bigger and slower with time.
Most devs upgrade cpu/ram/ssd regularly so don't notice when a refactoring has a performance cost.

If we could find exactly when the performance decreased it may be possible to undo it, but if it was that long ago it will be tricky to identify.
(and that assumes it was a single change, rather than a succession of 1% decreases).
Reply
#28
I understand Smile I think the time has come to retire the pi and move on, it seems unlikely that this performance issue can be fixed. Thanks for all your help!a
Reply

Logout Mark Read Team Forum Stats Members Help
libnfs on RPi1 too slow for bluray files0