• 1
  • 65
  • 66
  • 67(current)
  • 68
  • 69
  • 174
OpenELEC Testbuilds for RaspberryPi
(2013-01-22, 23:02)rbej Wrote: My new custom build.

http://www.mediafire.com/?10456ccz13ard

- OpenElec build r13076
- Xbmc Frodo build RC3 (22.01.2013) with 3d double framerate fix
- Rpi kernel 3.6.y (22.01.2013)
- Rpi firmware (22.01.2013)
- Pvr Addon (18.01.2013)
- Xvdr Addon (11.01.2013)
- Gpu memory set to 100mb on default (fix kernal killing Xbmc task on Rpi 256mb board)
- Memory cache set to 2621440 on default
- GUI resolution switch (taken from XBIAN)

Add to advencedsettings <guires>XXXX</guires>

XXXX = GUI resolution. 480p,720p,900p,1080p. <guires>720</guires>, <guires>1080</guires> etc...

Update Instruction:

http://openelec.tv/installation/updating

For Rpi 512Mb set gpu_mem=256, cachemembuffersize to 5242880 and change GUI to 1080p.

For Rpi 256Mb set gpu_mem=100, cachemembuffersize to 2621440 and change GUI to 900p.

or clean install:

http://wiki.openelec.tv/index.php?title=...spberry_Pi
Just a suggestion and there might be a reason but why don't you use the gpu_256_mem and gpu_mem_512 tags in config.txt so 512MB board users only have to drop the advancedsettings.xml in userdata?
(2013-01-23, 06:23)tuxen Wrote:
Code:
boot=/dev/sda1  disk=/dev/sda2  ssh  quiet

Just an FYI, but using /dev/sda1 as the boot device will cause the OpenELEC auto-update feature to fail (as it will copy the new kernel and Broadcom files to /dev/sda1 and not the SD card which is where they should go) so disable auto-update and update manually. It's the same situation with NFS booting, and although I've provided a patch for the auto-update process (to fix NFS) it hasn't been reviewed and accepted, but could easily be extended to support the Pi booting from USB (one extra line of code) as it's essentially the same problem/solution.
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.
(2013-01-23, 07:05)tuxen Wrote:
(2013-01-22, 23:02)rbej Wrote: My new custom build.

http://www.mediafire.com/?10456ccz13ard

- OpenElec build r13076
- Xbmc Frodo build RC3 (22.01.2013) with 3d double framerate fix
- Rpi kernel 3.6.y (22.01.2013)
- Rpi firmware (22.01.2013)
- Pvr Addon (18.01.2013)
- Xvdr Addon (11.01.2013)
- Gpu memory set to 100mb on default (fix kernal killing Xbmc task on Rpi 256mb board)
- Memory cache set to 2621440 on default
- GUI resolution switch (taken from XBIAN)

Add to advencedsettings <guires>XXXX</guires>

XXXX = GUI resolution. 480p,720p,900p,1080p. <guires>720</guires>, <guires>1080</guires> etc...

Update Instruction:

http://openelec.tv/installation/updating

For Rpi 512Mb set gpu_mem=256, cachemembuffersize to 5242880 and change GUI to 1080p.

For Rpi 256Mb set gpu_mem=100, cachemembuffersize to 2621440 and change GUI to 900p.

or clean install:

http://wiki.openelec.tv/index.php?title=...spberry_Pi
Just a suggestion and there might be a reason but why don't you use the gpu_256_mem and gpu_mem_512 tags in config.txt so 512MB board users only have to drop the advancedsettings.xml in userdata?

Gpu_mem_256=100 and gpu_mem_512=256 is default but i miss change changelog.




(2013-01-23, 07:01)doveman2 Wrote:
(2013-01-23, 06:23)tuxen Wrote: Also it might be the USB sticks that I have but the transfer rates was basically half of the sd card.

What did you use to benchmark them? I've benched my SD and USB on my PC with CrystalDiskMark, so I know what they can achieve but the results might be quite different on the Pi.
Just a simple dd test. But yeah I know though writing a big file can be faster on sdcard things like scanning your library and getting metadata and other saves seems faster on USB it think this is due to the hardware though.
Read speed are the same so once the library and metadata is saved and with the difference overall for me between the sdcard's I have and the USB stick's I have and particular the no overclocking problems at all I prefer using both USB connectors for hard drives instead.
And if anything using a harddrive for the Storage partition which is much faster than any USB stick.



(2013-01-23, 07:19)MilhouseVH Wrote:
(2013-01-23, 06:23)tuxen Wrote:
Code:
boot=/dev/sda1  disk=/dev/sda2  ssh  quiet

