DietPi-Software | Kodi: Implement systemd service with optional auto-restart

[zedrdave]

Kodi is unfortunately far from 100% stable, especially with a few add-ons installed, and will crash semi-regularly.

If the Pi is set up to work as a TV box, it can be particularly difficult to restart the app from the command line.

Maybe we could consider having an option in the autologin script that checks for the exit code, and automatically restarts the process if it crashed. Even better, if there's a debounce that prevents crash loops (eg: exit if two crashes are less than X seconds apart).

[MichaIng]

Many thanks for your report, and happy Xmas/holidays.

A systemd service can be easily configured to restart automatically, on certain or all non-zero exit codes, and stop trying after a defined amount of failed restart attempts in a certain time. I aim to implement this. I'm no big fan of auto-restarts, as usually there is reason to investigate the reason for the crash, which can be something that requires urgent action and where a constantly restarting process can make things worse. But I see the reason in this particular case, where console access is difficult.

However, did you try to check Kodi or system logs to get an idea why it is crashing or which addon might be responsible? While auto-restart can be a workaround, it is definitely not satisfying solution IMO. Which SBC/device are you running it on?

[zedrdave]

Agreed on generally investigating the causes of crash (I do, and whenever possible, remove whatever plugin/files may be the cause). But my aim is to set up and leave a Pi running dietpi+kodi, to a non-technical user, to use as their TV box…

For such a use case (basically, "kiosk mode"), there should be as little friction as possible. When confronted with a command line prompt on their TV, post kodi-crash, their only option will be to unplug the Pi and reboot, which is far from ideal.

However, I fully agree there should be some sanity check in the restart (maybe slightly more sophisticated than standard systemd nofail option), eg only allowing 1 restart per minute (anything more, probably means there's a crashing bug in the init itself).

This instance is running on a RPi4.B… As for the Kodi bugs, they are about 80/20 caused by badly-written plugins or badly-written media metadata (unfortunately, XMBC's core code doesn't seem to be using exception catching where it should). Both are hard to control (a lot of Kodi features rely on installing plugins, and the faulty metadata tends to come from online DBs, parsed by Radarr or Sonarr)…

Not a big inconvenience at all: I just worry that it would lead to a few hard reboots when used in Kiosk mode.

Merry Christmas!

[MichaIng]

their only option will be to unplug the Pi and reboot, which is far from ideal.

Or plug a keyboard? However, yes I agree that it makes sense to at least have this as optional feature.

Could be beneficial to report crashes, when identified the related plugin or cause (bad meta data) to the plugin or Kodi developers, btw. It should usually not be difficult to handle such in a graceful way instead of a full Kodi crash. But not always easy to identify the actual cause, I guess.

[zedrdave]

Inputting is not in itself the problem (I've already configured it to pair with a bluetooth keyboard app on the desktop), but as a matter of user-friendliness, I think we can't expect kiosk-mode users to know what to do when confronted with a terminal prompt (even if it's just as easy as typing kodi-standalone + return).

I've done my best over the years to diagnose and even sometimes debug some of the bugs in Kodi core or plugins, but anything that's not core, is often not very strongly maintained (understandable).

It should usually not be difficult to handle such in a graceful way instead of a full Kodi crash

agreed. I'm surprised that the plugin system doesn't use some stronger sandboxing and exception-handling…

[zedrdave]

Sort of a late afterthought (occurred to me while trying to debug one of the 100s odd entries in my kodi logs): the major problem with running Kodi on Raspbian, is that it is running a version that is literally 2 years behind current dev. As a result, when trying to report bugs or find a fix, one often ends up at the conclusion that it has been addressed in the more recent versions…

I know this is a Raspbian problem more than a Dietpi problem (and far from trivial), but is there any thought being given to trying to package a more recent version of Kodi for Dietpi, the way Libreelec etc do?

[MichaIng]

On Debian (Buster) it's worse btw, v17.6 vs. v18.7 on Raspberry Pi repository, Debian Bullseye ships current Kodi v19, being released this summer. NB: Raspbian has nothing to do with it, as it's only an armv6hf clone of Debian, required to run on RPi 1 and Zero models, with no source code variations. The special Raspberry Pi packages and builds come from archive.raspberrypi.org, which is not related to "Raspbian". Commonly mixed up, but important when it's about who to address issues to. Sadly I cannot currently find the source code repository of the RPi Kodi builds 🤔. Debian generally backports security patches and critical bugs into their stable releases as well, even that the version string stays the same. So on Debian you can send bug reports via mail to their bug tracker: https://www.debian.org/Bugs/Reporting Or check and push those which have been reported already: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=kodi

Providing own Kodi builds is out of our possibilities for now, especially since for RPi it requires specific own builds to be hardware-supported. LibreELEC has a whole team to build a whole OS only around Kodi, so it cannot be compared with DietPi where we 2-3 code contributors deal with >150 software titles for a longer list of supported boards 😉. So bear with us that we can provide own builds/packages only for a small number of simple software titles that do not depend on very SBC-specific hardware features. But if someone wants to help with such builds + maintaining them, even if only for a single SBC model, I'd be happy to implement them 🙂.

[zedrdave]

Thanks for the clarification on repositories.

Yes, I would never expect DietPi to tackle a full port of whatever's missing for Kodi to run on RPi. But it seemed there might be ways to take advantage of the work done by LibreELEC, since they obviously have to be able to compile it on RPi (among other platforms supported). From what I could see when I last looked, it seems like v19 had less hardware compatibility issues and it should be (theoretically) possible to even compile nightlies on dietpi (after installing a few billion packages)…

Anyway, let's hope the current/upcoming version is backported to the raspberry.org repo soon (I plan to look more into it, but unfortunately far from a RPi expert, so not the best candidate for that kind of packaging job).

Thanks for your hard work as always!

[MichaIng]

Problematic with builds or even sources of LibreELEC is the most likely specific library versions they require, at least the builds, which might not match what the stable Debian version ships. Looking through the sources, it's at least not trivial to extract the parts/patches for the Kodi build only: https://github.com/LibreELEC/LibreELEC.tv

[jose1711]

I am currently using Raspberry with OSMC as HTPC and can confirm Kodi crashes are quite frequent. Besides it's quite handy to have an option to reboot a system using a TV remote instead of reaching out for a keyboard. They have created a systemd service called mediacenter.service which calls a custom bash script that has all the logic implemented. Maybe it can serve as a reference.

[MichaIng]

See the other issue with a service example: https://github.com/MichaIng/DietPi/issues/4204 However, while it generally makes sense, when Kodi crashes frequently, rather than working around that with an auto-restart service, I'd focus on debugging and fixing the underlying issue.

[zedrdave]

@MichaIng as discussed above: it is very difficult to fix underlying Kodi issues for Raspbian/DietPi, considering the huge lag that exists between the current release, and the release available for Raspbian.

[MichaIng]

But is it really a bug in Kodi that leads to systematic crashes? In this case, a Debian of RPi distro issue/bug tracker report should have good changes to succeed, as then a large number of users should be affected. Otherwise I guess it's something around configuration and hardware capabilities, which can be debugged.

Also Debian and the Raspberry Pi repository ship different Kodi versions which different maintenance and stability. I cannot believe that both packages are broken a way that it regularly crashes, for that those are used much too often by a large number of users that would have reported it for a long time.