• 1
  • 66
  • 67
  • 68(current)
  • 69
  • 70
  • 174
OpenELEC Testbuilds for RaspberryPi
(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?

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?

Yeah but then you will have 2 SYSTEM disks though showing up under files in XBMC? Though it won't matter at all if you remove the fat one on the USB stick with windows disk manager and alter disk=/dev/sda1 in cmdline.txt you should be able to avoid this. I'm at work and would like to confirm this when I get home then we can make a final windows only guide.

I would like you also suspect that USB wifi would "interfere" but isn't the ethernet also on the same bus anyway so the result is the same in the end?
(2013-01-23, 11:58)miappa Wrote:
(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?

This fix is not in master of last nightly Raspbmc. My custom build have this fix. Try it.



I don't know why people don't use their Pi to format and prepare their USB sticks - for example:

  1. Boot the Pi from an SD card imaged with Raspbian
  2. Once the Pi has booted, connect with ssh (or type at the console using an attached USB keyboard) - username "pi", password "raspberry".
  3. Pop in your USB stick, it should be seen as /dev/sda (confirm with dmesg)
  4. Partition/format the USB memory stick using ext4 (see instructions below)
  5. Shutdown the Pi
  6. Reformat your SD card (or use another SD card - it doesn't have to be more than 100MB and they're dirt cheap!) with a single FAT partition and copy across the OpenELEC system files
  7. Configure disk=/dev/sda1 in cmdline.txt
  8. Job done - boot OpenELEC with storage on USB

Code:
sudo umount /dev/sda[1-2]
sudo parted -s /dev/sda mklabel msdos
sudo parted -s /dev/sda unit cyl mkpart primary ext2 -- 0 -2
sudo mkfs.ext4 -L Storage /dev/sda1
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, 12:30)rbej Wrote: This fix is not in master of last nightly Raspbmc. My custom build have this fix. Try it.

Ah, I see. I saw that it was in your build and thought it was in master already.
I´ll try tonight and report back.

@popcorn
Nevermind my recent posts! I´ll wait for the merge before I try it and report back!
Sorry for any confusion. :S
(2013-01-23, 12:33)MilhouseVH Wrote: I don't know why people don't use their Pi to format and prepare their USB sticks - for example:

  1. Boot the Pi from an SD card imaged with Raspbian
  2. Once the Pi has booted, connect with ssh (or type at the console using an attached USB keyboard) - username "pi", password "raspberry".
  3. Pop in your USB stick, it should be seen as /dev/sda (confirm with dmesg)
  4. Partition/format the USB memory stick using ext4 (see instructions below)
  5. Shutdown the Pi
  6. Reformat your SD card (or use another SD card - it doesn't have to be more than 100MB and they're dirt cheap!) with a single FAT partition and copy across the OpenELEC system files

I've been so scared by horror stories of the SD card slot breaking that I try to avoid removing the card as much as possible! Maybe it would be good if we could have a dual boot on a single SD card, to choose between OpenElec or Raspbian (or any trimmed down OS that will let us SSH in and format USB sticks, etc). I guess we'd need a USB keyboard plugged in to choose which to boot from but as we'd only need to occasionally boot into the other OS, plugging one in when we do shouldn't be a problem, with OpenElec auto-booting after, say 3s, otherwise.
(2013-01-23, 13:26)doveman2 Wrote: Maybe it would be good if we could have a dual boot on a single SD card, to choose between OpenElec or Raspbian (or any trimmed down OS that will let us SSH in and format USB sticks, etc). I guess we'd need a USB keyboard plugged in to choose which to boot from but as we'd only need to occasionally boot into the other OS, plugging one in when we do shouldn't be a problem, with OpenElec auto-booting after, say 3s, otherwise.

BerryBoot.
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, 08:44)tuxen Wrote: 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

I'm using a 7-port hub so I don't have to worry about using up the 2-ports Wink I'm not planning to plug a HDD directly into the Pi (or hub) but as all the media will be on a PC on the network, I'm considering storing the library on the PC as well, instead of the Pi's SD or USB stick, so the faster write speed with USB won't really benefit me. I'll still use it though, just to avoid the risk of the SD getting corrupted when overclocking.


(2013-01-23, 13:31)MilhouseVH Wrote: BerryBoot.

