Cache bottleneck

Thanks for the help. I'm just gonna grab a new router. The thing is over 6 years old anyways. What router do you use where you are able to stream with no problems? I'm looking to spend no more than $130. Any suggestions? Thanks

ASUS RT-N66U .it hits right below your price point at around $124 with free shipping from newegg. check out the reviews online there is really nothing bad to say about it

it will blow your mind in comparison to your wrt54g2. you can install the custom Merlin firmware which is pretty much the standard for these routers. It's similar to dd-wrt and it has a ton of extra features.

the rt-n66u also has 4 GIGABIT lan ports. it came out about 2 years ago or so.

if you want to spend a little more and get the new version that just came out 3 months ago it's the RT-AC68U

its around $180 but it has all of the latest hardware inside and supports the latest AC wireless protocol. again check the reviews online they are incredible

I just picked up an ASUS TR-N53 at microcenter and no improvement!!  Appears to run out of cache and start pausing/unpausing at the same exact spot!!  Did I not get a powerful enough router?  Anything I can try?

Did some more experimenting:

First tried putting the latest release build.  The cache dwindled down but much more slowly.  However, I would get a slight stutter every 20 seconds or so.  The cache ran out at about 10 minutes as compared to 3 minutes.

Then tried 9.9.15.  Cache stayed high.  Never got low.  However, I got the slight stutter (this isn't an actual pause like what happens when the cache runs out) but every 1 to 1.5 minutes.  Tried with vertical sync as auto and as disabled, didn't notice a difference.  I left the AC3 and DTS capable receiver boxes checked.

Was going to try 9.9.15 with my old router.  Then might try 9.9.20 again.  May also try to overclock the pi.  Seems that some changes made between builds .15 and .20 made some differences.

Any suggestions I can try?

trying to overclock the pi is a good idea. see if the stutters happen further apart than when running normal. overclock wont hurt the pi. it seems a handful of people on these forums experience it. its definitely not the norm. the only difference for you now compared to when it was working before is the lack of a receiver. not using a receiver works fine for me though even with high bitrate files. i use a slight overclock. it helps if youre running a class 10 SD card when overclocking.

     there is either a phantom in your network or the pi is choking trying to process the audio. however if it happens with both ac3 and dts i still dont see it being that much of a burden on the pi. you shouldnt have to bother trying with your old router as youve pretty much proven its not the router.

    i was hoping in longchairs reply if he could have stated if he thinks it really could be the pi having trouble decoding the audio and causing the cache to dwindle.it will be cool to try and find a solution becuz it seems only a handful of people have this issue and i wonder what it is. people with similar setups dont see the problem

    check out scott451 it sounds like he is having a similar type problem

Hello,

Yes. I am having a similar problem.

I am running 9.9.20 (fresh install). My RPi, PMS, and NAS are all on a wired gigabit network. I have overclocked the RPi. My TV can handle DTS and AC3. The RPi is connected to TV by HDMI.

I have never been able to play 1080p video with DTS because of the 'stuttering'. I recently upgraded to 9.9.20 to see if my stuttering problem had improved.

Initially, it got worse. Even when the RPi was doing nothing CPU usage was near 100% and when I actually played a video, it stayed at 100% until the cache ran out and then stuttered.

This was solved by disabling vertical blank sync.  :-)

So I am back to my initial problem. If I play a 1080p video with DTS, CPU usage goes up to 100%, and then cache runs out after a few minutes.

I do not believe this is a network problem as the RPi can handle files with 15-20 mo/s with AC3 audio. However, if there is a way to test bandwidth, I'd love to check.

What is worrisome is that the RPi is at 100% CPU almost all the time. I suspect there is some parameter that I need to change, like vertical blank sync. Could it be linked to frame rate, or something similar ?

Thanks for any help !

- Scott

