Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi Part 2 - Printable Version

Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166)
---- Thread: OpenELEC Testbuilds for RaspberryPi Part 2 (/showthread.php?tid=184866)



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-09-30

(2013-09-30, 21:17)misa Wrote: Maybe a stupid question....I am also testing this build and have the replace files.....but do I have to rename them to start.elf and fixup.dat?

Yes.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - h.udo - 2013-09-30

(2013-09-30, 12:57)popcornmix Wrote: If you have usb problems on 3.2.1, can you report:
Code:
vcgencmd version

Done.
Code:
OpenELEC (official) Version: 3.2.1
OpenELEC:~ # vcgencmd version
Sep 23 2013 21:35:27
Copyright (c) 2012 Broadcom
version cb10351d8eb5ab63122f62df8a9875e7588fc3c7 (clean) (release)

Doesn't boot with USB (disk=/dev/sda1). It shows message "can't find /dev/sda1 bla-bla-bla" after a very long time. Don't know exactly how long, I was cooking dinner. Took some photos if you're interested. Boots after a few minutes with original cmdline.txt, using only the SD card.


(2013-09-30, 16:46)popcornmix Wrote: People with USB issues on 3.2.1 can you try updating firmware manually. Download:
https://github.com/Hexxeh/rpi-firmware/raw/master/start_x.elf
https://github.com/Hexxeh/rpi-firmware/raw/master/fixup_x.dat

and replace start.elf and fixup.dat on the boot partition of sdcard. Let me know if it fixes it.

Working 133%! My RPi now boots in ~20s.

You're the man! Thanks.

BR


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - misa - 2013-09-30

Mine is booting ok with this build USB.SD and the replace files

16GB Transcend USB stick and 4GB class 4 SD card


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-09-30

(2013-09-29, 20:40)MilhouseVH Wrote:
(2013-09-29, 20:20)hudo Wrote: First problem encountered: Shutdown and reboot don't work. Both kill xbmc and restart it.

That's been broken in Gotham builds for a while - xbmc.bin segfaults when exiting and consequently it's impossible to power off/reboot. I'm sure it's on the list of things to do!

I caught it in debugger, seems to be a python init/deinit issue. Reverting this (and a few related commits) seems to fix it:
https://github.com/xbmc/xbmc/commit/69aac04b0da9f34e8dda2af7bb7753a005a13e78

I've reported it.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - allan87 - 2013-09-30

Popcornmix, could you please explain what you mean here?
(2013-09-28, 16:45)popcornmix Wrote: Note currently the switch between 720p limit and no limit doesn't fix up guisettings.xml. EIther delete it and reboot, or edit the overscan settings in the resolutions group.
(using the calibration option may well work).



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-09-30

(2013-09-30, 22:59)popcornmix Wrote: I've reported it.

Thanks popcornmix.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-10-01

(2013-09-30, 23:30)allan87 Wrote: Popcornmix, could you please explain what you mean here?
(2013-09-28, 16:45)popcornmix Wrote: Note currently the switch between 720p limit and no limit doesn't fix up guisettings.xml. EIther delete it and reboot, or edit the overscan settings in the resolutions group.
(using the calibration option may well work).

In guisettings.xml there are entries like:
Code:
<resolution>
            <description>1920x1080 @ 60.00i - Full Screen</description>
            <subtitles>694</subtitles>
            <pixelratio>1.000000</pixelratio>
            <overscan>
                <left>0</left>
                <top>0</top>
                <right>1280</right>
                <bottom>720</bottom>
            </overscan>
        </resolution>

which describe the physical display size (1920x1080) and also the GUI display size (1280x720).
Unfortunately the GUI size is used for calibration settings (it should really be the physical display size).

If you start with the gui resolution limit at 720p, and then remove it, currently the right and bottom calibration settings will remain at
1280x720, but the GUI resolution is now 1920x1080, so your GUI will only occupy the top/left part of display.

You can edit these (I believe) in xbmc using the calibration menu (you may need to do this for each resolution).
Or you can open guisettings.xml and edit the all the 1280/720 to 1920/1080.
You should also move the subtitles setting from 694 to 1040.

I'll try to get an automatic scheme for this in the future.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - bircoe - 2013-10-01

Hi popcornmix, just wanted to report some strangeness with the sort order/stacking of non library folders, I've got 2 Pi's here, they were both recently updated to OpenELEC 3.2.1. After I noticed this I downgraded one of the Pi's to 3.2.0 and found the sort order/stacking works as expected. I've checked through all the settings and can't find an option that changes this behaviour. Also strangely the parent folder link (..) sometimes ends up somewhere in the list other than the top... very unexpected.

On 3.2.1 the folders are not stacked at the top of the folder list, 3.2.1 is running XBMC 12.2 Git:cd71444 (Compiled: Sep 28 2013):

Image

On 3.2.0 the folders are stacked... 3.2.0 is running XBMC 12.2 Git:68a881d (Compiled: Sep 13 2013):

Image

I've raised this with sraue and he suggested posting here as it may be due to a recent commit:
https://github.com/OpenELEC/xbmc/commit/d2f23e3b8a7359663e35e31619b990017e5901c5
https://github.com/OpenELEC/xbmc/commit/7e6a30959fb2773de52bd2416b23bac42fac640d

