This is with the new update from today. When booting up the Vero 4k, the signal is 1080p@24Hz with 4:4:4 at 8bit according to my AVR. When watching HDR content, it correctly switches to 10bit. However, when done, it doesn’t revert back to 8bit but is now 1080p@24Hz with 4:4:4 at 10bit.
I’ve used the “HDR Autoswitch”-checkbox before that and didn’t have this issue.
My TV was calibrated for SDR with the 1080p/4:4:4/8bit signal. My TV definitely treats color and white point adjustments differently for 8bit and 10bit signals, making my current calibration obsolete. What’s even worse though is that there’s no consistency - if I were to have it calibrated again for 10bit, the next time I’d restart the Vero 4k the signal will be 8bit again, i.e. calibrated wrong until I play some HDR movie.
Hi,
To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.
So, in summary:
- activate the logging
- reboot the OSMC device
- reproduce the issue
- upload the log set either using the
Log Uploader method within the My OSMC menu in the GUI or the ssh method invoking command grab-logs -A
- publish the provided URL from the log set upload, here
Thanks for your understanding. We hope that we can help you get up and running again shortly.
Regards Tom.
The HDR auto switch option never worked properly. Now it does. So video will be presented correctly, which is quite important.
What’s important is that when you play the next file, the bit depth is correct.
Can you confirm if this is an issue with video playback? If it is solely confined to UI, we can certainly address this for you.
If there are issues with playback we will need to collect some logs to assist you
Sam
We encountered some issues trying to switch bitdepths on the fly - in particular when a video was being rendered at the same resolution as the GUI. The latest update sets bitdepth to 10 for both GUI and all videos if the display supports deep colour. In pre-release testing no-one could detect a difference between playing 8-bit videos at 10 bits and playing them at 8 bits, so we went with it.
What I don’t understand is why you are getting 8 bits at all. The splash screen may be 8-bit but once Kodi has started, everything - GUI, SDR, HDR should be in 10 bits. If you need to recalibrate, doing it at 10 bits should work. Please check cat /sys/class/amhdmitx/amhdmitx0/config when showing the GUI and when playing SDR.
You can also quickly check the render at 8 and 10 bits with echo 8bitnow | sudo tee /sys/class/amhdmitx/amhdmitx0/attr, echo 10bitnow | sudo tee /sys/class/amhdmitx/amhdmitx0/attr and to revert to default (10 bit for your display) echo now | sudo tee /sys/class/amhdmitx/amhdmitx0/attr
I know, it used to take me several tries launching a video until it really switched to 10bit, but as far as reverting back to 8bit afterwards, that was never an issue with that option.
Link to log file, actions taken:
- Rebooted: GUI is 1080p@24Hz 8bit
- Launched 1080p_8bit.mkv: display stays at 1080p@24Hz 8bit
- Stopped video, returned to GUI: display stays at 1080p@24Hz 8bit
- Launched 4k_hdr_10bit.mkv: display switches to 4k@24Hz 10bit
- Stopped video, returned to GUI: display switches to 1080p@24Hz 10bit
- Launched 1080p_8bit.mkv again: display stays at 1080p@24Hz 10bit
- Stopped video, returned to GUI: display stays at 1080p@24Hz 10bit
I have 1080p@24Hz configured for the GUI in the system settings, because most of my content is 24p and I don’t want the delay everytime I play videos. I’ve tried 60Hz, but Kodi still booted up with 8bit.
Also, this might or might not be related: I think the new “HDMI hot plugging” is causing issues for me randomly.
Sometimes when booting up, my 24Hz setting for the GUI is reverted to 60Hz and I have to go back in the settings and change it, this didn’t happen before but happened 2 or 3 times since last night when testing stuff.
Another time the Vero was seemingly sending a corrupted HDMI signal to my receiver after I stopped a 4k-HDR video and returned to the main menu. It caused random blank screens during navigation in the main menu. My AVR wasn’t even able to display its overlay anymore and it wasn’t able to tell me what resolution, refresh rate etc. is being sent, it just displayed “----” for all those fields.
Connection chain: Vero 4k → Marantz NR1608 → LG OLED C7
If there is no change in resolution and/or refresh rate and/or bitdepth Kodi does not reset the video clock. So if it starts up in 8-bit, it will stay that way until you play a 10-bit vid. But it won’t ever revert to 8 bits.
Now I thought we had it so it starts on 10 bit if using a 10-bit display. But I think in getting the last bugs out of hotplugging HDMI something changed on that front.
I’m 250 miles away from my vero atm but will have another look next week and see if I can reproduce your sequence.
That’s not supposed to happen. Can you grab a log immediately after that happens, please?
What I’m seeing at the moment is:
-
Immediately after rebooting, it displays the GUI as 8-bit (1080p/60, 4:4:4).
-
When I start playing an 8-bit video, (1080p/23.96Hz - a remux of a blu ray) it switches from 444 8-bit to 444 10-bit.
-
When I stop the video and go back to the GUI, it stays at 444 10-bit, and won’t output anything else until it’s rebooted.
Are you saying that all of that is deliberate? I’m not sure that outputting 10-bit colour on an 8-bit video is going to work for everyone - as I think someone said higher up, the TV won’t necessarily use the same calibration settings for 8-bit and 10-bit input.
Logs if you need 'em: http://paste.osmc.tv/curuniteci
Yes, except it should start off with the GUI in 10-bit.
Here you go. Didn’t take long, it happened on the first restart. I had 1920x1080@23.98Hz configured in the settings. After reboot it reset to 1920x1080@60Hz in settings, confirmed by my AVR.
OK, thanks. Kodi sometimes stores the desktop mode in guisettings.xml as ‘DESKTOP’, instead of something more useful. There is therefore no way to know what the desktop mode was before the reboot. Don’t know why. Looking into it.