• 1
  • 179
  • 180
  • 181(current)
  • 182
  • 183
  • 277
OpenELEC Testbuilds for RaspberryPi Part 2
(2014-01-29, 22:57)jpcolin Wrote: Hi,

I'm sorry to ask this, but i'm reading this threat for a while now, found a lot of info, but i can't find (the right and succes) how to install this builds.
Can someone give me a link to a good clear tutorial?
I can install img files but not this Tar, i know i have to "unzip" it but what then.

Thank you

Hi just to that i managed to install Millhouse build on my Pi using this "how to"
http://tasksofohm.wordpress.com/hardware...pberry-pi/

I'm using windows so the wiki did not help me.

thanks for the work millhouse, it seems to work great, i seems as "fast" if not faster in the menus as my ATV2.
The only problems i have but i might be related to gotham, is
- with the subtitles, really slow to find the subtitles. and it does not always works
- some "stutering" with fast scenes, i read about the 25hz, 50 and 60 problem, but at first look changing the setting does not seems to make a difference

Next step is to install a USB stick.

Regards and keep going on.
(2014-02-01, 17:32)jpcolin Wrote: - some "stutering" with fast scenes, i read about the 25hz, 50 and 60 problem, but at first look changing the setting does not seems to make a difference

Make sure "Adjust display refresh rate to match video" is turned on:
http://wiki.xbmc.org/index.php?title=Settings/Videos
New OpenELEC Gotham build: #0202
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.13.1 #1 PREEMPT Sun Feb 2 05:31:11 GMT 2014 armv6l GNU/Linux

# vcgencmd version
Jan 28 2014 18:56:53
Copyright (c) 2012 Broadcom
version 8966c433ecd9358a1cdab717d2a1b89999464b10 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140202053003-r17587-g0c71539

Based on tip of XBMC master (fc8358e, changelog) and tip of OpenELEC master (0c71539, changelog) with the following modifications:
  • Includes newclock3 commits (except for 0bba8cc which I've replaced with a static spinner)
  • Excludes the OpenELEC fernetmenta patches (due to conflict with newclock3)
Build Higlights:
  1. XMBC: Statically linked ffmpeg
  2. newclock3: Ben Avison patches that should help with text rendering speed
  3. popcornmix: ALSA support enabled - quoting popcornmix:
    Quote:I've been playing with enaling alsa on openelec. Apply this patch, and you should have a new option in audio settings to enable an ALSA device.
    By default that will just have the bcm2835 alsa driver. It should work, but is a longer route than Pi sink, so is only interesting for testing.

    In theory if you have a supported alsa device plugged in (USB or I2S), you may get more options showing up.
    Unfortunately I don't have a USB alsa device, but it might be worth pushing out to see if anyone has any luck with it.

    As usual, it will only work with gui sounds, paplayer and dvdplayer.

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).
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Hi Guys,

Thanks for your ongoing work.

Do the latest alsa changes resolves the crackling/clicking issue?

https://github.com/raspberrypi/linux/issues/320

Thanks.
I've just upgrade to latest MilhouseVH build.

Not sure if this is new to this build, but I'm seeing issues with step back and rewind (controlled via IR remote) when playing a movie with DVDPlayer.

When stepping back the sound jumps back and continues from the correct point (or so it seems) while the picture just freezes (or starts to play very slowly) at the point it was at. The picture sometimes recovers when the sound 'catches up' to the point the video is frozen at.

When rewinding the picture and sound go back to different points and play out of sync for a while (seconds) until the picture (in a very jerky manner) 'catches up'.

No problems with step forward or fast forward, and also no apparent problems with OMXplayer.
(2014-02-02, 10:31)b1m1 Wrote: Do the latest alsa changes resolves the crackling/clicking issue?

https://github.com/raspberrypi/linux/issues/320

That issue doesn't affect xbcm (which doesn't use alsa).
@popcornmix

Thanks, that is disappointing to hear Smile as I have been experiencing clicking and crackling in the last couple of builds.

I had my pi connected directly to my tv which only supports 2ch PCM and I was experiencing this type of distortion.

This prompted me to connect to my Amp which supports the common codecs and switch on pass through but the clicks and crackling still persist.

Thanks for your feedback and great support.

Will have a look through my settings and check my media files to see if I can find a fault.
Hi, just a question for popcorn, on your youtube video, (wich seems a lot faster than my setup, but still have to do the usb stick trick), is your GUI setup in 720 or 1080?
Of course the movie play in 1080p right?
(2014-02-02, 15:12)jpcolin Wrote: Hi, just a question for popcorn, on your youtube video, (wich seems a lot faster than my setup, but still have to do the usb stick trick), is your GUI setup in 720 or 1080?
Of course the movie play in 1080p right?

