Posts: 31
Joined: May 2014
Reputation:
0
I tried config_hdmi_boost=7 but it does not seem to help. The power supply is 1.2 A one which I bought from RS components for the Pi, how does it look on paper?
In any case, I did some more thorough testing with latest Mulhouse build (23 May). Even with turbo overclock, native mount, UDP and rsize=8192 the playback stops every now and again. Looking at network monitor, the data seem to flow at around 5 MB/s only. On the other hand, dding a ~400 MB file to /dev/null reaches 7.3 MB/s. According to PlayerDebug CPU0 hovers around 100% so it appears that CPU is the limiting factor. I already enabled DTS passthrough and omxplayer, is there anywhere else where the few missing CPU cycles could be gained? Thanks!
Wysłane z mojego Nexus 9 przy użyciu Tapatalka
Posts: 8,966
Joined: Feb 2011
Reputation:
426
m2 may have a more variable bitrate, with higher peaks even though the average is less.
Posts: 31
Joined: May 2014
Reputation:
0
But would the variable bitrate influence how fast the file is transmitted over the network? I have been monitoring the speed using system monitor installed on the server and m1 is being served at around 6 MB/s whereas m2 caps at around 4 MB/s.
I think that for some reason the second file has higher CPU requirement and there is not enough left for NFS. Even with readfactor set to 2 and buffermode set to 1 the transfer speed is the same and playback is jerky while PlayerDebug shows CPU usage hovering around 100%. Looks like it might be the time to upgrade to Pi 3...
Wysłane z mojego XT1580 przy użyciu Tapatalka
Posts: 112
Joined: Apr 2015
Reputation:
3
One more vote for OS level mounts. Solved buffering issues more than once for me.
Posts: 31
Joined: May 2014
Reputation:
0
2017-06-18, 19:04
(This post was last modified: 2017-06-18, 19:05 by belegdol.)
I believe I may have solved this: when I checked the files I had available I realised that ones which only has dts-hd ma as the lossless audio were playing fine, wherereas ones which contained dolby atmos on top of that were running out of bandwidth. Not even os-level mount over udp and rsize=8192 was enough. To test my theory, I remuxed the latter files removing the atmos audio track (alongside other unneeded audio tracks and subtitles) and the bandwidth problems have disappeared.
It looks like having two lossless audio tracks in one bluray rip is the proverbial straw breaking the camel's back.
Wysłane z mojego Nexus 9 przy użyciu Tapatalka
Posts: 31
Joined: May 2014
Reputation:
0
Apologies for resurrecting this old thread. I have now dusted off the Pi and tried libreelec-9.0beta1. Unfortunately, the transfer is too slow even for a file with just two audio tracks, no dolby atmos. While dd test gets up to 6.1 MB/s with system mount and rsize=16384, the same options yield only approximately 5 MB/s while playing a video which is a smidge too slow to keep up with the bitrate. I have noticed that as before, CPU is stuck at 100 %. I am already using omxplayer and audio passthrough. Is there anything else I could try?
Posts: 8,966
Joined: Feb 2011
Reputation:
426
Have you tried overclocking?
Posts: 31
Joined: May 2014
Reputation:
0
2019-01-02, 18:10
(This post was last modified: 2019-01-02, 19:21 by belegdol.)
Already running at turbo preset. As you suspected back in the day, display blinking was solved by replacing the PSU - an old Nexus 4 one did the trick.