Indeed, but perhaps it would be good if the distros incorporated this with a suitable tiny OS for SSH/emergency access, so that we don't have to setup BerryBoot again manually everytime we have to write a new image to the SD card. That's probably less an issue with OpenElec though, as most of the time it seems we can avoid writing images and just copy the new kernel and System files to the SD.
(2013-01-23, 12:33)MilhouseVH Wrote: I don't know why people don't use their Pi to format and prepare their USB sticks - for example:

  1. Boot the Pi from an SD card imaged with Raspbian
  2. Once the Pi has booted, connect with ssh (or type at the console using an attached USB keyboard) - username "pi", password "raspberry".
  3. Pop in your USB stick, it should be seen as /dev/sda (confirm with dmesg)
  4. Partition/format the USB memory stick using ext4 (see instructions below)
  5. Shutdown the Pi
  6. Reformat your SD card (or use another SD card - it doesn't have to be more than 100MB and they're dirt cheap!) with a single FAT partition and copy across the OpenELEC system files
  7. Configure disk=/dev/sda1 in cmdline.txt
  8. Job done - boot OpenELEC with storage on USB

Code:
sudo umount /dev/sda[1-2]
sudo parted -s /dev/sda mklabel msdos
sudo parted -s /dev/sda unit cyl mkpart primary ext2 -- 0 -2
sudo mkfs.ext4 -L Storage /dev/sda1
My steps are definitely more involved, chalk it up to lack of knowledge about Linux commands, fear of typing the wrong thing and wiping the wrong partition, and the ease of using a GUI to prevent possible issuesSmile Thanks for posting steps on the Pi I'll give them a shot next time I need to work with partitions!
(2013-01-23, 12:06)MilhouseVH Wrote: 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.

so does no one know how to workaround that issue? it's not related to the pi connected to the amp... that issue also exists when i connect mit rpi directly to my tv..... very strange... and somewhat annoying Sad it's also not build-related... cause i already tried others... so what could it be?

(2013-01-23, 16:23)FattyMcDirty Wrote: so does no one know how to workaround that issue? it's not related to the pi connected to the amp... that issue also exists when i connect mit rpi directly to my tv..... very strange... and somewhat annoying Sad it's also not build-related... cause i already tried others... so what could it be?

You can try adding:
hdmi_pixel_encoding=<n>

to config.txt. n can be:

HDMI_PIXEL_ENCODING_RGB_LIMITED = 0
HDMI_PIXEL_ENCODING_RGB_FULL = 1,
HDMI_PIXEL_ENCODING_YCbCr444_LIMITED = 2,
HDMI_PIXEL_ENCODING_YCbCr444_FULL = 3,

(shouldn't be needed if TV reports the correct pixel encoding modes supported in its edid)
(2013-01-23, 12:30)rbej Wrote: This fix is not in master of last nightly Raspbmc. My custom build have this fix. Try it.

Hey rbey, have now tested with your build.
Unfortunately it does not work, now something else is very wrong:
GUI and 3D signal works, so does frame rate.
But something is happening to the ration squeezing it to something like 5:1. And very laggy.
Tried with tags HSBS + 3DSBS with same result.

Is the fix in master in nightly 0123?
If so I can test if it´s only your build or if it+s in master as well.
Today this fix is add to master Xbmc. Next nightly version Raspbmc will be have this fix.



Just wondering if these messages are a problem:

Code:
16:34:18 T:2884695136 WARNING: COMXImage::Decode progressive images not supported by decoder
16:34:59 T:2969949280 WARNING: Previous line repeats 2 times.

I see these messages when scraping in new media (in this case, TV shows). Is it possible to add support for "progressive" images?
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, 18:21)miappa Wrote: Hey rbey, have now tested with your build.
Unfortunately it does not work, now something else is very wrong:
GUI and 3D signal works, so does frame rate.
But something is happening to the ration squeezing it to something like 5:1. And very laggy.
Tried with tags HSBS + 3DSBS with same result.

Does removing guisettings.xml fix it?
Does removing custom guires setting fix it?
(2013-01-23, 18:41)MilhouseVH Wrote: Just wondering if these messages are a problem:

Code:
16:34:18 T:2884695136 WARNING: COMXImage::Decode progressive images not supported by decoder
16:34:59 T:2969949280 WARNING: Previous line repeats 2 times.

I see these messages when scraping in new media (in this case, TV shows). Is it possible to add support for "progressive" images?

Progressive jpegs can't be decoded by GPU. They are supported, they just get decoded on ARM.
(2013-01-22, 23:08)tfft Wrote: Here are a couple of debug files which ended-up with a freeze/reboot each,
reboot1.log 503.15 KB http://a4mqui.dl4free.com/en/
reboot2.log 568.91 KB http://gs71m9.dl4free.com/en/

I then disabled CEC (to get rid of its debug messages) and here are more reboots,
reboot3.log 326.88 KB http://5d9gr2.1fichier.com/en/
reboot4.log 164.99 KB http://6ktwkq.1fichier.com/en/
reboot5.log 276.27 KB http://yc54z9.1fichier.com/en/ (zeroconf off)
Are these log files helpful ? Do they contain enough info to point at the freezing problem/issues ?

If not, _again_ what can I do to help !!

Some feedback please...
  • 1
  • 66
  • 67
  • 68(current)
  • 69
  • 70
  • 174

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