GUI resolution and HDMI resolution were both 1080p in video.
I know it's a bit OT and I'll start a new thread for further advice depending on the answer to this question but I was wondering if there's any way for me to add an OpenVPN server to my OE install?

I could use another RPi just for that but it seems a bit wasteful, as I'll only be connecting to the OpenVPN server when I'm out and thus not using XBMC, so using one RPi for both seems more sensible and cuts down on clutter/cabling/PSUs.

I realise I can't expect any support with such a non-standard OE install but I'm just asking if there's a way to do this, as I see apt-get is locked out in OE so I can't just install OpenVPN that way?
Questien regarding the "Audio output"->"Normalize levels on downmix"

I have a 2 speaker setup (screen only), and installed last Milhouse build r17587.

Here my "Audio output" settings:
Audio output device = HDMI
Number of channels = 2.0
Stereo upmix = Disable
Normalize levels on downmix = Enable
.
"The rest is default"

When I play a 5.1 content movie, the sound is LOW on my system
If I Disable the "Normalize levels on downmix", the sound is NORMAL/HIGH.

Hmmm.. Am I missing somthing.. Is that not the function of "Normalize levels on downmix", to give higher sound, when enabled ?
I looks to me, that this setting is reversed, or am I misunderstanding something ?

Best regards.

Btw: I use omxplayer, and the 5.1 audio/video content, is DVD/MPEG2/ISO.
(2014-02-02, 15:45)doveman2 Wrote: I know it's a bit OT and I'll start a new thread for further advice depending on the answer to this question but I was wondering if there's any way for me to add an OpenVPN server to my OE install?

I could use another RPi just for that but it seems a bit wasteful, as I'll only be connecting to the OpenVPN server when I'm out and thus not using XBMC, so using one RPi for both seems more sensible and cuts down on clutter/cabling/PSUs.

I realise I can't expect any support with such a non-standard OE install but I'm just asking if there's a way to do this, as I see apt-get is locked out in OE so I can't just install OpenVPN that way?

http://openelec.tv/forum/69-network/6671...ution-open ?
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
I'm not sure if this is a development build issue or not but I'm having some problems with timeouts on my NFS mounted /storage

cmdline.txt
Code:
ip=10.150.213.5::10.150.213.30:255.255.255.224:OpenELEC:eth0:off boot=LABEL=SYSTEM disk=NFS=10.150.213.2:/volume1/openelec console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 ssh

Code:
OpenELEC:~ # mount | grep 10.150.213.2
10.150.213.2:/volume1/openelec on /storage type nfs (rw,noatime,vers=3,rsize=131072,wsize=131072,namlen=255,soft,nolock,proto=tcp,port=2049,timeo=3,retrans=2,sec=sys,local_lock=all,addr=10.150.213.2)

The NFS server is connected to the same switch as the Pi.

The timeouts seem to occur randomly but I can usually reproduce them by transferring a lot of data to/from the NFS mount at the same time:

Code:
OpenELEC:~ # dd if=/dev/zero of=/storage/test.data bs=8M count=512
512+0 records in
512+0 records out
4294967296 bytes (4.0GB) copied, 420.484441 seconds, 9.7MB/s
OpenELEC:~ # dmesg | grep nfs
OpenELEC:~ # cp /storage/test.data /storage/test2.data
cp: write error: Input/output error
OpenELEC:~ # dmesg | grep nfs
[136858.199309] nfs: server 10.150.213.2 not responding, timed out
[136858.207228] nfs: server 10.150.213.2 not responding, timed out
[136858.231235] nfs: server 10.150.213.2 not responding, timed out
[136858.231657] nfs: server 10.150.213.2 not responding, timed out
[136858.231918] nfs: server 10.150.213.2 not responding, timed out
[136858.248969] nfs: server 10.150.213.2 not responding, timed out
[136858.261939] nfs: server 10.150.213.2 not responding, timed out

What I've found is that if I change the rsize and wsize to smaller values, I don't have any problems:
Code:
OpenELEC:~ # mkdir /var/media/test
OpenELEC:~ # mount -o rw,noatime,vers=3,rsize=32768,wsize=32768,soft,nolock,proto=tcp,timeo=3,retrans=2 10.150.213.2:/volume1/openelec /var/media/test
OpenELEC:~ # mount | grep 10.150.213.2
10.150.213.2:/volume1/openelec on /storage type nfs (rw,noatime,vers=3,rsize=131072,wsize=131072,namlen=255,soft,nolock,proto=tcp,port=2049,timeo=3,retrans=2,sec=sys,local_lock=all,addr=10.150.213.2)
10.150.213.2:/volume1/openelec on /var/media/test type nfs (rw,noatime,vers=3,rsize=32768,wsize=32768,namlen=255,soft,nolock,proto=tcp,port=2049,timeo=3,retrans=2,sec=sys,local_lock=all,addr=10.150.213.2)
OpenELEC:~ # dmesg -c >/dev/null
OpenELEC:~ # cp /var/media/test/test.data /var/media/test2.data
OpenELEC:~ # dmesg | grep nfs

