Seems to be encountering a persistent HDMI CEC issue where other player device on the CEC chain has stopped responding after a while (a few hours to a few days).
My setup is…
Panasonic GZ OLED TV
> Apple TV 4K - TV HDMI 1
> Samsung soundbar - TV HDMI 2 (ARC)
> OSMC Player - Soundbar HDMI 1
I’ve noticed this issue since updating to the build after the updated video stack was merged into the Debian 11 test builds.
Resolving this usually involves restarting OSMC, or disconnecting the HDMI connection to OSMC or powering everything off altogether.
I’ve also noticed a similar behaviour when CoreELEC updated to 19.5-Matrix_rc1 on the ODROID N2+.
Will try and get some logs however it has not been consistent as to when it will occur.
You can enable debug logging with an advancedsettings.xml file with an option to hide the overlay so you can use the device without being being annoyed. The log will likely get big enough that uploading will be an issue unless you restart Kodi periodically. If restarting Kodi needs to be avoided then when you go to upload logs use the method in the wiki for “Sanitizing your logs” and trim the boring bits out manually to get the size down.
Will give it a go, last time I tried extended debug logging, the resulting file were wayyyy too big.
Probably should have clarified, the OSMC device is a Vero 4K+.
The Vero itself has no issues with issuing/responding to CEC commands when this issue occurs, neither does the TV nor sound bar.
The only issue seems to be with the Apple TV itself - It couldn’t “switch” sources back to itself via CEC nor send commands to change volume, sometimes it would have issue communicating with the sound bar, causing audio to be duplicated across the TV and sound bar speakers.
Initially I’ve tried restarting the Apple TV, thinking it’s the cause of the issue but it never really went away, until one day I’ve tried unplugging the HDMI connection from the Vero and everything came good.
Is the bullseye build for Raspberry Pi also a 64bit version?
In the Wiki it says that RPi Images are 32bit but After an online upgrade uname shows „aarch64“ which could break some of my Docker containers…
I don’t know if this behaviour is actually specific to the Bullseye test build or not, but if it turns out not to be, then feel free to split this into a different thread.
Anyway: there’s an issue here with the logic of choosing a default playback resolution with whitelisting active. I’ve been watching some standard definition stuff on iPlayer lately, and the video typically has dimensions of 960x540 (frame rate 50Hz). The standard resolution it plays this at is 576p/50 - meaning it is being downscaled horizontally from 960 pixels to 720, with some consequent loss of detail. Whitelisting resolutions should never cause the video to be downscaled - that’s part of the reason for using a whitelist. It should be upscaling to 720p/50 or 1080p/50 instead.
The good news is that the latest update does indeed fix the “green screen” problem when playing VP9 videos. The bad news is that it also reintroduces a bug which was fixed some time ago in the mainstream release where, when playing HDR VP9 videos, my Vero 4k+ fails to trigger the TV to switch to HDR mode.
My Vero 4K+ is set to download updates daily, so I get whatever you push. @EduardoRS said the issue was fixed, I was just trying to confirm (or not). Maybe you pushed something you didn’t mean to push, but I’ve been watching YouTube without any green-screen problems today, which I couldn’t the last time I checked.
Everything needed for VP9 to work properly isn’t pushed yet - only a partial fix for green screen issues, which is why I didn’t announce anything yet. When the full set of fixes are in I’ll update the original post.
I’ve made some additional changes to smooth out some playback issues, and VP9 should now work as expected. However – one change that has been made is somewhat temporary, and we will develop a better solution for this soon, so do keep testing VP9 playback as updates come through.
I updated about five minutes before posting that, but some more update-stuff has appeared since then. (Or maybe the previous update just didn’t “take” somehow). Anyway, having updated again, I’m happy to say VP9 is now working correctly, including in HDR.
I have an issue where I can’t scrub through a .ts recording without completely breaking the video. E.g. last night I recorded Match of the Day from BBC 1 HD. If I start playback from the beginning, all is good. The moment I attempt to scrub forward, the video freezes into a corrupt mess (see example) with the audio still working. Sometimes the corruption is completely locked, other times it lurches from one corrupt image to another. I also find that I can’t pick up playback from a resume point (video is corrupt), only from the beginning. Scrubbing through the video of this file works perfectly on my LE 9.2.8 Pi 3B
