Spontaneous reboots

  • Since I upgraded to LE 8.0.1 on my Raspberry Pi 3 (with all add-ons up-to-date as well) I'm enjoying the improvements in Kodi 17 (over Kodi 15 which I had on my previous OE install) but unfortunately I'm also having serious stability problems. Mostly during user operations (i.e. navigating menu's and selecting options) but occasionally also during playback, Kodi will just freeze for a few seconds, followed by either one or by multiple reboots.


    Question 1: Since Kodi is an app running on top of Linux, I can't see how a Kodi crash could corrupt the Linux OS to the point where it crashes into a reboot (that shouldn't be possible). So how do problems with Kodi cause these reboots? Is there a watchdog process somewhere that reboots the system in response to an unrecoverable error state in Kodi?


    I suspect that not LE/Kodi itself but one of the add-ons is the problem. The Shadertoy visualization doesn't seem entirely stable (most reboots occur while "playing" with the different visualizations during music playback) and the visualizations are off-center and not full-screen, and also sometimes fail to come on-screen. Another possible culprit could be the Xonfluence skin, seeing as whenever I edit a menu options and there's a reboot shortly after that, I loose the latest menu edits and the menu's revert to what they were before the last (but not the previous) change.


    Question 2: Is there anything in terms of debug logging (either module-specific or not) that may hint at what causes these reboots?


    One last funny thing is that after a crash more often than not my display resolution settings have reverted from full screen HD to DESKTOP, with a refresh rate of either 60fps or 59.94fps. When that happens I need to restore the resolution to 1920x1080p and do another screen calibration to adjust the overscan to its correct settings.


    Question 3: What could cause the display resolution to revert to the factory default without affecting other settings?


    Any pointers in the right directions would be appreciated. Thanks!!


    // FvW

  • check /storage/.kodi/temp/kodi.log or ssh in an enter:


    Code
    1. pastebinit /storage/.kodi/temp/kodi.log


    and

    Code
    1. pastebinit /storage/.kodi/temp/kodi.old.log


    after the reboot and get us the links you will receive.


  • Thank you so much for responding-- it's greatly appreciated.


    I've done the above for both kodi.log and kodi.old.log, as well as for the two recent crash logs that I find in the same subdirectory. The pastebin URLs are:


    For kodi.log: cbWP
    For kodi.old.log: Ifbh
    For kodi_crash.log (symlink to kodi_crashlog_20170519182358.log): YXAJ
    For kodi_crashlog_20170519182231.log: CgdT


    These are the crash logs that (according to their time/date stamps) should cover the crashes/reboots that occurred just before I pastebinned the lot.


    Platform / How installed:
    Raspberry Pi 3 with 2 Toshiba USB harddisks via self-powered, non-backpowering USB hub, and a VRC-1100 MCE IR Remote Control receiver. No other peripherals present. Clean install of LE 8.0.1 from image LibreELEC-RPi2.arm-8.0.1.img on 8GB micro SD card. Xonfluence skin installed from the helly repo; everything else from standard repo's. Instability issues occur with two installations on two different SD cards, which should rule out the SD card as a possible source of problems. None of the above ever occurs with my old OE 6.0.3 install, which should rule out hardware issues with the RPi3.


    What I did to produce the crash that generated the above log files:
    play music, switch visualizations using the Visualizations Setting button in the Music Playback OSD. Playback halts; screen freezes, reboot after a few seconds. Wait for system to come back up, restart playback of same track; crash and reboot follows after about a second of music playback. Power cycle and switch visualizations back to 'Shadertoy' using the settings menu before resuming playback (finding that menu's have reverted to yesterday's configuration; screen resolution has reverted to DESKTOP, and "Enable CD case and disk art" and "Diffuse music visualization with artist fanart" have reverted to factory defaults. The above crashes are reproducible by repeating the above sequence of operations.


    Once again many thanks!


    // FvW


  • Decrease or eliminate your overclock to see if the trouble goes away.


    Hi, Doug,


    I didn't overclock. The RPi 3 is straight out of the box. No tweaking, modding or souping upping done in any way. :)


    // FvW


  • Power supply issues?


    I'm using an "officially approved" 2.5 amp power supply from which only the RPi itself is powered. The USB disks hang off a self-powered USB hub that does not backpower into the RPi.


    If power supply issues were the cause, this should also have been apparent with the previous OE install under the same CPU load, and it should be worse while playing, say, H.265 video's which currently generate the highest CPU load. But it isn't. Instead the problem occurs while switching visualizations during audio playback and the like, at which time Kodi freezes for a second or two, then reboots.


    In other words, this appears to be tied to software operations rather than to high CPU load operations (which should draw the highest current). Doesn't sound like a power supply issue to me... But the thought is appreciated. :)


    // FvW

  • If power supply issues were the cause, this should also have been apparent with the previous OE install under the same CPU load, and it should be worse while playing, say, H.265 video's which currently generate the highest CPU load. But it isn't. Instead the problem occurs while switching visualizations during audio playback and the like, at which time Kodi freezes for a second or two, then reboots.


    Not quite. Recent versions of Kodi/LE have changed how GPU/CPU handle audio/video compared to previous versions of Kodi/OE. You can't draw the conclusion. A more relevant comparison would be the same version of Kodi in LE vs. Kodi in OE. And this still wouldn't eliminate the power supply as a possible issue.


    I'd test a separate power supply. I'd also test a different USB cable as those can cause problems too.


    The kodi.log and kodi.old.log you provided weren't debug enabled logs. Enable debug logging, reboot, then reproduce. Then upload the logs.

  • Not quite. Recent versions of Kodi/LE have changed how GPU/CPU handle audio/video compared to previous versions of Kodi/OE. You can't draw the conclusion. A more relevant comparison would be the same version of Kodi in LE vs. Kodi in OE. And this still wouldn't eliminate the power supply as a possible issue.


    I'd test a separate power supply. I'd also test a different USB cable as those can cause problems too.


    The kodi.log and kodi.old.log you provided weren't debug enabled logs. Enable debug logging, reboot, then reproduce. Then upload the logs.


    I did enable debugging. But the crash reverted that setting to the default (i.e. no debugging).


    I hear what you say about the changes in GPU/CPU handling. However, the highest CPU load I get while playing H.265 encoded video, which works fine without a hiccup. I use a 2.5A power supply that came with the Pi and that only powers the Pi, and when I ssh in and generate maximum CPU load on all 4 cores (until the thermal warning appears on screen) there's no problem. However by simply playing audio and switching the visualization I can reproduce the crashes reliably.


    If there's a spontaneous crash while audio is playing (and the visualizations are doing their thing) I usually get two or three subsequent reboots, and as soon as I resume audio playing the system crashes again. Power cycling resolves that problem.


    So yes, I hear what you say, and I'll try to organize another power supply to see if that makes a difference, but this honestly doesn't feel like a power problem to me.


    Meanwhile I've disabled all visualizations to see if that makes a difference.


    Whatever the case may be, thanks for looking into it. I appreciate it! :D


    // FvW

  • Ya, you probably have some skin funkiness then...you say you are setting debug logging in setting and rebooting, but the kodi.log says logging is explicitly disabled. You can try enabling logging within the default skin, switch skins and then reboot. You should also try reproduce the error with the default skin.


    Is xonfluence even supported for 17.1? What about trying to reproduce the error in other skins.

  • OK. I'm going to do a clean install of LE only without any customization at all and see what that does, then install add-ons one by one until things go boom. That should help to narrow it down.


    Tnx!


    // FvW

  • This started happening to me also. It only happens when I hit the "back" button my remotes. Will switch back to16.1 for now.


    Thanks


  • For kodi_crash.log (symlink to kodi_crashlog_20170519182358.log): YXAJ
    For kodi_crashlog_20170519182231.log: CgdT

    Addon vizualization.wavforhue terminates Kodi:

    Code
    1. Thread 1 (Thread 0x74f84000 (LWP 1718)):
    2. #0 __GI_raise ([email protected]=6) at ../sysdeps/unix/sysv/linux/raise.c:58
    3. #1 0x7538d400 in __GI_abort () at abort.c:89
    4. #2 0x66de229c in WavforHue::SaveState(std::string) () from /storage/.kodi/addons/visualization.wavforhue/visualization.wavforhue.so.1.0.0
    5. #3 0x66dee14c in WavforHue_Thread::GetPriorState() () from /storage/.kodi/addons/visualization.wavforhue/visualization.wavforhue.so.1.0.0
    6. #4 0x66ddf418 in Start () from /storage/.kodi/addons/visualization.wavforhue/visualization.wavforhue.so.1.0.0
    7. #5 0x007081c4 in ADDON::CVisualisation::Create(int, int, int, int, void*) ()


    Deinstalling the plugin should solve the crashes.

  • Quote

    Deinstalling the plugin should solve the crashes.

    Thank you! That helps.


    Unfortunately this was only one of the many things that cause crashes. Also, what I don't get is, how can a plug-in from the repo be that crashy on my Kodi installation? If it were that bad surely it would be either pulled, fixed or marked broken. It isn't, so I assume that this isn't common behavior for a standard plug-in from the repo, which suggests other factors being in play as well.