• 1
  • 111
  • 112
  • 113(current)
  • 114
  • 115
  • 174
OpenELEC Testbuilds for RaspberryPi
The latest up-to-date git build of stock OpenELEC has xbmc.bin terminating with a segmentation fault after selecting "Reboot" or "Power off" from the shutdown menu - this is without my patch being applied. Anyone else able to confirm?

The shutdown takes a long time as well. Presumably something has been committed on 10 March that has caused this as there were now problems up to the end of 9 March.

You can see this for yourself by selecting Reboot, and instead of the Pi rebooting the XBMC GUI will restart thanks to the watchdog.

To observe the seg fault, touch the lock file to prevent XBMC being automatically restarted, kill XBMC, start XBMC manually and then select Power off or Reboot from the Shutdown menu (may require a keyboard):
Code:
rpi512:~ # touch /var/lock/xbmc.disabled
rpi512:~ # killall xbmc.bin
rpi512:~ # DISPLAY=:0.0 /usr/lib/xbmc/xbmc.bin $XBMC_ARGS
Segmentation fault

Because XBMC doesn't exit cleanly it is always restarted by the watchdog.

Edit: I've just bisected all the 10 March commits and it's PR 2387 that introduces the seg fault.
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-02-27, 09:01)rbej Wrote: Rbej Frodo Brench

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

- Xbmc 12.0.4 Frodo (many new fixes) (05.03.2013)
- Rpi kernel 3.6.y (08.03.2013)
- Rpi firmware (08.03.2013)
- Pvr Addon (06.03.2013) with PVR TvHeadend 1.6.19 and MythTv 1.6.9 (06.03.2013)
- Xvdr Addon (25.02.2013)
- Gpu memory set to 100mb on default for Rpi 256mb (fix kernal killing Xbmc task on Rpi 256mb board) and Gpu memory set to 256mb on default for Rpi 512mb.

...........................

Thanks for your hard work. I've got a bug to report, however. When playing video streams via AirPlay to the RPi, XBMC doesn't update the resolution (and bitrate of videoclip). It gets the AirPlay via a .m3u8-playlist, and I reckon the quality should be determined by the Internet-speed, and then switch resolution to a more suitable choice, but I haven't gotten it to work. It starts to play at the lowest bitrate and resolution, and stays there. Very good build despite this little bug. I hope it's fixable somehow!

Cheers!
(2013-03-11, 07:04)MilhouseVH Wrote: Edit: I've just bisected all the 10 March commits and it's PR 2387 that introduces the seg fault.

Are you able to use gdb to get a backtrace of the crash?
(2013-03-11, 13:17)popcornmix Wrote: Are you able to use gdb to get a backtrace of the crash?

Yep, I had a chat on irc and pasted a link there, here it is.

Looks like it's CEC-related, opdenkamp is aware.

Not sure if the illegal instructions are anything to be concerned about, this old discussion is pretty much all I could find.
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-03-11, 03:32)MilhouseVH Wrote: I've also just updated this PR (though I think I may have messed it up slightly by trying to squash my commits!) to include ifdef's for the Raspberry Pi, so that original suspend/hibernate behaviour is restored for non-Pi systems. The patch is here, and maybe this patch could be accepted into xbmc master at some point (unless there is a better solution).

Your PR is messed up. You should rebase your single change onto top of xbmc master tree.
If you edit rpi-power-defaults branch and force push, then PR will magically update.

Something like:
Code:
git reset --hard 03e18f4313e331c6fbc484049025f8ba8194a844
apply patch / git add / git commit
git push --force
(the hash should be top of current git).

However you should expect reluctance for xbmc to accept a PR with ifdef's when it may be possible to solve without ifdefs.
(2013-03-11, 13:25)popcornmix Wrote: Your PR is messed up. You should rebase your single change onto top of xbmc master tree.
If you edit rpi-power-defaults branch and force push, then PR will magically update.

Something like:
Code:
git reset --hard 03e18f4313e331c6fbc484049025f8ba8194a844
apply patch / git add / git commit
git push --force
(the hash should be top of current git).

Ha, yeah, really a noob where git is concerned. I followed a guide to squash the commit and obviously I shouldn't have pulled in all the other commits.

Anyway, this is what I have:
Code:
neil@nm-linux:~/myOpenELEC/xbmc$ git status
# On branch rpi-power-defaults
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       lib/taglib/.gitignore
nothing added to commit but untracked files present (use "git add" to track)

but when running git reset:

Code:
$ git reset --hard Commit:03e18f4
fatal: Invalid object name 'Commit'.
$ git reset --hard 03e18f4313e331c6fbc484049025f8ba8194a844
fatal: Could not parse object '03e18f4313e331c6fbc484049025f8ba8194a844'.
(edit: hmmm... the forum seems to be mangling the hashes)

Any ideas?

(2013-03-11, 13:25)popcornmix Wrote: However you should expect reluctance for xbmc to accept a PR with ifdef's when it may be possible to solve without ifdefs.

