The overall set of scan tables that LE bundles (upstream LinuxTV repo) aren't the same that Tvheadend bundles (own repo with extra commits) but the DVB-S tables for Astra-1{M|N|P}-19.2E appear to be the same in both locations and were updated in the LinuxTV repo from Lyngsat/KingOfSat three months ago.
Perhaps a blind scan with wscan2 needed? .. but I'll let others comment on troubleshooting suggestions as I'm not an experienced Tvheadend user.
The upper size limits of an EXT4 filesystem are orders of magnitude larger than 12TB and far beyond any normal persons storage budget. The 12TB drive size isn't an issue.
Doemela while we appreciate the attempt to be helpful, this is a support forum not an encyclopedia, and we strongly prefer the tone and style of human-written posts over blocks of obvious AI-generated content.
The government "Sovereign Internet" project mandates all service providers to have such capabilities and the communications regulator provides a frequently updated monitoring (block) list that must be implemented. It's unlikely that our infrastructure is deliberately targetted. More likely something objectionable is or has been hosted with DigitalOcean and Hetzner (where we host things) and their ASN ranges are configured instead of specific sites or IP's and we're just collateral damage.
The "index has wrong digest" logged error is probably the result of the download failing so you end up with a truncated .xml.gz file that doesn't match the published sha256 checksum. Add-ons are hosted directly (not mirrored like release images) but the addon server infrastructure is not overloaded and there is no active traffic management (bandwidth throttling) on our side. If there was a global problem with our infrastructure we'd see a ton of user reports, and we're not, which suggests a localised issue; something about your network or the connection between you and our infrastructure.
For kicks you can experiment with a current nightly on a spare SD card, but you should see the same problem since your requests are hitting the same server/infrastructure on our side.
The images in my share now synthesise a MAC address for the BT interface from the CPU serial and set this on boot to workaround issues where the (Broadcom) chipset ends up with a factory-default address which BlueZ ignores; resulting in BT not working. This is the correct resolution for the lack of working BT on WeTek Play2 boxes, which has been reported a few times, and likely impacts a few other devices too. The appearance of a BT 'regression' in LE 12.0 is the result of Linux 6.5.y kernel changes (LE 12.0 shipped with Linux 6.6.y) where the btbcm driver reverted to an earlier (stricter) handling of factory-default addresses. I was never able to track the cause down when previously looking; but now with help from Claude the dots were finally connected.
At the moment the MAC setting is done in the btmactool buildsystem package but I will probably rework this and ethmac tool into a common package before it gets upstreamed to main repo.
Mayoru Forum rules state clearly that we do not support when banned addons/repos are installed. What you installed from the banned repo is not relevant to our decision. There will be no debate on this point.
Run pastecrash after it crashes and share the URL generated; it would be useful to see the crash log.
If you or anyone have an idea how to solve this let me know please
Use an LE13 nightly and install flatpak and then the retroarch flatpak?
In modern Windows OS the SMB client MUST use authentication. So you need to set a user and password and enable auth on the Samba server. I forget whether it's required but since it's quick; reboot after changing/resetting the config. Also ensure the Samba server min/max version settings are correct, e.g. min SMBv2 and max SMBv3 and not min/max forced to SMBv1 as modern clients no longer speak the SMBv1 dialect.
I know that this thread is ancient ... but ... is there still a way to preconfigure WiFi?
There never has been a way to preconfigure it (LE has never packaged os_config.json). I'd suggest you force the SSH daemon to start by adding "ssh" to boot params in cmdline.txt and then connecting an Ethernet cable. As you have not configured an IP on the RPi it will auto-configure itself with a 169.254.x.x/16 address. In the absence of DHCP the device you need to connect from should also self-configure itself in the same range (which is a large range) and you can run arp -a or perhaps ping the broadcast address (the .255 address of the local subnet) to discover the other device's IP address; and then connect over SSH. Once connected over SSH you can run connmanctl > agent on > scan wifi > connect <name-of-service> to configure the network connection, and use kodi-remote to navigate around the screen. If you struggle with the remote IP discovery another approach is to have your computer connect to WiFi and then share its connection via Ethernet to the RPi, which results in the RPi using a known IP subnet that requires less guesswork.
I've forbidden automatic upgrades, waiting for stable LE13 to come up
FYI, development/nightly images never auto-update.
All forms of "spinning rust" media have a lifespan; typically 5-7 years but nothing is ever guaranteed. Boot LE with the drive attached and run "pastekodi" and share the URL so we can see the kernel/system log. I'm expecting to see a bunch of errors that suggest the USB drive has problems; the errors can/might hint whether the issue is related to a messed up filesystem (might be recoverable) or something more hardware oriented.
Official:Forum rules/Banned add-ons - Official Kodi Wiki
You have banned add-ons installed; no support
IMHO the three main causes of hardware lockups are power and thermal issues, and then software issues. For hardware like an Intel N100 device the software side is used at a large enough scale that hard lockup bugs in software are quite rare.
