Posts by chewitt

    The "reboot update" triggers recovery boot mode causing the SoC to search for boot scripts in the first partition on the SD card. The LE boot scripts are then found, which sets params in the vendor u-boot environment to use LE boot files and if you reach Kodi then everything has worked. To revert to CE you will need to trigger recovery boot mode again. In most cases that's done with the toothpick method, which (with SD card removed) will find their boot scripts and set boot params to use CE boot files. On most boxes (but it depends on what customisation was done in vendor u-boot) both OS are tweaking the same boot params to suit themselves which prevents a simple swap between OS(es) by removing the SD card.

    The ethmactool-config service creates a unique MAC address based on the CPU serial to avoid issues where vendor code sets the same MAC for all boxes (and users have more than one of the same box causing conflicts) or where the MAC was not set in the factory and changes on each boot. As long as you have a static MAC address "systemctl mask ethmactool-config" will disable the service on future boots and stop the message from showing up.

    Not sure about the blue tint, but as long as it doesn't happen on the TV it's not something I'll be interested in chasing. Vendor u-boot does a few weird things.

    NB: If the S805 image is AMLMX .. it is pre-Alpha state and is not even remotely supported.

    Code
    2023-02-05 01:29:18.397 T:1533    ERROR <general>: failed to initialize egl
    2023-02-05 01:29:18.397 T:1533  WARNING <general>: Visual 0x21 of the window is not suitable, looking for another one...
    2023-02-05 01:29:18.403 T:1533    ERROR <general>: GLX Error: vInfo is NULL!

    No idea what the cause of the problem is, but basically it fails to find an OpenGL surface to render the GUI onto and fails. As LE10 will receive no further fixes/changes now I'd start with a bump to LE11 beta 1 and see if that resolves things?

    The box is clearly booting and SSH is running if the connection is reset (if it wasn't, it would time out). If you remove "quiet" from boot params it will dump text onto the screen. It will scroll fast so the trick is to record a slow-motion vidio on a phone and as long as you have a steady hand you can watch it back slowly to see if you can spot something. Another option is to add "textmode" and it will boot to a local console session (Kodi is not started) and with a USB keyboard connected you can poke around (run "journalctl | paste" and share the URL).

    For kicks, create a new SD card from https://chewitt.libreelec.tv/testing/LibreE…95.1-box.img.gz as there are some minor fixes for things and a newer kernel.

    You can try booting the Tanix or Beelink 'box' devices on the Allwinner/H6 download page.

    LibreELEC is an appliance-like Linux. There are add-ons for most media-related things that users might want (other than piracy tools) but there is no package manager so you cannot just install things.

    You can experiement with Pulse audio to send audio over the network, but this generally sucks. There is no default/native option in the OS or Kodi to route audio to a UPnP target. Kodi can play from UPnP sources, but not 'cast' media to a UPnP target.

    There is no "Everything" mode in Picard, and I would caution against trying to stuff lots of files into the "to be scanned" pane. Your files will not always exactly match; requiring you to drag and drop things, which is easiest when there's only the files for a single album there. It will take time to go through and match/cleanup/correct all your albums. However, this is only a task you'll ever need to do once. You can train your children to do it ($free slave labour) although they often lack the obtuse knowledge of your music collection to tag everything right :D

    Two comments:

    a) If you can't boot from a USB stick, you might need to pull the drive and connect it to another PC and run the install from USB there; or write the installer image directly to the HDD and then (in the old PC again) interrupt boot and type "run" (direct from install media, which is now the HDD) instead of following the normal "install to target" flow.

    b) LE is small and lightweight which is appealing for older hardware, but we target current and recent HTPC hardware so are often missing the drivers and such needed for old hardware. If you have something so old that it won't boot from a USB stick, a more conventional distro that supports a wider range of hardware might be more appropriate.

    Our strong recommendation is to use a separate SAT>IP box or separate the 'head' end device from the player client so you can run whatever distro and distro version that works with the tuners you have, while the player client updates frequently with LE releases. The IT proverb "If it works, don't fix it" applies to anything with DVB .. it's the suckiest stuff we attempt to support.

    If the system was installed/working and then stopped; the most likely cause is the USB stick (or whatever device you boot from) has failed. LE is packaged with the entire OS contained in two compressed files (KERNEL and SYSTEM). In a conventional distro, if you have bad sectors on disk it will impact only the couple of files that are written to those sectors, and often the impacted files are not critical files so everything will appear to work until the whole disk gives up. Due to the way LE is packaged, if media corruption impacts any sector involved in storing either of KERNEL/SYSTEM the OS cannot boot at all.

    If corruption was due to something like unexpected file loss you might be able to boot Ubuntu and scan/fix the filesystem. If it was due to bad media (underlying pyhsical disk or flash memory issues) then you bin everything and start over with a new USB etc. - You might be able to get the contents or important things from /storage as that's a separate partition on the disk.

    IMHO there will only be one RPi killer, and that's another RPi :)

    RPi4 is not the best spec thing in the market, but only comparing hardware specs misses the point about RPi boards. They have massively better long-term software support, so they are reliable and continue to improve with age.

    Although bitrate is probably involved somewhere in the overall scheme of things, I'd guess internal bandwidth between IP blocks is where things are on/approaching the limit, so (repeating myself) some overclock might be helpful.