DietPi v10.2.3, arm64, RPi 5 Model B (aarch64)
Fresh install from current stable image.
When trying to install dependencies in Kodi i cannot scroll down and reach them all anymore.
Which dependencies, where? During the Kodi installation you mean the dependencies fail to install?
I guess within Kodi UI, otherwise I would not know how to scroll down on a list ![]()
I just don’t know about a dependency list in the Kodi GUI. Maybe addons are meant?
So far i only tried to install a skin from default repo to see if and how JellyCon widgets work. Any of them didn’t let me scroll down.
To get jellycon going i had to manually dl & install dependencies.
Yes, in Kodi when you look at each addon, if you go look into settings of the addon you will see dependencies, clicking on it shows the use what other packages are used and puled it. Either connection to default repo is just not that great and one has to retry installing or to make it less painful one goes into dependencies and clicks and installs each one manually by just clicking or using arrows > selecting it > Enter
This additional files and up in ~/.kodi/addons/
We don’t maintain Kodi as application. It’s installed from global Debian repository.
Again, thanks for the awesome quick replies here.
Could you please clarify that one is basically able to now install anything into kodi without running into problems as i was under the impression and memory that there were mentions/warnings in the past that kodi on dietpi has been tailored specifically different to fit into the dietpi way.
Not that i like installing random addons if any, i just remember that they would be problematic with dietpi.
If you can browse the official Kodi add-on repository via the GUI, then obviously that is present and should work. I am saying it since: while on Debian, we install the official Debian Kodi package + separate kodi-repository-kodi package for the add-on repo. On RPi, a dedicated package from the archive.raspberrypi.com repo is installed. Since Trixie, differences between that package and Debian are small, it has a kodi-repository-kodi package now as well, while previously it was embedded in the kodi package itself.
Anyway, it is supposed to work in both cases, and I did in fact test both package in another context, and could install and run add-ons successfully. But I never saw or recognized add-on dependencies, hence don’t know how these are resolved. So those dependencies are add-ons as well, and one add-on pulls in other add-ons? Can you show a screenshot of this?
Regarding JellyCon in particular: You followed their instructions to add their dedicated add-on repository?
And while dependencies are automatically installed in other cases, for JellyCon this did not happen? Are those dependencies as well from the Jellyfin repo?
If you start Kodi from console, you might see some error logs on the console, otherwise in the executing user’s home directory, like ~/.kodi/temp/kodi.log IIRC. Maybe it reveals some issue, like Jellyfin repo connection issues, maybe rate limiting or so.
Nope, we just assure that, on RPi, KMS/DRM and video codec drivers are enabled, respective libraries installed, and create a desktop shortcut. It starts with defaults.
Yes i did.
I need to add that i also learned that cat cable testers are not to be trusted over the week end and learned the hard way that my ethernet was dropping and reconnecting and that maybe might have caused the scroll down problem since i am able to scroll down in addon’s dependency windows.
Checking with
cat /sys/class/net/eth0/carrier_changes
revealed those disconnects, anything > 1 means that one has a problem which is amazing since i was able to stream just fine even with these errors. Let’s hope this is fixed for now, time will tell.
Thank you for the replies and all the hard work.
Nice command, I did not know about this either.
Or the router has been restarted or so. But before/after values indicate whether a disconnect has happened in between
.
Yeah, recabled home after i upgraded to larger Switch and crimped a bunch of cables. While cable tester said ok initially, i ended up with a bad one.
From now on, i will have to make sure to run extensive tests, including some cable wiggling at the RJ45 connectors and do some extensive data moving before i decide the cable is usable.
Think it’s worth adding the carrier_changes value to the default ssh login banner as red alert? Would have saved me time diagnosing lol (:
Since it is not an indicator about unintentional connection losses, but include intentional cable unplug, router restarts, even just network interface restarts at the client, this value is not generally of concern. Also there is not really a way to know whether a certain large value is, or in which circumstances.
It is good to know about that API, but I see no reasonable way to somehow integrate/monitor it in DietPi, but more as additional way to debug individual network related issues, when knowing the circumstances, time frame etc. Btw, you see those disconnects in dmesg output, and probaly journalctl -u ifup@eth0 as well, right?