Don’t use 422. DV does its own thing and gets confused if you set that.
1 Like
Merry Christmas to all!
Glad to report that DV works great on my Vero V and TCL 65C855!
Right after installing and rebooting, I encountered a black screen playing back DV content, but reading comments above, I toggled “Use limited colour range (16-235)” under “Settings > System > Display” which was already on (just toggled off and on again) and rebooted via the OSMC UI “Power > Reboot” and then everything just works perfect and i got the proper “Dolby Vision” badge for the movies and TV shows.
I also noticed on my TCL 65C855 that there is an additional “Dolby Vision Game” (I have this set to “Dolby Vision Dark”) option under “Picture Settings > Picture preset” which isn’t normally an option when playing back DV content on Google TV apps such as Disney+.
1 Like
Merry Christmas!
I too installed the test image and after the last week of constant movies and test videos, I am pretty confident to say that DV is working great with the Vero V, Anthem 1140 receiver and my colour calibrated LG C1.
Great work everyone. Is there any sort of anticipated release date for the full releases?
Tested a couple of videos. Works like a charm, no issues so far. Thanks a lot for your effort Sam and team.
Couple of things to brush up on. I’d think mid February would be realistic.
2 Likes
From a “security first/zero trust/yada-yada” perspective, is there any reason that the instructions are to add
http://apt.osmc.tv bullseye-devel main
to the list of sources, not
https://apt.osmc.tv bullseye-devel main
?
I checked the main sources.list file, and that lists
deb https://apt.osmc.tv bullseye main
so certificates should be fine, etc.
I get this is just a temporary testing update modification/channel, but still there should be no need to reduce the device’s security posture if it can be avoided. For the sake of a single character 
It doesn’t matter. Using HTTPS does not improve the device’s security due to the nature of APT.
Each of those plays fine here with no buffering and keeping the filenames as-is. Is that buffering repeatable?
Same here. No buffering issues and both clips stop as expected.
Happy to report that the buffering problem with the MP4 version of amaze has gone since I plugged the Vero into HDMI Port 1 (which supports HDMI audio/video passthru) of my AVR.
Checked both files just now, and they played perfectly.
Furthermore the Vero-V as I have it configured, is performing well now with my test files. The ‘quirks’ (if you like) concerning system settings (e.g. ‘Using Limited Colour Range’) and selecting adequately Dolby Vision/Audio supported inputs on AVRs and TVs I think needs be clearly communicated to users. I guess this could be done by refining the default settings or at the very least improving the ‘help’ text on the settings/menu pages of the skin.
Thank you.
Thanks for the feedback but if it was up to me I’d say we can’t give any advice about quirks of particular AVRs. The labelling on yours seems contradictory 
1 Like
Indeed the labelling of the HDMI inputs is contradictory, but the labelling by Yamaha in the first photo of :
([TESTING] Vero V: Dolby Vision TV led support - #70 by thechrisgregory)
was provisional, but does show that they (can and do) configure the HDMI inputs differently.
Consequently I took a ‘try it and see’ approach, whilst noting that the more recent spec (in the second photo) (labelled RX-A2A) states HDMI Pass-through is supported on HDMI 1 to 3.
Any advice/help concerning HDMI inputs for Dolby Vision etc should just be general, i.e. check the spec of your AVR HDMI inputs.
in case someone is keeping a list for compatibility:
Vero V
LG C7 (2016 OLED model)
Denon X6200W receiver (2015 model)
tested multiple mkv remux files… all working good!! appreciate all the work by the OSMC team
1 Like
Looking at the info via my avr when playing a DV file and it states 8 bit. I thought DV was 12 bit which is downsampled to 10 bit which my TV supports. Is DV restricted to 8 bit only or is my avr reporting incorrectly?
8-bit is correct. ‘Standard’ DV is actually 422 (12 bits) in a RGB 8-bit ‘wrapper’. This is so it can be sent through HDMI1.4 if that’s all your AVR supports.
Quite, but if the spec says ‘Dolby Vision’ it would be good to know what they mean by that if it doesn’t actually support a DV signal.
1 Like
Hi, i installed DV patch as described, after some struggle with settings params (force 422 = false, use limited color range = true, reboot device) the dolby vision started to work. LG CX tv recognize dolby vision content but somethimes i can see burned pixel in pictures. See attached image. What can i to do with it?
1)i’ve change hdmi cable also.
2) sometimes half of screen is burned or large area of picture
So many things could be causing this from bad rip to display calibration. If you upload a short clip which shows the problem we could check it out. Upload debugs logs for a start, though, so we can see the video type and all your settings.
Adding more details:
- It happend for all DV what i tested.
- I migrated vero 4k into vero V via osmc backup. Can this have affect on it? I think to try new instalation of osmc.
- some DV are correctly played with plex od lg cx dlna player. It means DV source should be correct.
I can’t immediately see anything unexpected in logs.
Good idea. You are getting a load of these
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label1231) was not found.
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label1263) was not found.
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label1274) was not found.
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label1280) was not found.
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label1312) was not found.
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label136) was not found.
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label147) was not found.
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label153) was not found.
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label185) was not found.
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label196) was not found.
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label202) was not found.
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label234) was not found.
2025-01-03 14:27:51.428 T:2983 debug <CSettingsManager>: requested setting (label245) was not found.