[Milhouse]

New OpenELEC Gotham build: #0213
(Supercedes previous build)

Code:

# uname -a
Linux rpi512 3.13.2 #1 PREEMPT Thu Feb 13 00:07:27 GMT 2014 armv6l GNU/Linux

# vcgencmd version
Feb 12 2014 20:29:25
Copyright (c) 2012 Broadcom
version 981c14ae8229477232a0349d9c3abbedbfa68d99 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140213002229-r17700-g56e8f72

Based on tip of XBMC master (a74973f, changelog) and tip of OpenELEC master (1510929, changelog) with the following modifications:

• Includes newclock3 commits (except for ddcc72e which I've replaced with a static spinner)
  
• Excludes the OpenELEC fernetmenta patches (due to conflict with newclock3)
  
• "Show RSS Feed" default setting changed to disabled
  

Build Higlights:

1. Firmware: Updated to 12 Feb release:
   • Fix crash that could occur when passthrough dts packet is short
     
   • Set validity bit for audio passthrough formats to avoid noise when unsupported by tv/receiver
     
   • Increase allowed clock drift from 50ms to 100ms to avoid video stutters
     
   This should make max_clock_drift_rate unnecessary. max_clock_drift has been increased to 100ms in firmware, so both these two options can now be removed from config.txt.
   
2. OpenELEC: Now has support for I2S ALSA cards like HifiBerry
   

---

Additional Testing Notes:

1. Testers should try adding the following entry to their advancedsettings.xml:
   
   Code:

   <advancedsettings>
  <video>
    <defaultplayer>dvdplayer</defaultplayer>
    <defaultdvdplayer>dvdplayer</defaultdvdplayer>
  </video>
</advancedsettings>
   and report if it is better/worse than omxplayer. You can still play files with omxplayer using the context-menu "Play using... OMXPlayer".
   

   ---

2. The following settings are no longer required in config.txt and should be removed:
   
   Code:

   no_hdmi_resample=1
hdmi_stream_channels=1
   no_resample_audio is now a default, and hdmi_stream_channels is switched based on audio content. For the time being when using passthrough, 2.0 speaker layout should continue to be used (you will still get 5.1 with AC3/DTS).
   

[gusmin]

Hallo,

I use Openelec stable with SD+USB Installation. Last night i tried the latest Milhouse build before today by installing the build to another SD card with the same procedure that i followed with the stable one except of the USB part where i used the same USB as storage Also i used the same overclocked settings in config.txt (1000/500/500/6) with which the stable version runs without any freezing.

The problems that i had were:

- All videos either from Nas or Streaming Services played as Audio and not Video
- When i got to setting in whatever option i tried to get into (Video, Audio , System etc.) the system freezes.

Thank you

[Milky-Joe]

I've only been using Gotham since the 2014-2-10 build (and I'm now running the 20140-2-13 build), but I'm having a few issues (using OMXPlayer):

- Sometimes, when playing a movie, only the sound plays (I can still navigate around my movies)
- Sometimes, when starting a video, the screen goes black and nothing happens *
- Some movies refuse to start (I haven't figured out if there's a pattern yet)
- DVDPlayer is too unstable, and keeps freezing

I am using caching (with a 64Mb buffer), and I have configured NFS with a rsize of 32k, but everything else is pretty much stock.

* Once this has happened, I've had the Pi refuse to reboot - it froze after clicking Quit > Reboot

[Milhouse]

There have been a number of ffmpeg related changes in XBMC (and more to come from the OpenELEC side), I wonder if this could be the reason for payback problems...

[popcornmix]

I've only been using Gotham since the 2014-2-10 build (and I'm now running the 20140-2-13 build), but I'm having a few issues (using OMXPlayer):

- Sometimes, when playing a movie, only the sound plays (I can still navigate around my movies)
- Sometimes, when starting a video, the screen goes black and nothing happens *
- Some movies refuse to start (I haven't figured out if there's a pattern yet)
- DVDPlayer is too unstable, and keeps freezing

I am using caching (with a 64Mb buffer), and I have configured NFS with a rsize of 32k, but everything else is pretty much stock.

* Once this has happened, I've had the Pi refuse to reboot - it froze after clicking Quit > Reboot

What do you have gpu_mem set to? Must be at least 128.

[Milky-Joe]

I've only been using Gotham since the 2014-2-10 build (and I'm now running the 20140-2-13 build), but I'm having a few issues (using OMXPlayer):