Yeah, that did occur to me, though not entirely sure how to solve it without ifdefs (my original patch was even nastier).
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 did "git reset --hard HEAD" and that did the trick, PR updated as you said it would, many thanks! Smile
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-03-01, 17:31)popcornmix Wrote:
(2013-03-01, 00:43)LehighBri Wrote: Quick update. I tried that build with a clean install and am still getting out of sync video. I think the previous example didn't make it as apparent... see below for a new sample file that the video and sound get out of sync every time around the 14-15 seconds mark of playback starting. Can folks try this new sample I just uploaded? I can reproduce it on multiple rpi's with the update above.

New sample: https://www.dropbox.com/sh/f03xceuz30a5ky2/QaGIB8Gue2

I see the out of sync issue.
The video file is quite badly corrupted (lots of video and audio artifacts due to packet loss), which is obviously provoking the out of sync audio.
VLC displays the corruption, but maintains audio sync. It will take more careful study to work out exactly what happens to the timestamps (and so the sync) after the lost packets.

popcornmix - just wanted to check in on my issue above. I think it got buried many pages ago. Any update/progress? Is there a better place for me to log this so that it doesn't get lost or do you have what you need?
(2013-03-10, 01:16)sraue Wrote: the problem here is xbmc calls "upower" to get if suspend/hibernate is supported. because upower depends on consolekit, which depends (still) on x11 librarys we dont include upower (also because supend/hibernate is not supported). this also means xbmc shows this options which are set as default because xbmc dont get the requested info

On my raspbian image, I did:
Code:
sudo apt-get install hal
lshal -l |grep power_management.can_hibernate
  power_management.can_hibernate = false  (bool)
lshal -l |grep power_management.can_suspend
  power_management.can_suspend = false  (bool)

which looks like the information wanted from:
Code:
m_CanSuspend   = QueryCapability("power_management.can_suspend");
  m_CanHibernate = QueryCapability("power_management.can_hibernate");

So I'm not sure if that is the code path we want to enable.

(2013-03-11, 13:58)LehighBri Wrote: popcornmix - just wanted to check in on my issue above. I think it got buried many pages ago. Any update/progress? Is there a better place for me to log this so that it doesn't get lost or do you have what you need?

I have all the information I need - just not the day or two needed to spend investigating the problem. It will happen when some of the issues I'm currently working on are resolved.
It may be worth openening an xbmc trac ticket with a link to the relevent information, so it is not forgotten.
(2013-03-11, 16:24)popcornmix Wrote:
(2013-03-11, 13:58)LehighBri Wrote: popcornmix - just wanted to check in on my issue above. I think it got buried many pages ago. Any update/progress? Is there a better place for me to log this so that it doesn't get lost or do you have what you need?

I have all the information I need - just not the day or two needed to spend investigating the problem. It will happen when some of the issues I'm currently working on are resolved.
It may be worth openening an xbmc trac ticket with a link to the relevent information, so it is not forgotten.

Sure thing... I'm sure you're busy and I have a workaround to record to .mpg instead of .ts (which doesn't have the same packet loss and thus plays back ok). Still would be nice in the future to have the .ts handled like VLC, etc. Much appreciated. And so we don't lose this, I created the trac ticket below and assigned to you and gimli (hopefully that is correct).

http://trac.xbmc.org/ticket/14179
Update Frodo Branch

- Xbmc Frodo 12.0.6 (many new fixes)

http://forum.xbmc.org/showthread.php?tid...pid1350100



Is there any way I can keep Storage on the SD but point the .xbmc directory to my NFS server? That would avoid the issues I'm having with the ssh key permissions being incorrect and preventing ssh/winscp access but keep most of the writing on the NFS share/off the SD card and thus minimise the chances of corruption when overclocking.
(2013-03-11, 23:15)rbej Wrote: Update Frodo Branch

- Xbmc Frodo 12.0.6 (many new fixes)

http://forum.xbmc.org/showthread.php?tid...pid1350100

Thanks for the updates of your compilation.

It is possible, apart from *.tar.bz2, to compile the *.img?.

So could we Windows users, do a clean installation with its compilation.
(2013-03-12, 13:45)wOOx Wrote: Thanks for the updates of your compilation.

It is possible, apart from *.tar.bz2, to compile the *.img?.

So could we Windows users, do a clean installation with its compilation.

Just use a stock OpenELEC image and then update using the contents of the Rbej tar.bz2.
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-03-12, 13:49)MilhouseVH Wrote:
(2013-03-12, 13:45)wOOx Wrote: Thanks for the updates of your compilation.

It is possible, apart from *.tar.bz2, to compile the *.img?.

So could we Windows users, do a clean installation with its compilation.

Just use a stock OpenELEC image and then update using the contents of the Rbej tar.bz2.

So I've been doing so far.

But many users, making their first installation from windows.

Thank you.
  • 1
  • 111
  • 112
  • 113(current)
  • 114
  • 115
  • 174

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