(2012-12-13, 00:00)tuxen Wrote: 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? (:

(2012-12-13, 02:46)MilhouseVH Wrote: 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?

(2012-12-13, 13:48)hpbaxxter Wrote: 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.

(2012-12-13, 09:46)goujam Wrote:

(2012-12-13, 00:00)tuxen Wrote: 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.

(2012-12-13, 14:55)MilhouseVH Wrote: 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.

(2012-12-13, 14:37)tuxen Wrote:

(2012-12-13, 09:46)goujam Wrote:

(2012-12-13, 00:00)tuxen Wrote: 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=Supported_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.

(2012-12-13, 16:52)MilhouseVH Wrote: 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.

(2012-12-13, 17:19)MilhouseVH Wrote: 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.

(2012-12-13, 17:32)goujam Wrote: 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.