- Sometimes, when playing a movie, only the sound plays (I can still navigate around my movies)
- Sometimes, when starting a video, the screen goes black and nothing happens *
- Some movies refuse to start (I haven't figured out if there's a pattern yet)
- DVDPlayer is too unstable, and keeps freezing

I am using caching (with a 64Mb buffer), and I have configured NFS with a rsize of 32k, but everything else is pretty much stock.

* Once this has happened, I've had the Pi refuse to reboot - it froze after clicking Quit > Reboot

What do you have gpu_mem set to? Must be at least 128.

I have a model B Pi, and my config is as follows:

Code:

gpu_mem=128
gpu_mem_256=100
gpu_mem_512=128
arm_freq=950
core_freq=450
sdram_freq=450
over_voltage=6
force_turbo=0
avoid_fix_ts=0

And I'm running from a USB 3.0 memory stick.

[popcornmix]

Code:

gpu_mem=128
gpu_mem_256=100
gpu_mem_512=128
arm_freq=950
core_freq=450
sdram_freq=450
over_voltage=6
force_turbo=0
avoid_fix_ts=0

And I'm running from a USB 3.0 memory stick.

That will set gpu_mem to 100 for a 256M Pi, and 128 for a 512M Pi.
I'd suggest you change to:
gpu_mem_256=128

if you have a 256M Pi.

Code:

vcgencmd get_mem gpu

will make it clear what is configured.

[Jönke]

@popcornmix
Should it look like this ? Empty under SDRAM size based GPU memory split....

#default GPU memory split (do not change if you do not know what you are doing)
gpu_mem=128

# SDRAM size based GPU memory split, uncomment and setup to override 'gpu_mem'

[popcornmix]

@popcornmix
Should it look like this ? Empty under SDRAM size based GPU memory split....

#default GPU memory split (do not change if you do not know what you are doing)
gpu_mem=128

# SDRAM size based GPU memory split, uncomment and setup to override 'gpu_mem'

From what you've shown you have gpu_mem=128 which should be fine. Use the vcgencmd I posted to be sure.

[Milky-Joe]

Code:

gpu_mem=128
gpu_mem_256=100
gpu_mem_512=128
arm_freq=950
core_freq=450
sdram_freq=450
over_voltage=6
force_turbo=0
avoid_fix_ts=0

And I'm running from a USB 3.0 memory stick.

That will set gpu_mem to 100 for a 256M Pi, and 128 for a 512M Pi.
I'd suggest you change to:
gpu_mem_256=128

if you have a 256M Pi.

Code:

vcgencmd get_mem gpu

will make it clear what is configured.

I have a Model B (512Mb), and the gpu value is 128 (after running that statement).

[popcornmix]

I have a Model B (512Mb), and the gpu value is 128 (after running that statement).

Should be okay, but you could changing to
gpu_mem_512=256
just to rule out memory. Posting a debug may have some clues.

[User 99401]

I have a Model B (512Mb), and the gpu value is 128 (after running that statement).

Should be okay, but you could changing to
gpu_mem_512=256
just to rule out memory. Posting a debug may have some clues.

@popcornmix
Following that note - is it safe to say that for Model B we should be using gpu_mem_512=256 on a normal basis?
thanks for clarifying it

[popcornmix]

@popcornmix
Following that note - is it safe to say that for Model B we should be using gpu_mem_512=256 on a normal basis?
thanks for clarifying it

No, 128M is the recommended value. There are some circumstances where this isn't enough, so if you are having problems, then increasing this value is a useful test point.
If the problems go away, then we know your use case is using more than 128M of gpu_mem and can investigate further.

[bAD kLOPFER]

- All videos either from Nas or Streaming Services played as Audio and not Video
- When i got to setting in whatever option i tried to get into (Video, Audio , System etc.) the system freezes.

I got these problems with some of the builds too. Renaming or deleting the guisettings.xml fixed them for me. After that your gui is back to stock configuration so it might be a good idea renaming guisettings.xml to .bak i.e. to check if it helps. If this isn't the cause you can still rename it back.

[User 99401]

@popcornmix
Following that note - is it safe to say that for Model B we should be using gpu_mem_512=256 on a normal basis?
thanks for clarifying it

No, 128M is the recommended value. There are some circumstances where this isn't enough, so if you are having problems, then increasing this value is a useful test point.
If the problems go away, then we know your use case is using more than 128M of gpu_mem and can investigate further.

thanks for clearing this up
128 works great atm for me