[Milhouse]

Edit: I can boot Beta 5 all the way up to sdram_freq=499, but as soon as I try to use sdram_freq=500 the Pi will fail to boot (2-3 flashes of green LED, then nothing).

This same Pi has been 100% stable with sdram_freq=600 up to and including Beta 3 - something iffy in the post Beta 3 firmware/kernel?

[goujam]

No idea look it up (2 words in google). What I do know is that openELEC3 B5 is released running RC1.
Can we get a small list of changes if we ask nicely sraue? (:

Well I take it you didnt google it as it doesnt say anywhere that its avaialable in the Pi builds, so thats why I asked here.

[hpbaxxter]

Edit: I can boot Beta 5 all the way up to sdram_freq=499, but as soon as I try to use sdram_freq=500 the Pi will fail to boot (2-3 flashes of green LED, then nothing).

This same Pi has been 100% stable with sdram_freq=600 up to and including Beta 3 - something iffy in the post Beta 3 firmware/kernel?

I had to insert boot_delay=1 in config.txt to boot with higher sdram frequencies than 425 MHz; 500 MHz now works fine. Maybe it works for you, too? I haven't checked if it's still necessary for me with newer versions as this behavior already appeared in summer. For raspbian, however, this parameter isn't necessary at all, so this seems to be a bit kernel specific.

[tuxen]

The same here with beta 3 I had to set the sdram from 500 and down to 450 otherwise it stayed at the color gradient screen. I think I wrote it longer back in this thread to notify that something changed in the firmware. I have not tryid edging up to 499 but it could very well end in same result as yours. But now you have you answer.

Edit: I can also confirm that the same "problem" happened once during the summer but got fixed.

[Milhouse]

I had to insert boot_delay=1 in config.txt to boot with higher sdram frequencies than 425 MHz; 500 MHz now works fine. Maybe it works for you, too? I haven't checked if it's still necessary for me with newer versions as this behavior already appeared in summer. For raspbian, however, this parameter isn't necessary at all, so this seems to be a bit kernel specific.

Thanks hpbaxxter - boot_delay=1 has got me back to sdram_freq=600!

[tuxen]

No idea look it up (2 words in google). What I do know is that openELEC3 B5 is released running RC1.
Can we get a small list of changes if we ask nicely sraue? (:

Well I take it you didnt google it as it doesnt say anywhere that its avaialable in the Pi builds, so thats why I asked here.

Well now I put the two words into google and got this: http://wiki.openelec.tv/index.php?title=...d_Hardware
I even spell out what it says:

Works: yes
Chipset: AX88178
Type: USB
Notice: Most "no name" brand USB Gigabit NIC's use this chipset and you can get cards for $10-15. The ASIX chipset is supported in all images and works great. Ideal for AppleTV's where the onboard 10/100 NIC struggles with bigger 1080p files

So next time google how to use google maybe. (; I'm kidding dude. But something must have went wrong for you when typing the 2 words.

[Milhouse]

In the context of streaming, what's a "bigger" 1080p file?

I'm able to watch >18GB BluRay raw rips (VC-1, 22Mbps overall bit rate) without a problem on a Pi with its wired 10/100 Ethernet-over-USB NIC. Over NFS, watching this type of movie doesn't even utilise 50% of the Pis eth0 capacity, typically about 3.5MB/s, although it does sometimes hit 5MB/s (50% utilisation) when starting the movie.

So I have to ask, what benefit is there to be had from this AX88178 Gig NIC, as I'm not sure the Pi needs it or would even be able to make use of it (could the Pi really handle a greater than 10MB/s stream?)

---

In Beta 5 (as in Beta 3), the "Info" button on the remote is still not functioning in the "Movies" view. It does however now work in TV Shows and Music, which is an improvement on Beta 3.

[caravela]

In the context of streaming, what's a "bigger" 1080p file?

I'm able to watch >18GB BluRay raw rips (VC-1, 22Mbps overall bit rate) without a problem on a Pi with its wired 10/100 Ethernet-over-USB NIC. Over NFS, watching this type of movie doesn't even utilise 50% of the Pis eth0 capacity, typically about 3.5MB/s, although it does sometimes hit 5MB/s (50% utilisation) when starting the movie.

So I have to ask, what benefit is there to be had from this AX88178 Gig NIC, as I'm not sure the Pi needs it or would even be able to make use of it (could the Pi really handle a greater than 10MB/s stream?)

---

In Beta 5 (as in Beta 3), the "Info" button on the remote is still not functioning in the "Movies" view. It does however now work in TV Shows and Music, which is an improvement on Beta 3.

None, The bottleneck is the USB and SMB (windows shares) using high CPU

[goujam]

No idea look it up (2 words in google). What I do know is that openELEC3 B5 is released running RC1.
Can we get a small list of changes if we ask nicely sraue? (:

Well I take it you didnt google it as it doesnt say anywhere that its avaialable in the Pi builds, so thats why I asked here.

Well now I put the two words into google and got this: http://wiki.openelec.tv/index.php?title=...d_Hardware
I even spell out what it says:

Works: yes
Chipset: AX88178
Type: USB
Notice: Most "no name" brand USB Gigabit NIC's use this chipset and you can get cards for $10-15. The ASIX chipset is supported in all images and works great. Ideal for AppleTV's where the onboard 10/100 NIC struggles with bigger 1080p files

So next time google how to use google maybe. (; I'm kidding dude. But something must have went wrong for you when typing the 2 words.

Now I do feel stupid as ive been on that exact page and didnt notice the bit about being in all images. I had checked github and noticed the driver was put into the ATV openelec but could find anything related to the RPI.


With reguards needing the gigabit network Im having problems playing some files over network that work fine when played off USB. The example file would be the Terminator 2 lossless THX file which can be downloaded free. This file will play but no matter what I try it buffers, this is using NFS mounts in autostart.sh. What I wanted to try is to use the USB to gigabit adaptor to try and see if the file could play with that, I understand that gigabit is not achieveable and the theoretical maximum is 480Mbit/s however that should be much better than the 10/100 connection currently used.

By the way the file im using is VC-1 and overall maximum bitrate is 48.0 Mbps, I know if I convert the DTS-MA to DTS this bitrate will drop but I want to keep the DTS-MA in my rips to use on other media players. I have also noticed when playing this file my CPU is at almost 95% the whole time its playing even when playing off USB stick.

[Milhouse]

Is there a link for this Terminator 2 file? DTS-MA and Dolby TrueHD is not playable (yet) on the Pi, expect extremely choppy performance.

[goujam]

Is there a link for this Terminator 2 file? DTS-MA and Dolby TrueHD is not playable (yet) on the Pi, expect extremely choppy performance.

Yes the link is http://www.demo-world.eu/trailers/high-d...ailers.php

If you scroll down to the THX files you will see the lossless one. I know that DTS-MA and TrueHD are not supported yet but the PI does take the DTS-MA and ouput the DTS core. Maybe this is taking up CPU cycles on the PI to extract the DTS core, however the file plays fine from USB

[Milhouse]

Yes, that file buffers over XBMC NFS mounts in Beta5, but it's only utilising 25% of the network (2.5MB/s), and the CPU is pegged at 100% so I doubt a Gig NIC will help here unless it can somehow reduce the CPU load.

The file plays fine from SD card (Class 10, Transcend) as the Pi doesn't have to expend CPU cycles in order to service the USB interrupts caused by the network traffic, although even from SD card the Pi (overclocked 1000/500/600) will come close to exhausting the audio queue so only narrowly avoids a stutter. When playing back from the network, the audio queue does become exhausted resulting in a stutter/buffer, simply because there isn't enough CPU available to get the data in time from the network and also decode the video/audio.

It's not really a case of the Pi NIC having insufficient bandwidth to play the movie, more a case of ethernet-over-USB being a rather inefficient (but cheap) design from a CPU loading perspective, and I doubt a different USB NIC will help here, but do let us know how you get on if you take this route.

[goujam]

Yes, that file buffers over XBMC NFS mounts in Beta5, but it's only utilising 25% of the network (2.5MB/s), and the CPU is pegged at 100% so I doubt a Gig NIC will help here unless it can somehow reduce the CPU load.

The file plays fine from SD card (Class 10, Transcend) as the Pi doesn't have to expend CPU cycles in order to service the USB interrupts caused by the network traffic, although even from SD card the Pi (overclocked 1000/500/600) will come close to exhausting the audio queue so only narrowly avoids a stutter. When playing back from the network, the audio queue does become exhausted resulting in a stutter/buffer, simply because there isn't enough CPU available to get the data in time from the network and also decode the video/audio.

It's not really a case of the Pi NIC having insufficient bandwidth to play the movie, more a case of ethernet-over-USB being a rather inefficient (but cheap) design from a CPU loading perspective, and I doubt a different USB NIC will help here, but do let us know how you get on if you take this route.

Thanks for your feedback its most helpful, I assumed that it was network speed slowing it down. Why do you think the CPU is at almost 100% all the time? Is it the fact it needs to extract the DTS core from the DTS-MA, If so im sure that if we get the DTS-MA pass thru liecence this file should play fine.

It also explains the reason why SMB is so terrible at plaing this file due to the extra cpu load.

[yantoucan]

Hey goujam
Do you use Heatsinks on your overclocked RPI?

[Milhouse]

Thanks for your feedback its most helpful, I assumed that it was network speed slowing it down. Why do you think the CPU is at almost 100% all the time? Is it the fact it needs to extract the DTS core from the DTS-MA, If so im sure that if we get the DTS-MA pass thru liecnce this file should play fine.

It also explains the reason why SMB is so terrible at plaing this file due to the extra cpu load.

Yes, the additional ARM CPU processing required to extract the DTS core from DTS-MA will most likely mean that such movies will be choppy over the network (and possibly SD card too) until this workload is transferred to the GPU. Fingers crossed this happens, but obtaining the necessary licences now seems to be the stumbling block.