CatchupTV is not on the banned list. Other items are though.
Here's the list: https://kodi.wiki/view/Official:Forum_rules/Banned_add-ons
CatchupTV is not on the banned list. Other items are though.
Here's the list: https://kodi.wiki/view/Official:Forum_rules/Banned_add-ons
Doesn't R40 supposed to support VP9 decoding? Why isn't hardware decoder used?
Hardware supporting it and someone coding drivers to implement that support are different things .. is probably the reason.
Read: https://wiki.libreelec.tv/hardware/amlogic#installtointernal
TL/DR: You either stick with the old install on eMMC, or boot something newer from an SD card.
LE 12.0 to LE 12.2 does not require a clean install. The core OS is updated, but it's the same Kodi version in both images.
I've no idea what the problem could be, but if you see the splash screen the OS has booted and should be running. However Kodi has not started and thus nothing gets rendered over the splash screen. If you add "ssh" to kernel boot params in cmdline.txt the SSH daemon is forced on and you can probably SSH in to capture the log from the device. Or the Logfiles SMB share might be accessible over the network.
The log isn't a debug log and the catchup plugin you are using hides all the useful ffmpeg information on the media. Then I noticed banned add-ons installed, and found something else to do.
It's unclear what the actual issue is (debug logs demonstrating the problem would help) but disabling DRMPRIME is a workaround and not a fix. You will probably/eventually find that other media will play badly because you've disabled the optimised decoding path and are forcing media to be less efficiently handled.
Any idea?
LE 9.0 uses the legacy vendor kernel and amcodec in Kodi. LE 10.0 onwards uses the upstream kernel which reimplements hardware decoding (but the implementation is incomplete) and Kodi dropped support for amcodec in 2017 as part of an intentional purge of prioprietary codecs and refocus on standards.
TL/DR: the codebases are completely different and while most media plays reasonably well on a C2 it is not pefect and will not work with all media for all users. The upstream codebase is mature and stable for practically everything except media capabilities, where work stalled years ago and has never resumed. You may find that some media is badly encoded and re-ripping from the original sources or re-encoding makes things more playable.
NB: mkv is a container not a format so it's hard to comment further without knowing what the actual format was (although HEVC is the most likely answer).
You'll need to share a full debug log for anyone to comment, log snippets are pointless.
Once we see the full log it'll probably reveal that you're trying to play a 4K 10-bit HEVC file and that will fail because there is no HEVC hardware decoding support on S905X3 (SM1) devices and the CPU is too weak for software decoding.
Changes will be reset on HDMI hotplug events, and that includes reboot.
What LE device are you playing the videos on?
The current workaround is a script (re)configuring the DRM layer from userspace. If someone can come up with a kernel patch to avoid hacking things from userspace: a) we'll know what area of kernel driver code to focus Intel devs on, b) i'll accept/merge a temporary patch to see what issues arise: the patch probably needs to cap bits-per-pixel and those calculations are used for lots of things so there is potential for unintended fallout and the 'simple' change might not be simple.
LE 12.2 and 13.0 have dropped the legacy nvidia driver, and the number of ‘newer’ cards in active use is tiny (we have been telling people not to use nvidia cards for a decade; people have listened) so we may simply drop nvidia support completely and have a more simple life. It will suck to do that, but as nvidia continues to either ignore standards or implement them with some catch that eliminates LE use, so be it.
There's an obvious kernel splat in the log, but nothing obvious about why that occurred, and Kodi has started in 'off-screen' mode.
Are you using any kind of HDMI adapters or an Argon case?
I'm wondering if the audio glitch is similar to the N100 issues here: https://github.com/LibreELEC/LibreELEC.tv/pull/8588 - the script in that PR is not going to be merged as it's too much of a hack, but you could copy/paste it locally and experiment. It basically finds the active DRM connector and limits the max bits-per-pixel to 10-bit as 12-bit seems to cause issues. The root cause is unknown but I have a hunch it's related to bandwidth and UHD video + HD audio maxes out something resulting in audio dropouts.
You might want to add something like video=HDMI-A-1:1920x1080M@60 to kernel boot params in syslinux.cfg in case (for reasons unknown) the box is trying to use a problematic 4K mode. This will clamp initial kernel DRM output to 1080@60 to stop that. There's no impact on Kodi switching to 4K during playback later.
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.