UPDATE: Other users over at the OpenELEC forums have noted the same behaviour.
http://openelec.tv/forum/90-miscellaneous/67364-folders-first-sorting#87524


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-10-01

I see the same folder/file mix in Gotham when sorting by Name - I'd forgotten that folders were meant to be sorted first.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - javaboyuk - 2013-10-01

(2013-09-30, 16:51)popcornmix Wrote:
(2013-09-21, 21:22)javaboyuk Wrote: Alas with the
hdmi_force_open=1
With 3.1.6 and still with 3.2 on my Raspberry PI, I find if I "jump" to the next song or skip forward in the song my raspberry will loop playing the "current" 1/4 second of music and you have to reboot the PI to stop this, unplugging and plugging th HDMI does not fix it, and nor does trying to stop, play another track etc work. However I can still reboot the PI.

(Note I am controlling the PI vi the XBMC remote controller on my iPhone over wifi.)

So looks like a firmware/driver issueHuh
Any suggestions who I can talk to about this, happy to help.

I spent some time stepping through the code and believe I have fixed the issue.
I've also tried to do sane things when switching between PCM and passthrough audio.

Can you follow the update procedure in previous post, and report if the behaviour is better.

@popcornmix
Sorry only saw this this evening, so kept people up in the flat testing it... :-)

I can report that, the resync still happens, WITHOUT hdmi_force_open=1.

GREAT NEWS with "hdmi_force_open=1" no re-sync so get full track from begining,
AND you can seek again without the rpi hanging, the volume control also works
again (with or without force).

Additionally I have now tested play back of the gimell test files for
flac versions of:

stereo - 24 bit from 44100 to 96000

All played great (but can NOT confirm what the amp was receiving 24bit 96KHz until
I hook a screen up to it!)

However
=======
Issue 1:
5.1 channel versions would not play correctly and came out as only stereo.

Issue 2:
My DTS tracks don't "play" the amps DTS symbol binks on and off and I get
"snipit" of disorted sound.

Config:
My rpi is runing production 3.2.1 openelec, with your "new" firmware from
the just preious page as you suggested. My config.txt options are:
standard gpu/overclocking for 3.2.1 plus:
hdmi_force_hotplug=1
hdmi_force_edid_audio=1
hdmi_drive=2
force_hdmi_open=1

The samples are here:
http://www.gimell.com/recording-free-trial-downloads-1.aspx

or these which are easier to get
http://www.linnrecords.com/linn-downloads-testfiles.aspx

Any suggestions on the above issues greatly appreciated!!

As always really happy to test etc.

Thanks!!!


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Wanderlei - 2013-10-01

(2013-09-30, 19:11)Wanderlei Wrote: Yep, fixed it. (also replaced the bootcode.bin)

Edit, Just to be clear, I used image file of 3.2.2 to create and put those files in it and now it boots and seems ok. I didnt run a update on 3.2.1 install to 3.2.2.

Woops I meant 3.2 to 3.2.1.

Also notice that both files and folders are sorted differently.

The autostart.sh script I had to change cpu governor that wasnt working with 3.2 is now working with 3.2.1.

Its incredible how much cpu usage has decreased since 3.2, especially during video playback, amazing stuff.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - rbej - 2013-10-01

Updated Frodo Branch

- updated OpenElec build

- updated firmware and kernel

- [rbp/omxplayer] Waiting without an eos being sent does not help

- [rbp/omxplayer] For bypass renderer, renderer not started is not an error condition

http://netlir.dk/rbej/builds/

http://lysin.me/rbej


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2013-10-01

(2013-10-01, 11:02)rbej Wrote: Updated Frodo Branch

- updated OpenElec build

- updated firmware and kernel

- [rbp/omxplayer] Waiting without an eos being sent does not help

- [rbp/omxplayer] For bypass renderer, renderer not started is not an error condition

http://netlir.dk/rbej/builds/

http://lysin.me/rbej

LiveTV not working for me with this, so back to the 15/09 build for me for now http://xbmclogs.com/show.php?id=64645


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - javaboyuk - 2013-10-01

@popcornmix
Confirmed, the audio system now is happy playing *flac files up to 24bit at 196Khz and sent to the
amp as such, so amazing!!

Thank you, I suppose I will have to have more of your babies........


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-10-02

(2013-10-01, 02:30)javaboyuk Wrote: Issue 1:
5.1 channel versions would not play correctly and came out as only stereo.
That is expected. Only passthrough DTS/AC3 will be multichannel. Everything else is downmixed to stereo. Currently.

(2013-10-01, 02:30)javaboyuk Wrote: Issue 2:
My DTS tracks don't "play" the amps DTS symbol binks on and off and I get
"snipit" of disorted sound.

The samples are here:
http://www.gimell.com/recording-free-trial-downloads-1.aspx

or these which are easier to get
http://www.linnrecords.com/linn-downloads-testfiles.aspx

Can you point at a specific DTS file that is failing? Do you have DTS passthrough enabled? Did this used to work?


This forum uses Lukasz Tkacz MyBB addons.