Posts by chewitt

    The default VPN confs used by most providers simply "route all traffic down tunnel" .. hence the issue. However, most containers are NAT'd on the local host so they only expose ports/services via the existing IP address/interface of the host. To fix this you'd need to run containers from anothre IP address/interface (can be a alias/virtual interface), and then fiddle with the routing rules in the VPN conf so that you only route all traffic for the main interface (excluding the container interface) down the tunnel.

    Our default config uses servers so you do not need to configure anything for NTP to work; assuming your network or your ISP does not obstruct the normal process. ISP blocking sounds dumb, but appears to happen more often than you'd realise.

    Clean boot, wait 2 minutes, then "journalctl | paste" and share the URL here so we can see what the system actually does.

    Assuming you're okay at the SSH console and can read internet HOWTO posts on uncompressing a tar file (the backup). You can take a backup on LE 9.2.6 (using the settings add-on) and make a manual/selective restore of the following from the backup:





    The Python 2>3 changes (and arch change) mean you need to reinstall add-ons anyway .. consider it an opportunity for spring cleaning. The scrapers are also different in Matrix so you can either take the highest numbered DB files and existing Thumbs cache and use it again or only copy sources.xml and then rescrape. The guisettings.xml file has other config, but some will be x86 specific so it's always 50/50 how that turns out when swapping arches. With practice it takes 5 mins to reconfig everything in Kodi settings so it's not a big deal.

    I wouldn't say dead, but I'm on hiatus for a while now since I don't have much free time for kerenel fiddling (busy in the real-world) and vdec development has been stalled for two years, so from a Kodi perspective there are no improvements to be excited about. There is still ongoing work on the Amlogic SOC platform overall.. the core OS is solid and increasingly used by industrial use, desktop and some of the retro gaming distros; but all of those have primary use-cases that do not depend on multimedia capabilities in the same way LE/Kodi does.

    But still I think the e2fsprogs package should be present in the default image as LibreELEC supports EXT4 filesystem. It's just 1,5M uncompressed (615K compressed).

    This is the first time I have any memory of someone demanding (let along actually needing) defrag tools in LE and I've been hanging around the project and its forerunner for nearly a decade. On that basis alone I'm confident defrag tools are not a must-have thing for our users. You also fundementally mistunderstand how the team thinks about adding unnecessary cruft into our images. Adding 200Kb of new files causes huge debate. Adding 1.5MB for something withiout large-scale user demand .. isn't going to happen. Even if it was needed the approach we'd follow would be to bundle up a collection of things into a "disk-tools" add-on that the minority who need them could install (see the current btrfs-tools add-on as an example).

    Pi Foundation folks are currently focussed on finishing the 10/12-bit video and 4K60 work. This will firm up the kernel/DRM side of the puzzle and allow some ffmpeg cleanup, which needs to happen before more complication (with deinterlace) is added. It's vacation season so all of the above is running about 3/4 speed right now. IMHO the current software deinterlace capability is quite usable (not perfect, but usable).

    Content status tracking is done in Library based views (Movies/TV Shows) using content scraped into the Library. Or are you using the non-Library "Videos" view?

    So this is Version is 9.97.1 Beta and not 10.0 Stable ?

    RC = Release Candidate. More stable than a beta, but not the 10.0.0 release either (hence not called beta, or stable). Generic is pretty stable though. The remaining WIP bits are related to other platforms (mostly RPi4).

    Wrappers aren't the right approach because the level of optimisation required for functional 4K pipelines on ARM hardware is high and you'll always end up needing to write efficient native drivers. You can bodge 1080p, but RAM speed and bandwidth become big factors with 4K. The tertiary challenge with V4L2 is that it's all super new and still in a lot of flux; we're still some way from making a serious effort to upstream our current working code to ffmpeg because lots of things are still being experimented on.