Posts by chewitt

You can partially restore some the content of the backup (add-on settings, databases and thumbnails, etc.). Just avoid add-on binaries as those will be for 'arm' CPU architecture and will not run on x86_64 hardware.

There is no support for piracy infested forks in this forum and you aren't using LE on any devices. So i'll point out that a lighthttpd package is already in the buildsystem as a Kodi dependency, but beyond that you're on your own.

Run "journalctl | paste" and share the URL from a cold/clean boot and after a minute or so.

The USB audio card route would be best, as this provides an independent soundcard to route audio to. I'm not sure if the current behaviour is hardwired in hardware (in the SoC) or in the kernel, but I suspect the former if both legacy and modern kernel images behave the same, as those kernel codebases have almost zero driver code in common.

The samba server is configured to require credentials. The default user = libreelec, and pass = libreelec .. unless you change them in the LE settingsd add-on. So enter the details and store the credential in the local keychain and the GUI shouldn't prompt you again. Or change the user to match whatever credential you have previously stored for the same host (looks like user = kodi, pass = ???).

Anyone running that piracy infested garbage is on their own. Good luck.

I trashed the log post, because a) the URL was invalid, b) when you fix it, it links to a garbage post on crypto crap

I've assumed you're booting from a USB key which can be removed and inserted somewhere to edit the config. The alternative would be to boot from a Live USB key (ours or any other distro) .. something to get a text console to mount/edit the config.

I last booted our codebase on x86_64 hardware more than a decade ago so I've no idea about GMA3600 support. The system log should provide some clues about what is/isn't happening though.

Update to the 9.2.8 final release for RPi devices. If no change, grab a spare SD card and test with current LE11 nightlies. If no change, file a bug report in the Kodi forums so upstream devs responsible for the TVH add-on and/or Kodi can investigate.

Reinstall the legacy version of LE that worked before, then stop Kodi, manually copy the latest update file to /storage/.update/ and then erase the /storage/.kodi folder and reboot. On restart you should end up with a (legacy) bootloader that works and clean Kodi setup.

Nightlies are in an alpha state, but crowdsourced bug reporting normally catches anythibng major quickly so they're not extreme. The netflix issue should be resolved (add-on author was publishing fixes).

Add "ssh" to kernel boot params to force the daemon to start.

Correct.

Well there's no general issue with SMB shares, so perhaps try an LE10 or LE11 nightly on a spare SD card.

● ledfix.service - LEDfix Service
     Loaded: loaded (/usr/lib/systemd/system/ledfix.service; disabled; preset: disabled)
     Active: active (exited) since Sat 2022-09-24 14:27:48 +04; 6 days ago
    Process: 675 ExecStart=/bin/sh /usr/bin/ledfix (code=exited, status=0/SUCCESS)
   Main PID: 675 (code=exited, status=0/SUCCESS)
        CPU: 102ms

Sep 24 14:27:48 WP2 systemd[1]: Starting LEDfix Service...
Sep 24 14:27:48 WP2 systemd[1]: Finished LEDfix Service.

I don't see any issues with the service when it runs ^ .. admittedly not on a C2 but the service has run without logging errors.

No idea. To be honest it wasn't obvious that you were directly connecting the two RPi devices (not via a router) so I was expecting them to be in the same subnet and thus the OMV interface would be accessible.

Speed of navigation in a large library is mostly about CPU and I/O performance of the device where the library DB files and artwork thumbnail caches reside. Using a less art-intensive skin and lower resolution graphics has a major impact (as less data to be fetched and rendered to the screen) and using a better CPU and particularly SSD/nvme storage (so access times are lower) are also important. I've also found that GUI scroll speed is often dictated by the remote device; benchmark things with a 'keyboard' not an IR device where slow(er) key-repeat timings can make the GUI appear sluggish even when compute performance is good.

Converting the PC that's storing the media into a NAS will probably improve playback start times (as more efficient network, etc.) but will not improve browse times as Kodi stores the DB/thumbs on the playback device, not the sharing device. The partial exception being with you use an SQL database (which is likely on the sharing device/NAS) but then artwork access still has more impact than DB query times.

Two options:

a) Configure a static IPv4 address in LE settings add-on (network) settings

b) Configure the router with a static DHCP reservation for the MAC of each RPi device

I would personally do 'B' because this means the DHCP assigned IP is persistent over reinstallations of the device and copy/pasting things to a router GUI is usually quicker than entering details with a remote control (nothing has a keyboard attached in my setup).