Just an FYI, but using /dev/sda1 as the boot device will cause the OpenELEC auto-update feature to fail (as it will copy the new kernel and Broadcom files to /dev/sda1 and not the SD card which is where they should go) so disable auto-update and update manually. It's the same situation with NFS booting, and although I've provided a patch for the auto-update process (to fix NFS) it hasn't been reviewed and accepted, but could easily be extended to support the Pi booting from USB (one extra line of code) as it's essentially the same problem/solution.
Ah. I was not totally aware of this although it crossed my mind. Anyway deleting the fat from the USB stick can be done in windows and then just keep the SYSTEM on mmcblk0p1, keep boot=/dev/mmcblk0p1 in cmdline.txt and bigger sd card it all should still be possible from windows. Smile thanks!
Let's hope the NFS fix gets accepted then.

(2013-01-23, 08:56)tuxen Wrote: Ah. I was not totally aware of this although it crossed my mind. Anyway deleting the fat from the USB stick can be done in windows and then just keep the SYSTEM on mmcblk0p1, keep boot=mmcblk0p1 in cmdline.txt and bigger sd card it all should still be possible from windows. Smile thanks!

Yes, if you keep boot=/dev/mmcblk0p1 (ie. SYSTEM file on the SD card FAT partition) then auto-update will work just fine. Hopefully the patch will land sooner than later as USB/NFS booting is the only sure-fire way to avoid SD card corruption and could become a more widespread option.
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.
(2013-01-22, 02:21)popcornmix Wrote: See: https://github.com/xbmc/xbmc/pull/2100

@popcorn
I tried build 0122 last night and something is not correct, I´ll try to explain.

All this has to do with HSBS 1080@24Hz and GUI in 720p with (3D-TV of course).

Previous build (0121) everything worked (GUI + 3D-signal) except for 2 things:
1. Double frame rate (50Hz) instead of 24Hz
2. Some external subtitles displayed doubled even when in 3D mode on TV (do not focus on this though, thought it might be good to know).

New build (0122) the following does not work:
1. 3D signal to TV
2. GUI is a little of. It looks like it has the wrong resolution (if necessary I can take a screen dump later, at work at the moment)

On the other hand the set frame rate now works (24Hz).

Edit: I have only tested this with OpenElec and nightly 0122. I will test this on more distros later, but it should be the same huh?

Edit2:
@popcorn
Nevermind my recent posts! I´ll wait for the merge before I try it and report back!
Sorry for any confusion.
(2013-01-23, 01:38)Wally81 Wrote:
(2013-01-22, 23:41)FattyMcDirty Wrote: and another thing: compared to openelec on my htpc, the hdmi output of the rpi seems significantly brighter and not as sharp... does that sound familiar? is there any way to improve this? got it running through hdmi and in 1080p...

I concur. The blacks aren't black but grey compared to other HDMI inputs on my LCD TV. Does a value need changing? I'd rather fix it at the Pi/XBMC level rather than messing with settings on my TV.

yes, the blacks aren't black, that right. and the image is overall kinda not that sharp. is there any way to fix this one the rpi/xbmc side? my tv is overall calibrated to my needs and is ok with my other sources... i wouldn't like to adjust that when i'm watching with the rpi...

Sorry just to clarify.

Move to SD card
bootcode.bin, cmdline.txt, config.txt,fixup.dat, kernel.img, LICENCE.broadcom,openelec.ico, README.md, start.elf and SYSTEM file

Alter cmdline.txt
boot=/dev/mmcblk0p1 disk=/dev/sda2 ssh quiet

This is correct?

With the move over to USB, is there any chance on introducing other performance problems, eg say you have a wifi adapter and have openelec on usb. (It is two usb plugs via inbuilt hub, but actually one bus, I think) So will the two devices using the same bus interfere with each other?
(2013-01-23, 09:53)FattyMcDirty Wrote: yes, the blacks aren't black, that right. and the image is overall kinda not that sharp. is there any way to fix this one the rpi/xbmc side? my tv is overall calibrated to my needs and is ok with my other sources... i wouldn't like to adjust that when i'm watching with the rpi...

Sounds like a color space problem. I wonder if either the Pi or the display device are using the wrong color standard. For example, the Pi might be generating HD images using the SD color standard Rec-601/BT.601, or the display - or more often AV amp - is displaying SD material using the HD Rec-709/BT.709 color standard (or vice versa).

Such color space conversion problems can result in color levels 0-255 (black through to white) instead being clamped 16-235. If the display device is expecting 0-255 but being fed 16-235 (or vice versa) then you can experience what you are describing.