Are you using  a receiver with your setup?  Do you have access to one to for testing?  My setup was working perfecting and the only things that changed were I no longer have a receiver and I had been using a dated router.  I have since bought a new router and encounter the same problem which leads me to believe the problem is that I am not using a receiver.  I don't have my technical knowledge about this kind of thing so I am unable to explain it.  I no longer have access to a receiver for testing.  I plan on trying to overclock the pi today and may try some other things.

I tried a file that is ~16 mb/s with AC3 and still got the same problem.

hello again,

no receiver in my set-up, the tv manages sound on its own. my router is only a few years old ; it is integrated into my isp-supplied box, though they are generally advanced. i do not think that the network is the issue, but i have not been able to conclusively test bandwidth.

are you experiencing the cpu at 100% situation as well ?  over-clocking could help this. if network bottleneck is problem, i would not expect cpu to be at 100% or overclocking to change anything. in my example, i can play a file at 16mb/s, but my rpi is overclocked at 950/450/450/4.

i still personally suspect that some video output parameter is causing this, much as vertical blank sync will. maybe something caused by an american film and a european television.

- scott

Where on the display is the cpu %?  I see dcpu, acpu, vcpu and then a percentage immediately to the right of the cache.  The percentage to the right of the cache doesn't really go above 10% and the others are low as well.

Just put the latest experimental build back on.  The percentage to the right of cache now stays at 100%, the cache does not go down nearly as quickly, but I am getting a brief single stutter every 10-20 seconds.  Very strange!!

Overclocking seems to have fixed my problem.  The cache no longer dwindles down and no stutter!  The Pi now seems to constantly be at 100%.  I have an episode of Walking Dead that has a 3 minute scene where the bitrate is over 20mb/s.  This will bring the cache down to zero.  It seems that the problem has to do with the Pi handling audio and video in a high bitrate file.  I am guessing if I had a receiver I would not have encountered this problem.

Overclocking seems to have fixed my problem.  The cache no longer dwindles down and no stutter!  The Pi now seems to constantly be at 100%.  I have an episode of Walking Dead that has a 3 minute scene where the bitrate is over 20mb/s.  This will bring the cache down to zero.  It seems that the problem has to do with the Pi handling audio and video in a high bitrate file.  I am guessing if I had a receiver I would not have encountered this problem.

so the answer to whether or not the pi having to handle the audio as well as a high bitrate video stream is taxing on it, the answer is yes.

when the pi offloads the dts audio stream to a receiver that burden is greatly mitigated. i hope it happens throughout the whole movie and its not a fix in disguise.

what overclocking settings did you use?

scott was having a problem almost exactly like yours and overclocking did not help him. interesting indeed

I used 950/450/450/4

hi,

a couple of posts ago it was asked how to see the cpu usage with the on-screen stats from the "i" command. i get something like this :

