Posts by chewitt

There's no shortcut/script for it, but the backup process we use in the LE settings add-on is just a 'tar' command. If the box is only hosting Tvheadend you only need to stop Kodi and then tar the contents of /storage/.kodi/userdata/addon_data and any other dirs that you've used in your TVH configuration as the rest of the OS and Kodi should be using default settings.

NB: If you are thinking to update to LE 12.2 (or LE13 nightlies) Tvheadend 4.2 is no longer supported and only Tvheadend 4.3 exists in the 12.2/13.0 addon repo you are updating to.

In theory de-featuring the board to a single HDMI connector shouldn't be an issue, but if you fuzzed one thing it's possible other things were damaged too. Historically i'm able to play 4K30 VP9 content from YouTube, although I didn't test since the rather niche regression below was possibly added (and can't test from current location).

There is one software regression we are triaging, noted when playing 4K H264 on an RPi5; much higher resolution than 720p VP9 but also software decoding so there's a chance your issue could be the same thing. Log in to the RPi5 over SSH, run rpi-eeprom-config -e and add SDRAM_BANKLOW=3 to the end of the file, then reboot. Any better after? NB: If no difference, it's not the same issue and you can revert the change.

Quote from MatteN

Usually there is no autoupdate first week or two,

There will never be auto-update from 12.0.x to 12.2.x.

LE only auto-updates within the same release series, e.g. 12.0.0 > 12.0.1 > 12.0.2. It never auto-updates between major releases like 12.0.x > 12.2.0 or 12.x > 13.x as major releases often contain breaking hardware changes and/or Kodi major version changes.

For example. forced update from 12.0.2 > 12.2.0 would be an issue for RPi5 users running Tvheadend 4.2 (doesn't exist in 12.2) or an x86_64 device with older nVidia card would rebot to no Kodi home screen (GPU drivers don't exist in 12.2).

You can manual update in the settings add-on if you've read the release notes and nothing impacts you.

The laptop has a proper WiFi antenna allowing 'max' transmission rates and so much single-core CPU capacity that single vs. multi-threading makes no practical difference. The CPU design is general purpose and the fully built system uses a large amount of power and generates a lot of heat even when handling trivial tasks.

The RPi5 has a rubbish antenna so WiFi will always be at a disadvantage when compared to Ethernet, and the ARM CPU single-core performance is much lower so single vs. multi-threaded has a more noticeable impact. The SoC package is a lot more efficient and a fully built system uses considerably less power and generates less heat for a trivial workload.

As usual, the moral of the story is .. use Ethernet

Random guess is that pget is multi-threaded and get is not.

Best to continue the discussion in the Tvheadend forum thread: https://tvheadend.org/d/9200-server-spec/

heitbaum any ideas?

[  888.846372] VideoPlayer[1304]: segfault at 48 ip 00007f20f594ce85 sp 00007f20a77fe280 error 4 in r600_drv_video.so[7f20f55b2000+b48000] likely on CPU 1 (core 1, socket 0)
[  888.846392] Code: 45 00 01 f0 83 2e 01 0f 84 b0 01 00 00 0f 1f 84 00 00 00 00 00 48 8b 83 e8 00 00 00 48 89 ab f8 00 00 00 66 0f ef c0 49 89 e4 <48> 8b 68 48 0f b7 45 44 0f b7 55 40 0f 29 04 24 48 89 ee c6 43 3f

No idea what any of that means .. Just flagging in case someone else does. I'd personally start with testing an LE13 nightly release to see if newer (everything) magically resolves the issue? - because even if we discover what the issue is, there will be no fix for LE12.0.

2025-08-13 19:08:23.604 T:976      info <general>: ffmpeg[0x208aae90]:   Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn (default)

^ media is detected as 4K23.976 (10-bit, with a colourspace normally associated with HDR)

2025-08-13 19:08:23.740 T:979     debug <general>: CRenderManager::Configure - change configuration. 3840x2160. display: 3840x2160. framerate: 23.98.
2025-08-13 19:08:23.745 T:892     debug <general>: DeleteRenderer - deleting renderer
2025-08-13 19:08:23.745 T:892     debug <general>: LinuxRendererGLES: Cleaning up GLES resources
2025-08-13 19:08:23.745 T:892     debug <general>: SetHDR: setting connector colorspace to Default
2025-08-13 19:08:23.745 T:892     debug <general>: LinuxRendererGLES::Configure: fps: 23.976
2025-08-13 19:08:23.745 T:892     debug <general>: SetHDR: setting connector colorspace to BT2020_YCC
2025-08-13 19:08:23.745 T:892     debug <general>: LinuxRendererGLES::Configure: HDR passthrough: on

^ then it flags a renderer with [email protected] and appropriate colourspace, but have you enabled "adjust reresh" ? - If yes it will output using the whitelist (not configured) or best guess at the right mode. If not, it will scale the output to the desktop res (1080@60). So make sure adjust-refresh is enabled and configure the whitelist as per the wiki article.

Once done, if you run kmsprint on the SSH console before playback it will show DRM connector properties as 1080@60, and during playback it should show them to be [email protected]?

Quote from Ozyman

Hope this helps!

Not much. Please repeat after creating a plain SMB mount to the device where you store media, then play something appropriate and 4K from that source using the Kodi 'Videos' view so we can see a playback event containing all the normal and useful ffmpeg/drm/Kodi media debug info that's being masked or suppressed by the Plex plugin you are using. In the log you've captured I can sort of figure out where playback probably occurred, but there's no useful info.

Do we have to guess what OS or distro the other instance of Kodi is running on?

Quote from ghtester

The issue is still the same in LE13.

The issue is still not reported to Tvheadend developers. TL/DR; expect your issue to still remain unresolved.

Quote from chuck

I am surprised and disappointed that they don't have an installer for Linux.

We had this in the past, but to create a single binary that runs on all Linux distros requires Qt to be built from sources in a 'static' config (else users need to install 350MB+ of shared Qt6 packages to run our 3MB app) and the bump to Qt6 (needed for a long list of reasons) required a completely different build command/recipe to the one previously used with Qt5. Nobody on staff ever managed to figure out the new recipe; including several folks that work with Qt6 professionally in their day-jobs. So we have no Linux app.

Should you wish that to change, go find the build recipe.

The "invalid-key" error is something internal to the wireless stack and has nothing to do with "passphrase" for the network. It's root cause is still unknown but poor signal strength is a regular factor in it being seen.

Post the entire log somewhere else there's no point asking upstream devs to comment; it's the first thing they'll ask for.

There must be only one APPEND line in the syslinux.cfg file (with your video= changes) and the boot=UUID= and disk=UUID= details (the UUIDs) must match the UUIDs of the two partitions on the internal drive, use 'blkid' to check them. If you have the wrong UUID details the system will not boot because you told it to use a UUID (partition) that doesn't exist, hence the error message you saw.

The problem description suggests you're trying to set the Kodi desktop resolution to 4K (and users typically pick 4K60) which you probably don't want to do. Have a read here first: https://wiki.libreelec.tv/configuration/4k-hdr

If the device won't switch to any 4K modes (or perhaps modes above 4K30) for playback, the normal cause is HDMI cables that won't support the bandwidth required, or a mismatch between the colour output on the HTPC and input on the TV, e.g. TV only allows 4:2:0 input and you're sending 4:2:2 or some RGB format.

The additional dice-roll on inexpensive Intel devices is that the HDMI outputs are often derived from DP using an LSPCON chip which has its own firmware (can be buggy or needing updates) which influences the capabilities of the HDMI chain as this is cheaper to manufacture than wiring up a dedicated HDMI display transciever on the board. Some users find they need to use the DP outputs with an external DP to HDMI adapter to avoid problems with the internal one. Of course, the external DP to HDMI convertor also has a chip (with firmware) so they are not all equal, but unlike the internal convertor you can order a few different ones from Amazon and then return them if they didn't work.

For some users it all just works fine. Others have a more frustrating experience. We'd love to meet the Intel engineer who first came up with the idea of using LSPCON chips with their NUC designs (which everone has copied since). Preferrably in a dark alleyway so we can thank them properly for all the extra support work and frustration we've encountered since then.