[TESTING] Debian 11 Bullseye

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.

Any tips to capturing logs for such situations?

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.

Can you reproduce the problem when only an OSMC device is connected to the CEC bus after powering everything off at the mains for a minute?



Will give it a go, last time I tried extended debug logging, the resulting file were wayyyy too big. :smiley:

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…

Architecture remains unchanged.

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 50Hx). 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.