Forum

Full Version: [1.0RC3] XBMC keeps restarting
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5
(1st Jan, 2015 07:38 AM)CurlyMo Wrote: [ -> ]Simple:
1. XBian checks if XBMC fails or crashes and auto-restarts it.
2. If point 1. fails you get a restart loop.

Little more technical:
It REALLY difficult to check if XBMC actually started properly. XBMC didn't implement this logic, so we hacked it in ourselves. That was what has changed in the latest versions. All packages involved need to be the right version to work or else you get conflicts between "XBMC started?" checks. If they are out-of-sync, it fails and you get the behavior as you described as the reboot loop.

I'm not sure of the exact method openelec uses, pid checking or something but it works flawlessly.
It works flawlessly 99.9% of the time. The same reason we hadn't have complains for about a year. But still, it wasn't working 100%. I already said (and mk01 explained to me): XBMC just didn't include anyway of reporting if it's actually started fully. So either OpenElec included the same hack as we did, or they can't be sure as well.
I have never had an issue in Xbian so I didn't know it even had this mechanism Wink

I have had an issue in OE, that's why I know it works.

I have used the following on an X86 box to keep a process going, never had an issue that I can remember with it.

https://github.com/ghewgill/relight/blob/master/relight.py

Not that the implementation we are using now isn't fine, I haven't looked at it.
I've been using the old beta version for awhile now, but unfortunately my SD card got corrupted so I had to re-install xbian. Looks like that only RC3 is now available so I installed that.

My PI now reboots a few times until it calms down (can take unto 20 mins to be stable), is there a release coming out that will fix this? I'm not too linux savvy (old DOS dude).

Great OS though!
(1st Jan, 2015 03:15 AM)CurlyMo Wrote: [ -> ]The rpi-wheezy will be added if you follow all steps described in the FAQ.

I confirm this is not the case. My box did not have the file xbian.list. I added it just like the FAQ said. Including the reinstall. It re-wrote the xbian-list file, but the only non-commented out line, the stable one, still did not have the rpi-wheezy at the end. The commented out ones did.

So you need to add it manually, at least in some cases like mine, and perhaps the earlier person.

Now after I also added the rpi-wheezy and updated, the reboot issue is gone. Thanks!
(1st Jan, 2015 07:33 AM)palswim Wrote: [ -> ]
(31st Dec, 2014 08:59 PM)mk01 Wrote: [ -> ]Also because never before this happened at MASS scale - we neither users ever considered the looping itself for a BUG. the looping is alone a FEATURE - to auto restart XBMC in case of crash. but if XBMC doesn't start AT ALL (to HOME SCREEN) as part of BOOT and is killed on timeout - it is not logical to try loop it again and again. only today I named as BUG and fixed in xbian-package-xbmc-scripts v1.1.5.
(i have the feeling @palswim challenged that looping few msgs back as well -and clearly - reload AFTER xbmc running & crashing later is the feature we want to havel. useless restarting of XBMC which never make it to display on TV is an attack on user. Wink

I'm not sure I understand what you mean here. Are you saying that you added the XBMC auto-restart as a feature, but I provided an argument as to why a user may not desire that behavior?

1) first of all, this bug in discussion is not related to new function. the way XBMC start / stop / autorestart is handled is there (with no actual workflow / script) since B1. that means almost 2Y. but there was need to some changes on XBMC scripting side due to KODI preparation and with that we introduced this problem.

2) regardless to 1) to answer your question - because this part was NEVER making troubles before, we(and also users) never realised, that the "autorestart" implementation HAS one logical processing issue. and that is that it is trying to start XBMC again and again in never-ending loop not considering XBMC's ability to RUN(to START) at all - as of course it is making no sense to try to start XBMC if it is damaged, missing or missing system libs and others fatal conditions.

but now that missing "exit-loop" condition was added.
(1st Jan, 2015 09:31 AM)CurlyMo Wrote: [ -> ]If that's indeed the case, then you found a bug that needs to be solved Smile For the quickest solution, report it to our github issues next time.

lsb-release should be added as pre-dependency to xbian-package-repo. it is auto installed on images but (can) be missing on old installs . then it fails the wheezy/jessie recognition. Undecided

updated the FAQ too to include lsb-release install.
(13th Jan, 2015 02:44 PM)mk01 Wrote: [ -> ]lsb-release should be added as pre-dependency to xbian-package-repo. it is auto installed on images but (can) be missing on old installs . then it fails the wheezy/jessie recognition. Undecided

updated the FAQ too to include lsb-release install.

In my case, the wheezy/jessie recognition succeeded (it properly identified my installation of jessie), but then the rpi-jessie repository didn't exist. But, this discussion doesn't quite relate to the XBMC restarts. It sounds like a discussion for a different thread, or the GitHub issues.
I updated the xbian-package-repo to not just rely on lsb_release. If it isn't present it will check the /etc/debian_version file, and if that's not there stop continuing instead of wrecking the repo's.
Is there an ETA on when a fix for this is going to be released?
Like at least a month ago?!?

Again, follow the frontpage FAQ and upgrade all packages.
My Xbian keeps restarting, randomly, right after it loads the EPG from Tvheadend (using pvr.tvh).
It takes 5-10 reboots before it finally calms down.
How can I debug this problem? Can't see the logs while it does this.

I'm connecting to TVH via internet, can it be something like "if epg does not load in x seconds, then assume something is wrong and reboot"?
XBMC is a steamy pile of horse pucky.
Fresh install 10.1.16 build on Pi v3 FAIL.
These linux apps / systems have a LONG way to go before being capable OF EVEN BOOTING!!!
FAIL: Keyboard doesn't work.
FAIL: Mouse doesn't work.
FAIL: Locked OSMC welcome screen.
I'm out.
(4th Nov, 2016 03:57 AM)mem89756 Wrote: [ -> ]XBMC is a steamy pile of horse pucky.
Fresh install 10.1.16 build on Pi v3 FAIL.
These linux apps / systems have a LONG way to go before being capable OF EVEN BOOTING!!!
FAIL: Keyboard doesn't work.
FAIL: Mouse doesn't work.
FAIL: Locked OSMC welcome screen.
I'm out.

very informative
(4th Nov, 2016 03:57 AM)mem89756 Wrote: [ -> ]FAIL: Locked OSMC welcome screen.
I'm out.

Seems he is a bit confused. OSMC is not XBian
Pages: 1 2 3 4 5
Reference URL's