It's unlikely that installing a Python add-on affected a Linux kernel subsystem. More likely there is a change in the kernel used with an older and current LE version that affects power modes for the IR receiver .. or something in that direction. First step is sharing the dmesg log from the box after the receiver stops working. It would also be useful to know what IR hardware is being used.
Posts by chewitt
-
-
I've interpretted the original request as thin-client to server with GPU work being done on the big server; similar to how game streaming works between a small thin-client device and a 'big' computer with the fancy GPU. There is no equivalent to this for video playback.
If you just want client/server behaviour with some NUC-like thin clients this is simple. Setup a MariaDB database on the server, and share files over SMB or NFS to clients that share a common library maintained in the central SQL database. Doing this in the same house does not need wireguard, file sharing over SFTP/FTP/WebDAV, or any of the pirate shitware that @elonesa described (which has been edited from his post).
-
It's not a supported (or supportable) configuration with LE, and no plans to change that.
-
i have created .no compat folder in .update folder, but still no luck.
Run "touch /storage/.update/.nocompat" .. it's checking for a .nocompat file, not a folder. NB: You might want to uninstall aarch64 binary add-ons before crossgrading like this as they may not handle the change of arch to "arm" gracefully.
-
You should be able to build Armbian with LE's kernel version and current patch-set. HDMI works although with random box devices there are more unknowns. There's no harm in trying.
-
Please provide a full debug log.How to post a log (wiki)1. Enable debugging in Settings>System Settings>Logging2. Restart Kodi3. Replicate the problem4. Generate a log URL (do not post/upload logs to the forum)
use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link -
It's completely logical. The .m3u file is managed by the add-on, so if you edit it externally the add-on is not aware of changes. Deactivate, edit, and then reactivate, avoids that. If it worked differently in older versions that was likely luck more than design.
-
Could you look into that as well?
Not my area of expertise. Someone else will need to do that.
-
what i need to do for adaptation it for LibreELEC ? ... tv box: ugoos AM7
Code support for the SC2 platform. Send it upstream to the kernel. Bump LE kernel to use the updated kernel. So simple
-
Code
touch /storage/.please_resize_me^ will trigger the resize of /storage to 100% size. I forget whether we resize the current partition or remove and recreate it.
-
But hopefully soon, really soon...
don't hold your breath .. I'm not aware of anyone actively working on it
-
We keep test images for about 7-days, not longer.
-
I'll confess it's about 4 years since I did a password change, but that sounds rather odd/wrong.
-
Possible "command-line" workarounds are sending JSON API commands via curl, or enabling the Kodi webserver so you can do things from the Web GUI instead of using a remote. IMHO using a remote control is easiest.
-
Kodi software decodes media to create thumbs, so when entering views with thousands of movies or episodes (and a clean install) it will start generating them in the background. Once they have been created (or you scraped the library deliberately, which also creates them) the CPU activity will reduce. Our kernel defaults to the "ondemand" CPU governor, so unless there is a bug that affects AMD chips (or all chips) the CPU should ramp up clock as the load increases. Perhaps try a current nightly image (newer kernel = fixed bugs or different bugs).
-
GUI and CLI both refefence the same password so it doesn't matter how you change it.
-
-
Share the output of "aplay -L | paste", "amixer contents | paste" and "amixer controls | paste" please.
