• 1
  • 54
  • 55
  • 56(current)
  • 57
  • 58
  • 277
OpenELEC Testbuilds for RaspberryPi Part 2
It's not just the EPG screen being open that causes TV audio to break up and stutter, it's also on Home and other pages, so it seems there's an issue with having the GUI displayed whilst TV is playing. It hasn't always been a problem though. I note that the debug OSD shows XBMC using around 70% CPU at these times but overall the CPU is 97-100%. With TV visible, it's normally around 35-40% but on some programmes/channels it's been much higher, around 75% for some reason. When I get this audio breakup and then close the GUI to go back to TV, it tends to freeze and breakup the picture for maybe 10s before it sorts itself out and starts playing normally again.

One cool fix though, changing channel via the EPG now closes the EPG after the new channel has started whereas the EPG used to stay open and I had to press back twice to show TV again.
I can also confirm that the lirc ir receiver is not working on the latest build.
It's a bug in OE 3.2. I already opened a thread on the official forum but
I didnt receive a answer. When I downgraded to 3.1.7 it works. Any ideas?

Thanks in advance
I am having an issue with the current Gotham build.

If I reboot, it frequently freezes on the XBMC screen. It takes many reboots (over SSH) before booting successfully. I have not identified a factor that impacts which boot will be successful. It seems completely random.

Once it boots, it seems to run well.

I have not seen this behaviour with any previous build I had installed.

Anyone else see this? Workarounds?
(2013-09-18, 04:38)allan87 Wrote: I am having an issue with the current Gotham build.



If I reboot, it frequently freezes on the XBMC screen. It takes many reboots (over SSH) before booting successfully. I have not identified a factor that impacts which boot will be successful. It seems completely random.



Once it boots, it seems to run well.



I have not seen this behaviour with any previous build I had installed.



Anyone else see this? Workarounds?



Just to test switch back to confluence if your using a different skin and delete guisettings from the userdata folder. Couple of the skins i use dint play nice with Gotham yet but i just swap the skin out each time i reboot to save the settings.
(2013-09-17, 20:19)MilhouseVH Wrote:
(2013-09-17, 19:35)allan87 Wrote:
(2013-09-17, 19:25)trogggy Wrote: Thanks. I just wondered why it was there.
I don't think that is quite correct. These are, I believe, recommended for these builds. To install, just copy into the userdata folder.

OpenELEC already includes sensible defaults in /usr/share/xbmc/system/advancedsettings.xml.

There is no need to specify additional settings unless you really know what you are doing and disagree with the system defaults. Blindly duplicating these default system settings is also a dumb idea, which is basically what these "recommended" settings amount to.
Yep - I asked the question before I installed the build. The advanced settings in system (seen in the log) are identical to those in the links.
Another possibly dim question: can I do a normal manual update with these builds (as another rbej build becomes available), or is it recommended to do a fresh install with each new build?
Moving Frodo > Frodo or Gotham > Gotham, not switching between the 2.

Thanks.
(2013-09-17, 23:06)blazinramirez Wrote: I can also confirm that the lirc ir receiver is not working on the latest build.
It's a bug in OE 3.2. I already opened a thread on the official forum but
I didnt receive a answer. When I downgraded to 3.1.7 it works. Any ideas?

Thanks in advance

This thread may be of help -

http://openelec.tv/forum/124-raspberry-p...g-on-3-2-0

Seems the update doesn't work corectly in some cases, I presume due to an issue with the updater script or similar. You may have to manually update the Kernel and possibly System files on your install.

I can't confirm this yet, but will try later on and report back...
(2013-09-18, 10:23)soupboy Wrote:
(2013-09-18, 04:38)allan87 Wrote: I am having an issue with the current Gotham build.



If I reboot, it frequently freezes on the XBMC screen. It takes many reboots (over SSH) before booting successfully. I have not identified a factor that impacts which boot will be successful. It seems completely random.



Once it boots, it seems to run well.



I have not seen this behaviour with any previous build I had installed.



Anyone else see this? Workarounds?



Just to test switch back to confluence if your using a different skin and delete guisettings from the userdata folder. Couple of the skins i use dint play nice with Gotham yet but i just swap the skin out each time i reboot to save the settings.
I use stock confluence, but I will try renaming guisettings next time I have the issue, to see if that is the issue. Major inconvenience if those settings have to be recreated, unfortunately.
(2013-09-18, 10:38)trogggy Wrote: Another possibly dim question: can I do a normal manual update with these builds (as another rbej build becomes available), or is it recommended to do a fresh install with each new build?
Moving Frodo > Frodo or Gotham > Gotham, not switching between the 2.