Is there a way to change the default wsize and rsize for NFS /storage when it's mounted via cmdline.txt?
Hi May I make some comments?
Yes you should be able to change the read/wite size when mounting, see the man pages (welI I can on Solaris)

Anyway the real worry for me, your mounting the NFS mount with SOFT option, generally
you should NEVER do this if your going to write to it, and really unlikely even if its read only
unless you have multiple source to switch bettween, with specialist code to detect that etc.

So always mount NFS with HARD "hard" as the option. Now that is based on quite old
knowledge, but I can't see that level of fundamental approach changing :-)

So please mount it hard, the timeouts will still happen, but you will not loose data
ie get the IO errors your seeing, especally dangerous post flush() when the code
does not bother to check the return you effectively get silent data corruption.

Enjoy.
JB


Code:
OpenELEC:~ # mount | grep 10.150.213.2
10.150.213.2:/volume1/openelec on /storage type nfs (rw,noatime,vers=3,rsize=131072,wsize=131072,namlen=255,soft,nolock,proto=tcp,port=2049,timeo=3,retrans=2,sec=sys,local_lock=all,addr=10.150.213.2)

The NFS server is connected to the same switch as the Pi.

The timeouts seem to occur randomly but I can usually reproduce them by transferring a lot of data to/from the NFS mount at the same time:

Code:
OpenELEC:~ # dd if=/dev/zero of=/storage/test.data bs=8M count=512
512+0 records in
512+0 records out
4294967296 bytes (4.0GB) copied, 420.484441 seconds, 9.7MB/s
OpenELEC:~ # dmesg | grep nfs
OpenELEC:~ # cp /storage/test.data /storage/test2.data
cp: write error: Input/output error
OpenELEC:~ # dmesg | grep nfs
[136858.199309] nfs: server 10.150.213.2 not responding, timed out
[136858.207228] nfs: server 10.150.213.2 not responding, timed out
[136858.231235] nfs: server 10.150.213.2 not responding, timed out
[136858.231657] nfs: server 10.150.213.2 not responding, timed out
[136858.231918] nfs: server 10.150.213.2 not responding, timed out
[136858.248969] nfs: server 10.150.213.2 not responding, timed out
[136858.261939] nfs: server 10.150.213.2 not responding, timed out

What I've found is that if I change the rsize and wsize to smaller values, I don't have any problems:
Code:
OpenELEC:~ # mkdir /var/media/test
OpenELEC:~ # mount -o rw,noatime,vers=3,rsize=32768,wsize=32768,soft,nolock,proto=tcp,timeo=3,retrans=2 10.150.213.2:/volume1/openelec /var/media/test
OpenELEC:~ # mount | grep 10.150.213.2
10.150.213.2:/volume1/openelec on /storage type nfs (rw,noatime,vers=3,rsize=131072,wsize=131072,namlen=255,soft,nolock,proto=tcp,port=2049,timeo=3,retrans=2,sec=sys,local_lock=all,addr=10.150.213.2)
10.150.213.2:/volume1/openelec on /var/media/test type nfs (rw,noatime,vers=3,rsize=32768,wsize=32768,namlen=255,soft,nolock,proto=tcp,port=2049,timeo=3,retrans=2,sec=sys,local_lock=all,addr=10.150.213.2)
OpenELEC:~ # dmesg -c >/dev/null
OpenELEC:~ # cp /var/media/test/test.data /var/media/test2.data
OpenELEC:~ # dmesg | grep nfs

Is there a way to change the default wsize and rsize for NFS /storage when it's mounted via cmdline.txt?
[/quote]
Guys the mount of /Storage from cmdline.txt would appear to be a SOFT mount from markius's output.

this is very dangerous as the writes will time out on busy/overloaded servers leading to possible data corruption, I believe.

Should he riase bug on openelec, or our builds for RPI builds?

For sort of an interesting discussion I saw this.. http://discussions.citrix.com/topic/2743...ard-mount/
So they have made changes for NFS-Version 3, but HARD is still probabily the way to go,
  • 1
  • 179
  • 180
  • 181(current)
  • 182
  • 183
  • 277

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 223