I'll flag the problem internally but I won't guarantee quick resolution. FWIW, that mirror isn't reachable from the UAE either so it's not an IL specific issue.
Posts by chewitt
-
-
-
There is nothing obvious in the logs. Hence I've asked you to follow basic common sense troubleshooting 101 basics using a spare SD card. I'm not going to request it a second time. Your call on the next move.
-
I waited better support from this forum.
Family and work has a higher priority than your harmless cosmetic CPU temp non-bug. Feel free to ask for a refund.
-
For kicks I would take a spare SD card and the latest LE13 nightly and see if the problem is repeatable with default Estuary skin and stock configuration and without the unmaintained VPN addon that fills your logs with junk.
-
Code
2026-07-09 20:31:46.691 T:1228 debug <general>: OnPlayBackStarted: CApplication::OnPlayBackStartedIn the log this is the first invocation of a 'play' ^
Stream info search has completed within 2 secs ^
Code2026-07-09 20:31:48.969 T:1455 debug <general>: CVideoPlayer::HandleMessages - player started 2And by this point audio has synced and playback is started ^
So i'm not seeing a two minute delay from the invocation of playback to playback starting.
Code2026-07-09 20:30:35.747 T:1279 info <general>: VideoInfoScanner: Starting scan .. ... 2026-07-09 20:31:46.691 T:1228 debug <general>: OnPlayBackStarted: CApplication::OnPlayBackStartedHowever there's a 75 second gap between an update scrape/scan of the USB drive and the playback event starting. Do you have Kodi configure to update the library on start? .. perhaps this is the delay you are seeing?
CodeJul 09 20:31:28.529486 Raspberry sh[1197]: SG_IO: bad/missing sense data, sb[]: f0 00 01 00 50 00 00 0a 00 00 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jul 09 20:31:28.530216 Raspberry sh[1197]: /dev/sda1: Jul 09 20:31:28.530216 Raspberry sh[1197]: setting standby to 12 (1 minute)NB: This ^ is also logged in the journal, but this is harmless. It's the result of hdparm configuring standby on the drive and the USB/SATA adapter not implemented all of the SCSI command set (common on cheap SATA bridges) so the kernel doesn't see responses to everything it gave instructions on and it logs this.
-
How is that possible?
Old laptops are typically larger, consume more power, generate more fan noise when used in a confined space, and either offer less or not-much-more capability. Yes the CPU is likely faster and GPU more capable, but RPi4/5 boards are a well optimised package for LE use and a good compromise of features/capabilities/stability. There's no right/wrong answer tho.
-
8ball That was indeed missing. I've updated the image in my testing share.
-
You can add ssh and video=HDMI-A-1:1920x1080M@60D to boot params in uEnv.ini and see if that helps? - The first forces the SSH daemon to start on boot so you can find the IP from another device and log in. The second forces the initial DRM state to 1080@60 output; sometimes it will run at 4K and TV's don't always agree with that. The display.service failure is harmless; this is from the VFD driver service (it fails as the U9-H has no VFD display IIRC). It has absolutely nothing to do with HDMI output.
The LE13 images here: https://chewitt.libreelec.tv/testing/ run a newer kernel with some changes to HDMI/DRM things. You'll also find a U9-H image there (for eMMC install) but mainline u-boot support is still in a rather experimental state and when you hit issues with that image I have no time or interest for bug-hunting right now, so I would suggest sticking with the box image on SD card so that vendor u-boot is used. As much as I loathe vendor boot code it's probably doing a better job with that hardware.
-
emveepee We could create a standalone scan-tables add-on for users to install (is that what you were thinking?) but I'm not sure the extra complication of that is justified. The scan tables are updated infrequently (both upstream LinuxTV and the Tvheadend fork) while the DVB server apps are updated relatively frequently; so if you just bundle the tables into the NextPVR add-on the latest table updates will be distributed to users without much delay. IMHO content quality in the tables is a much more pressing issue.
-
Where is the stuff under /storage/.kodi/addons/service.tvheadend43/dvb-scan/dvb-s from, TvH or LE ?
LE currently packages the upstream LinuxTV tables into the Tvheadend add-on.
-
Any other ideas are also welcome
I'd stick with the RPi4 as it probably delivers a better overall experience than an old recycled laptop.
-
Am I doing anything wrong?
FYI, the backup function in the LE settings addon will backup /storage/.cache, /storage/.config and /storage/.kodi which is normally all you need to capture.
-
This image https://chewitt.libreelec.tv/testing/LibreE…-12.95.1.img.gz has the following patch applied:
Diff
Display Morediff --git a/projects/Generic/linux/linux.x86_64.conf b/projects/Generic/linux/linux.x86_64.conf index 0bd90b1804..68693c1f5e 100644 --- a/projects/Generic/linux/linux.x86_64.conf +++ b/projects/Generic/linux/linux.x86_64.conf @@ -4081,8 +4081,8 @@ CONFIG_CEC_NOTIFIER=y # # CEC support # -# CONFIG_MEDIA_CEC_RC is not set -# CONFIG_MEDIA_CEC_SUPPORT is not set +CONFIG_MEDIA_CEC_RC=y +CONFIG_MEDIA_CEC_SUPPORT=y # end of CEC support CONFIG_MEDIA_SUPPORT=m @@ -4957,7 +4957,7 @@ CONFIG_DRM_CLIENT_DEFAULT="fbdev" CONFIG_DRM_LOAD_EDID_FIRMWARE=y CONFIG_DRM_DISPLAY_HELPER=y -# CONFIG_DRM_DISPLAY_DP_AUX_CEC is not set +CONFIG_DRM_DISPLAY_DP_AUX_CEC=y # CONFIG_DRM_DISPLAY_DP_AUX_CHARDEV is not set CONFIG_DRM_DISPLAY_DP_HELPER=y CONFIG_DRM_DISPLAY_DSC_HELPER=ySee if that works? - Note that DP/USB-C adapters need to be an 'active' type that supports CEC tunnelling; and even then there's no guarantee that the CEC pin has been physically wired up.
-
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.