Yes, ‘dolby-vision-art’ (Profile 5) also suffers from the audio problem.
After playing thru several demo DV files, one after the other, the video stream got stuck in ‘green/purple mode’ requiring a reboot to resolve.
The logs for playback of ‘dolby-vision-amaze’ with the video+audio+timing components enabled are here https://paste.osmc.tv/gasigogizi
Chris.
Thanks. We’ll have a look through that log. Out of interest, if you set Audio channels to 2 while playing EAC3 with passthrough, does that help?
Setting no. audio channels to 2 & constraining to a fixed no. of channels in settings>system made no difference to the audio problem.
I still heard the same stuttering in 2.0 as I did in 7.1.
Furthermore I tried disabling passthrough so the EAC3 JOC audio was decoded by Kodi (to 7.1 PCM) rather than being passed to the AVR for decoding. This made no difference either.
Let me know if you would like me to try anything else.
We’re wondering if your addons are over-taxing the CPU. Could you try a clean Kodi as a test?
sudo systemctl stop mediacenter
mv /home/osmc/.kodi /home/osmc/kodibak
sudo systemctl start mediacenter
You can revert after that test with
sudo systemctl stop mediacenter
rm -r /home/osmc/.kodi
cp -a /home/osmc/kodibak /home/osmc/.kodi
sudo systemctl start mediacenter
Tried, that, had to access video by a USB stick, no difference I’m afraid.
I really don’t have any add-ons installed/running, above the default set.
However … I think I might have resolved this now.
I have selected a different HDMI input for the Vero-V on the AVR (Yamaha RX-A2A) which supports slightly different features than the one it was originally connected too. This has stopped all the stuttering.
i.e. the Vero-V is now connected HDMI Input 1 rather than HDMI input 4 as shown in the photo below (which is for a RX-V6A Yamaha AVR which uses the same HDMI board as a the Yamaha RX-V6A).
I think this is a little out of date, so am going to research a little more.
I suspect that the problem was to do with HDMI Passthrough only being implemented on HDMI Inputs 1 thru 3, as shown from the specs below. The Vero-V is now on a HDMI Passthrough port (to the TV) .
Thanks for that. Seems device manufacturers are always playing cat and mouse trying to guess what the others are doing. Dolby Vision was invented when HDMI1.4 was the latest thing so just needs to be passed through. I can actually get DV through my Yamaha RX-V373 by spoofing the EDID. Why do they have to mess with it?
Let us know what you discover. I’ve seen reports of DV+Atmos videos not playing nicely on other forums. Maybe it’s an AVR thing, not a player thing.
Will do Graham & many thanks for your support and suggestions.
Yes, the issue I think was really to do with the way AVR handles HDMI passthrough (although the audio is captured by the AVR, on its way to the TV).
The HDMI input ports do behave differently depending on the device connected (and the quality and (non-) conformance of the different CEC implementations).
Chris
We’ve noticed you seem to have two versions of the Amaze clip. One is mp4 and one mkv and your log implies they are playing at the same time. Very strange. Maybe that re-scan library on start is useful after all?
I converted the ‘original’ MP4 to MKV.
Sometimes the container/file format can have an effect on the playback quality. The MKV version contains identical A/V streams as the MP4. The MKV was made using MKVToolNix.
Furthermore there is one final (?) problem with the MP4 version of the amaze clip, once its played to the very end (video and audio all OK) it hangs with the message “Buffering …” indefinitely.
Notably however, the MKV version stops properly without the “Buffering …” message.
I suggest you rename the mkv version so it’s not just the extension that’s different from the original.
That’s interesting and shouldn’t happen. I’ll have a look. The amaze trailer link that you provided above is that mp4 I suppose?
You’ll find the two files (MP4 and MKV) here - Dolby Vision Tests – Google Drive
I did a clean reinstall of OSMC on my DV test Vero to check that the lag issues in the Estuary skin that I reported in the early testing discussion were gone, and am glad to say Estuary is behaving now that I’ve added the public testing DV update, so I guess something got corrupted along the way.
Still seeing the slightly dark SDR conversion as previously reported, performance otherwise is very good.
And …drum roll…the red noise issue if playing a DV file first after a reboot has gone. Is that a consequence of an update in the public version or perhaps something to do with me having reinstalled OSMC from scratch?
It’s hard to tell without seeing the old system. But you were a tester - bugs happen… so things happen.
As long as they don’t resurface, happy days.
Sorry about the inconvenience of having to reinstall OSMC.
Good morning. I enabled the DV function last night with mixed results. After applying the patch I rebooted and found all the DV rips I tried would display only a black screen (audio was fine). Non DV films played as previously. Another reboot and all but one of the DV ones I tried now played ok. The Dolby Vision logo appearing on the LG screen as expected. This was late so I left it until this morning to try again. The vero hadn’t been switched off or rebooted but now the DV rips that would play all had a strong colour cast and the Dolby Vision logo didn’t appear on screen. One rip played but it was similair to an old tv where line (or field) lock had gone - rolling, thick diagonal grey lines!! Unfortunately applying de-bug logging and 2 reboots has restored order - the tested rips now play fine again with the Dolby Vision logo apppearing. I’ll leave the system a couple of hours and check again, unless there’s any useful test you’d like carrying out in between?
Andy
Do you have quantisation range set to Full by any chance? See above:
Thanks Graham. I’ll check when home.
@sam_nazarko Is there some (config file) option to toggle the newly added DV support? Just asking out of curiosity, if someone might want to compare the DV image to the HDR10 image.
‘‘Use limited colour range’’ was already selected ON. The rips are still behaving at the moment, except -
‘‘Force 422 colour subsampling’’ was OFF, and since this is a new LG TV and the menu suggests that LG’s may work better with this selected I enabled it and rebooted. The first DV rip I tried after reboot displays the Dolby Vision logo and the sound is correct but there’s no vision. Press Stop then Play and it comes good. This is repeatable after each reboot and for each of the rips I tried. I’ll disable that menu as I didn’t notice any difference, but thought it worth passing on.
You can turn it off under HDR Processing.
