Posts by chewitt

    Offtopic: is there any specific SSD brand / model /series that you can recommend from your experience in terms of a) reliability and b) low power consumption?

    I've never considered power consumption with SSD's in LE installs as the hardware it runs on has far more impact than the choice of drive and because LE runs in RAM on anything with more than 1GB so there's negligible read/write on the drive.

    I've always picked name branded SSD's on the debatable assumption they won't use low-bin chips. Thus the only drives I've ever had die (not a frequent occurence) were name-brand ones. I pull things apart, move things around, and reinstall the OS on a much higher frequency than any normal user though.

    It's unusual and something to monitor. If it occurs again it might be the first signs of the memory device inside the SSD starting to have problems. It's the kind of panic that you see when there are faulty cells resulting in bad sectors on the block device; causing a failure to read partition data or preventing successful reading/decompression of the SYSTEM file from the boot partition.

    Does the new Linux exploit affect settop boxes running Libreelec or OSMC?

    LE = technically no because we don't have sudo so the exploit chain is incomplete, but as stated above, everything already and intentionally runs as root so there's no need to use the exploit in the first place.

    OSMC = someone else's distro, go ask them in their forum.

    There's an RPi4 build in my test share too; probably not as current as the RPi5 one but close enough. I find the OSD tonemapping to be a little off on RPi5 hardware compared to e.g. RK3588, e.g. the OSD panels that are normally ~85% transparent are more like ~65% and need to be darker, but everything is still work in progress. I didn't specifically check for the leak in a while but that's because things have been behaving so that's probably been resolved. Go test and report back.

    AFAIK the EmuELEC distro uses the Amlogic legacy boot process so if the box is currently booting LE then the u-boot environment is adapted to LE boot files and you'd need to (re)trigger recovery boot so that Amlogic u-boot reads their bootscripts from an SD card, which will modify the u-boot environment to work with their boot files/names. Beyond that, it's best you contact EmuELEC devs for support (I'd assume it has a forum somewhere) because I've never downloaded it or booted it on anything.

    So the GUI plane supports XR24, but the Video plane does not (YUV things only) so next step is to run kmsprint | paste when the emulator is playing (and screen is dark) to see whether the plane is AR24 (default for Kodi) or XR24 .. or what. At that point we need to ping garbear for guidance on what's normal or correct.

    Code
    debug <general>: bool KODI::WINDOWING::GBM::CDRMUtils::FindPlanes(): Using video plane 41
    debug <general>: bool KODI::WINDOWING::GBM::CDRMUtils::FindPlanes(): Using gui plane 38
    ...
    debug <general>: GameClient: Loading game.libretro.uae2021 in standalone mode
    debug <game.libretro.uae2021>: Setting libretro pixel format "XRGB8888"

    Run modetest | paste and share the URL. I'm not familiar with retroplayer internals but let's see if plane 38/41 are supporting that format (IIRC, XRGB8888 = XR24). I'm blind guessing at the problem though.

    NB: Do other emulators, e.g. something simple like a SNES one, work or show the same issue?

    The Either use '-o nolock' to keep locks local, or start statd message comes from the underlying NFS libs but systemd knows whatever follows Options= is an option so you don't need to provide the -o prefix to nolock.

    Investigate manual mounting of an NFS share from the console. Once you have that working .. translate the working config into the required systemd mount file options. Pay particular care to the NFS protocol versions being used because modern kernels (client) might make assumptions on infrastructure (server) supporting equally modern versions of NFS, and if SMB is unperformant you probably have old server hardware running old server software. In my experience SMB works fine unless the underlying network environment is poor, and the cure for that is always fixing the environment not swapping protocols /shrug