Absolutely, just drop the SYSTEM and KERNEL (plus MD5) files in your Update folder and reboot. No need for a fresh install.
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-09-18, 18:58)MilhouseVH Wrote:
(2013-09-18, 10:38)trogggy Wrote: Another possibly dim question: can I do a normal manual update with these builds (as another rbej build becomes available), or is it recommended to do a fresh install with each new build?
Moving Frodo > Frodo or Gotham > Gotham, not switching between the 2.

Absolutely, just drop the SYSTEM and KERNEL (plus MD5) files in your Update folder and reboot. No need for a fresh install.
Unless you're running XBMC from USB drive or NFS, as this update has stopped working, it always corrupts the SD card. I need to copy the files manually to boot SD card partition.
(2013-09-18, 11:56)RichG Wrote: Seems the update doesn't work corectly in some cases, I presume due to an issue with the updater script or similar. You may have to manually update the Kernel and possibly System files on your install.

I can't confirm this yet, but will try later on and report back...

If you have configured the boot parameter in config.txt to use something other than /dev/mmcblk0p1 - for example, when "booting" from USB, NFS, SMB etc. - then the standard update process (manual or automatic) will NOT work 100%. At best the Pi will not receive the new kernel and experience glitches such as non-functional lirc, at worst the Pi may not boot at all.

There are two problems with OpenELEC:
  1. The initramfs init script blindly copies new kernel firmware to /flash even when /flash isn't the boot partition - an issue for this was opened long ago and a subsequent patch was rejected and rotted almost as long ago
  2. The update.sh script doesn't preserve the timestamps of the new firmware files (they're always 1 Jan 1980) so the user never knows when they have old firmware. This is trivial to fix, however the original patch was rejected. I've resubmitted patch 2614, we'll see how that goes. It's a small step, but progress.
Anyway the upshot is if you have boot= set to anything but mmcblk0p1, you will need to manually extract SYSTEM and KERNEL and also the firmware from the 3rdparty folder, then update your SD card/USB by hand using a PC.


(2013-09-18, 19:19)pplucky Wrote: Unless you're running XBMC from USB drive or NFS, as this update has stopped working, it always corrupts the SD card. I need to copy the files manually to boot SD card partition.

Yes, this "wrinkle" in the update process is very unfortunate, particularly as it was flagged up as an issue so long ago and will now likely catch out a lot more users than it would have done 9 months ago. Though actual SD card corruption could be something else, a check for that was also part of the rejected (and now rotten) patch - the problem with the update process is that it simply writes the Pi's most important firmware file to the wrong location.
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-09-18, 19:27)MilhouseVH Wrote: Anyway the upshot is if you have boot= set to anything but mmcblk0p1, you will need to manually extract SYSTEM and KERNEL and also the firmware from the 3rdparty folder, then update your SD card/USB by hand using a PC.

Thank you - that is exactly my situation. I've now managed to rectify the problem doing as you suggest.

Really hope they have another look at this issue. as you say it will surely catch a lot of people out.
At least the timestamp patch 2614 has now been committed on Gotham and Frodo branches, in future you should be able to tell by looking at /flash if you have an outdated kernel.img file.
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-09-15, 16:30)rbej Wrote: Updated Frodo Branch

- [rbp/omxplayer] Only apply boost centre to multichannel audio

- [rbp/omxplayer] Avoid losing volume changes when amplification is disabled

- Speedup for opening music song library

- Faster sorting of CFileItemLists

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

http://lysin.me/rbej

I download this one and the name is OpenELEC_Gotham-RPi.arm-devel-20130915161035-r15725

is frodo or Gotham??
(2013-09-19, 00:01)panico Wrote: I download this one and the name is OpenELEC_Gotham-RPi.arm-devel-20130915161035-r15725

is frodo or Gotham??

@rbej: the 15 Sep Frodo .tar.bz2 definitely contains a Gotham build folder... the contents of SYSTEM:/etc/openelec_release is:
Code:
OpenELEC_Gotham (unofficial) - Version: devel-20130915161035-r15725
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.
This is Frodo not Gotham. If you dont believe check splash screen. Im use Gotham options (PROJECT=RPi ARCH=arm XBMC=master make release) when compiling Frodo and Gotham builds. So always is written Gotham, even as compile Frodo.



  • 1
  • 54
  • 55
  • 56(current)
  • 57
  • 58
  • 277

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