Posts by chewitt

  • [x86-64] Random Crashing

    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).

  • Transfer log to server systemd-journald-remote

    Quote from Mayoru

    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.

  • Official LE13 Test Images for Amlogic (Kodi-22)

    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?

  • [x86-64] Random Crashing

    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.

  • Official LE13 Test Images for Amlogic (Kodi-22)

    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.

  • Source archive is never downloaded for custom package - why?

    That ^ works for me (at least to download the sources):

    Code
    chewitt@toolbox:~/LibreELEC.chewitt$ ls -l sources/heaptrack/heaptrack-1.5.tar.bz2*
-rw-rw-r-- 1 chewitt chewitt 5553752 Apr 21 15:51 sources/heaptrack/heaptrack-1.5.tar.bz2
-rw-rw-r-- 1 chewitt chewitt      65 Apr 21 15:51 sources/heaptrack/heaptrack-1.5.tar.bz2.sha256
-rw-rw-r-- 1 chewitt chewitt      73 Apr 21 15:51 sources/heaptrack/heaptrack-1.5.tar.bz2.url

    NB: there's no need to hide things behind switches, just build the package directly with, e.g.

    PROJECT=Generic ARCH=x86_64 scripts/build heaptrack

  • [x86-64 - legacy] No HDMI sound with Nvidia ION

    Quote from timemaster

    The splash screen is broken. It shows the same “damage” on every boot, and it's been like that since at least LE11

    That's the Kodi Omega (21) splash screen. The glitches are intentional and part of the splash. Kodi Piers (22) moves back to a more normal one.

    If you are using "adjust refresh" in Kodi config so it switches mode to match the media being played can you disable that and force all media to 1080@60. If you are not using that, please enable that and define 1080@60/59.94/50/24/23.976 modes and allow mode doubling. Do the changes make any improvement?