D(Audio:ac3, 48000 Hz, 5.1 (side) s16 640 Kb/s P(aq:63%, Kb/s:681.77)
D(Video:h264 (High) yuv420p 1920x800 [SAR 1:1 DAR 12:5]) P(fr: 23.976 vq:99%, dc:omx-h264, Mb/s 11.64)
C(ad:0.000 a/v:4.223, edl:-, dcpu:1% acpu:0% vcpu:0% cache 59.48 mB 100% 0 sec, omx vs:19666000 ad:2.000
W(fps:15.12 CPUO:52.8%) P(Server:Tirion direct-play)

now, if there is an explanation for all this out there i haven't found it yet. i am assuming rpi cpu usage is on last line "CPU0". i would love to have more information.

- scott

hello again,

another thought... my tv manages dts but not dts-hd ma. i assumed that the rpi would pass along the dts-hd ma stream and my tv would simply play the core.

is this correct ?  or is the rpi burning up cpu cycles to strip the core out ?

this might explain why i have no problem with ac3 audio, but big ones with dts-hd ma.

- scott

hello again,

another thought... my tv manages dts but not dts-hd ma. i assumed that the rpi would pass along the dts-hd ma stream and my tv would simply play the core.

is this correct ?  or is the rpi burning up cpu cycles to strip the core out ?

this might explain why i have no problem with ac3 audio, but big ones with dts-hd ma.

- scott

they discuss it here: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=16821&sid=114a7d1■■■8e76064284bb71348ab2da&start=125

it appears the Pi passes the core to the Amp/TV

any new news?

funny you should ask ...

i spend some time this weekend 'playing' with rasplex, basically re-encoding the same files at different bit rates and with different audio to see what worked, and what didn't.

my conclusion is that there is not a problem with dts-hdma per se, but the vast bandwidth it can use when added to the bit rate of the video simply overwhelms the rpi. in one of my examples the audio was at over 5mbs. this plus 15mbs video (with spikes at 20mbs) was simply too much.

dolby digital works 'better' simply because it only uses 640kbs.

thanks to all for help during this trial. there is no fix, just the reality of the processing power needed. the question is what to do with all the bsg episodes i have at 25mbs ?    ;-)

- scott

funny you should ask ...

i spend some time this weekend 'playing' with rasplex, basically re-encoding the same files at different bit rates and with different audio to see what worked, and what didn't.

my conclusion is that there is not a problem with dts-hdma per se, but the vast bandwidth it can use when added to the bit rate of the video simply overwhelms the rpi. in one of my examples the audio was at over 5mbs. this plus 15mbs video (with spikes at 20mbs) was simply too much.

dolby digital works 'better' simply because it only uses 640kbs.

thanks to all for help during this trial. there is no fix, just the reality of the processing power needed. the question is what to do with all the bsg episodes i have at 25mbs ?    ;-)

- scott

dinosaur plex seemed to confirm this. overclocking solved all his problems until his bitrate reaches over 20 give or take.  the rasp pi simply hits a limit where even overclocking it does not help.

    o/c it took 15mb/s files and made them play fine with dts whereas before it was all stutter  

    good to learn something every day!

I'll add my experience to the thread in case it can helps solve the problem.

I'm using a brand new 512MB Pi with Rasplex 9.9.20 on a wired network although the Microserver from which I run Plex Media Server is connected to the router via 500mbps Homeplugs.

With a file transfer from my laptop connected via Wifi to the server I get 2MB/s (Megabytes a second) which I figure is plenty fast enough and I do not believe there is a bottleneck on the network but I may be wrong.

The router is a Virgin Media superhub, around 1 year old.

Up until last night I had been watching my TV shows on Rasplex without any problems at all, they are in 480p.

I watched Blood Diamond in 720p and got to around the 70 min mark without any hiccups then the stuttering issue began. Upon loading up the info I could see that the cache had depleted to a few hundred kb and the CPU was maxed out at 100% trying to work to presumably fill the cache.

If I paused the cache filled back up to 60MB but immediately upon pressing play it emptied, I didn't even get a few seconds play before the stuttering resumed.

I restarted the Pi several times and resumed the movie from the same position, again stuttering.

I restarted the movie from the beginning and skipped forward to where I was, again stuttering.

I overclocked the Pi for the first time, checked all settings upon reboot - vertical sync disabled, all audio DTS disabled (I have no receiver). Still stuttering.

I started a new movie - Prometheus - got about 3 mins in then stuttering.

One thing to note which I didn't realise until Googling yesterday, the SD card that came with NOOBS installed is only Class 6 so I'm going to test with a Class 10 card next time - but I'm curious - will this have any effect? The Pi boots from the SD and presumably all this caching is happening in the 512MB of RAM and has nothing to do with the SD card. This is a guess and I'm likely wrong.

I overclocked the Pi for the first time, checked all settings upon reboot - vertical sync disabled, all audio DTS disabled (I have no receiver). Still stuttering.

I started a new movie - Prometheus - got about 3 mins in then stuttering.

tough to say. dinosaur plex fixed his stuttering completely on high bitrate files by simply overclocking. he was having the exact same cache issues. it was a matter of the pi not being able to keep up with the high bitrate unless he gave it a little extra juice. he said he was using a class 10 sd card. not sure if that will make the difference