Can't say I've noticed a particular problem yet, but them I'm only using a computer LCD monitor at this point and I'm yet to hook the Pi up to my Onkyo TX-NR905 amp (which has BT.601/BT.709 colour space conversion issues) and Philips TV.
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.
(2013-01-23, 09:16)miappa Wrote:
(2013-01-22, 02:21)popcornmix Wrote: See: https://github.com/xbmc/xbmc/pull/2100

@popcorn
I tried build 0122 last night and something is not correct, I´ll try to explain.

All this has to do with HSBS 1080@24Hz and GUI in 720p with (3D-TV of course).

Previous build (0121) everything worked (GUI + 3D-signal) except for 2 things:
1. Double frame rate (50Hz) instead of 24Hz
2. Some external subtitles displayed doubled even when in 3D mode on TV (do not focus on this though, thought it might be good to know).

New build (0122) the following does not work:
1. 3D signal to TV
2. GUI is a little of. It looks like it has the wrong resolution (if necessary I can take a screen dump later, at work at the moment)

On the other hand the set frame rate now works (24Hz).

Edit: I have only tested this with OpenElec and nightly 0122. I will test this on more distros later, but it should be the same huh?

You try my last custom build??.




(2013-01-23, 11:53)rbej Wrote: You try my last custom build??.

No, this was not your build.
I can test it tonight if you think it´ll work?

Edit: Perhaps the fix was not in the master of last nightly?
(2013-01-23, 11:05)Wanderlei Wrote: Sorry just to clarify.

Move to SD card
bootcode.bin, cmdline.txt, config.txt,fixup.dat, kernel.img, LICENCE.broadcom,openelec.ico, README.md, start.elf and SYSTEM file

Alter cmdline.txt
boot=/dev/mmcblk0p1 disk=/dev/sda2 ssh quiet

This is correct?

Yes, although you don't need to copy LICENCE.broadcom, openelec.ico and README.md, they're not required for a working system.

(2013-01-23, 11:05)Wanderlei Wrote: With the move over to USB, is there any chance on introducing other performance problems, eg say you have a wifi adapter and have openelec on usb. (It is two usb plugs via inbuilt hub, but actually one bus, I think) So will the two devices using the same bus interfere with each other?

Problems are certainly possible given the current state of the Pi USB stack but I've not noticed any problems running OpenELEC/Raspbmc entirely over NFS (the Pi implements ethernet on top of the USB bus), however two USB devices are unlikely to interfere with each other. One potential issue with two devices plugged into the on-board USB is power consumption, so just make sure you have a "decent" power supply. Generally speaking though, as long as you have a decent power supply you should be OK and not have any problems.
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.
(2013-01-23, 11:48)MilhouseVH Wrote:
(2013-01-23, 09:53)FattyMcDirty Wrote: yes, the blacks aren't black, that right. and the image is overall kinda not that sharp. is there any way to fix this one the rpi/xbmc side? my tv is overall calibrated to my needs and is ok with my other sources... i wouldn't like to adjust that when i'm watching with the rpi...

Sounds like a color space problem. I wonder if either the Pi or the display device are using the wrong color standard. For example, the Pi might be generating HD images using the SD color standard Rec-601/BT.601, or the display - or more often AV amp - is displaying SD material using the HD Rec-709/BT.709 color standard (or vice versa).

Such color space conversion problems can result in color levels 0-255 (black through to white) instead being clamped 16-235. If the display device is expecting 0-255 but being fed 16-235 (or vice versa) then you can experience what you are describing.

Can't say I've noticed a particular problem yet, but them I'm only using a computer LCD monitor at this point and I'm yet to hook the Pi up to my Onkyo TX-NR905 amp (which has BT.601/BT.709 colour space conversion issues) and Philips TV.

my pi is connected to an onkyo tx-nr616, which had no problems so far with my existing htpc, all colours and the sharpness as well was normal... that's why i've instantly noticed a difference with the pi... is there any way to fix this?

I know in the Popcorn Hour C-200 settings you can specify which color space to generate, presumably this is to work around duff displays or amps that mangle/misinterpret the colours. Not aware though of such a setting in XBMC or the Pi (config.txt). In theory such a setting shouldn't be necessary, but thanks to outfits like Onkyo it is... :-(

I'd be very surprised though if Onkyo are still stuffing up the color space conversion, as your amp is much more recent than mine.
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.
  • 1
  • 65
  • 66
  • 67(current)
  • 68
  • 69
  • 174

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi12