Posts by chewitt

    Devices need to use passwords when connecting and/or reauthenticating to the network. This happens in normal use. It happens a lot more frequently when signal/connectivity is poor; and RPi boards generally have poor(er) connectivity before we place them into cases that reduce it further. So the short answer is "nobody knows" (could be any and all of the items you've listed) but if the issues reduce when moving boxes closer to the router, it's probably the normal issues seen with RPi boards, and the solution(s) are moving things closer, using an external wifi dongle with better connectivity, using ethernet instead of wifi, etc. etc.

    EXT4 is considered reliable and Ubuntu defaults will have formatted the drives appropriately for normal use like LE, and while Kodi crashes can corrupt files in the filesystem, esp. databases which Kodi is responsible for managing, they should not cause corruption to the filesystem itself. This means filesystem errors in the system log are more likely to be the result of power issues, i.e. sudden power loss, or issues with the physical disk media.

    If you are lucky it's minor corruption and running fsck against unmounted drives will fix things. If you're less lucky the physical drives are okay but the filesystem is properly messed up and needs a total rebuild. If you're properly unlucky there's physical media damage to the drives. These days physical media damage is rare unless some form of physical shock is also involved, but it's not completely impossible. Failures also follow a bell curve: if the drive is going to fail it's more likely to be when the drive is still very new, or years later when it's very old. Failure rates often correlate to the manufacturing batch of the drives too, so the ideal scenario when purchasing a set of disks is to acquire disks from a variety of different batches not all drives from the same batch.

    The only way to find out is trying to fsck, or trying to reformat and rebuild. Beware that if formatting, the default quick format done by most tools may not find physical media issues. That kind of thing is normally only found by trying to 'zero' the drive by writing to all sectors (also rather long and boring).

    What should I consider? How should I configure it?

    The need is somewhat moot because LE runs the core OS from a virtual filesystem in RAM on all boards with 1GB+ RAM so writing data to the journal is not writing constantly to the SD card like a standard Linux distro.

    To configure systemd-journald-remote you'll first need to compile a custom LE image that builds systemd with journald-remote support, and copy the required binaries and service files into the image, as we don't currently do that.

    The easier option will be to install the rsyslog add-on from the LE repo and use that to send logs to the NAS. I've never personally played around with it, but it exists and last time we broke it people complained. On that basis I assume it's used and working; else we'd be complained to again.

    As the saying goes: "past performance does not guarantee future performance" but I've been running LE13 nightlies for a year or more (albeit on an RPi5 not RPi2) without drama.

    Download the relevant nightly file to /storage/.update and reboot. If you want to hedge your bets take a backup first as Kodi only handles upgrades not downgrades.

    IR remote details are defined in device-tree and (no surprise) the N2 dtb defines the Odroid remote not the Dreambox one. It can be overriden in a custom IR map file (there's a wiki article on that).

    The N2 dtb working proves there's no underlying kernel issue. The issue will be a difference between the actual hardware and how that hardware is currently described in device-tree. As the vendor kernel (which we have a device-tree file for) is rather different to the modern upstream kernel and I've never seen a Dreambox board we're reduced to guesswork and playing "spot the difference" with dtb files that work/don't-work. In this respect the N2 isn't so helpful as it isn't based on the W400 reference design and has a large number of differences.

    To narrow the field, please try other "meson-g12b" device-tree files and flag if any have working audio?

    I'd suggest updating to an LE13 nightly before doing anything else. If there's a bug/issue related to UPnP the issue is with Kodi not the OS layer (LE) and all Kodi development moved onto K22 more than a year ago. See if anything changes with the update.

    imhotep Update using https://chewitt.libreelec.tv/testing/LibreE…h64-12.80.2.tar as I've reverted a couple of kernel changes, then share a log URL again.

    I'm also interested to see the log when meson-g12b-dreambox-one.dtb is configured, to see if this clears up a couple of other (unrelated to audio) things in the log. Again, share a log URL.

    If there's no difference with either (audio card not detected) configure the uEnv.ini file to use meson-g12b-odroid-n2.dtb and if that boots (not guaranteed, but it probably will) share a log URL.