EDID Override - Injecting a Dolby VSVDB Block

Change file first, if you can test the Framestor remux of Gemini Man.

Check cache settings. Adaptive readfactor, 64MB cache size.

1 Like

Yes, that could be the culprit. Also, make sure your Media server has the throughput and your are using 1Gb LAN all the way. Gemini Man Blu-Ray and related MKV file is one of the few 4K 60Hz Dolby Vision and Dolby Atmos True HD movies - which means it consumes all of the HDMI 2.0 bandwidth (~600MHz).

1Gbit LAN, file on an SSD + SMB share (Win11 server), Adaptive Readfactor, 64MB Cache, 128Kb SMB block size. Tested multiple remuxes of Gemini and Billy Lynn (including Framestorā€™s release and remuxes I created with MakeMKV), no difference - still stutters badly when the OSD (or subtitles) are enabled. Things are significantly better on the latest nightlies (since 20240527 IIRC) - it still stutters a bit but itā€™s much less intrusive.

I have a problem, probably with this pull. Higher bitrate DV streams (70-100 Mbit/s) containing DTS-MA and TrueHD with Atmos audio are problematic. (Throughput is no problem since my equipment handles 200 Mbit/s streams without a problem)
When a stream starts DTS-MA audio cannot sink, itā€™s on for a second or two then itā€™s off for a second or two, and so on. The only (temporary) fix is to press back (10 seconds back) and then the audio comes on. However after a couple of minutes this repeats, audio disappears for a couple of second and then reappears for a couple of seconds. Pressing back (10 seconds jump) fixes it againā€¦ DV streams with only DTS-MA audio or with only TrueHD + Atmos audio work OK.
My AM6B+ is connected directly to LG C2 TV, then via eARC to my Marantz amp, and none of previous CE or your versions have this behavior; reverting to any older version fixes this problem.

I found that is what the stock DV code does - constantly send the vsif. Maybe this is why. Sending it all the time certainly isnā€™t needed for normal operation - at least on my tv.

yep - iirc it sends a ā€œfreshā€ pkt all the time when playing content, but not when not playing.

There is a ā€œconfigā€ command in hdmi_tx_20 to send a hdr/vsif pkt I saw a while back - whilst investigating the Player Led (HDR) - but was immediately overridden with playing video, but maybe whatā€™s needed here, there are also Force HDMI and Toggle Frame flags which sound useful in this context.

Something like:

[DV-Std RGB_8BIT]

echo vsif11 > config

[DV-LL YUV422_12BIT]

echo vsif40 > config

Noted - maybe can build two versions next time one with one without.

The FC 7 and FC 8 are very close - identical apart from this and some code tidy up (which would probably compile down to exactly the same thing when running anyway).

Edit: I think I found why - missed come config changes for the upstream PR - CoreELEC/xbmc from what I can tell is not a direct fork of the upstream xbmc/xbmc repo, so I had manually merged in the changes and missed some config, guess the CE team have a more robust way of doing this.

Anyway hopefully fixed for the next release, will release when I find a fix for the hot plug colour issue - likely later this week.

Likely not the cause but will throw this out there. I tend to separate out the network at layer 2 - where I perceive the need for more solid dedicated bandwidth point to point, generally by using switches - have not yet invested in 10GB infra.

e.g. the Ugoos to NAS is layer 2 fully isolated (no bandwidth sharing) from traffic going from other areas of the house to the internet for example.

Another way to think about it is parallel wire 1GB networking infra - no place where everything funneling down the same 1GB single wire - except of course the router to the internet which is just 1GB up and down on fiber.

Note this is not vlan (layer 3 etc.) so broadcast traffic is crossing everywhere but simple setup.


I do run an air gapped, then separate lan - isolated for some esoteric audio stuff but thatā€™s a whole other story.

Try using Update 7, the second update from the last.
Or maybe try to not use passthrough, use the AC3 audio or let kodi decode the audio.
Itā€™s a long shot, but perhaps the new truehd passthrough code is the culpritā€¦

Those are good tips, thanks. Iā€™ve been considering a more exotic network set up for a while. I have a 2.5Gb capable switch to which the server and Ugoos are directly connected, but the bandwidth there is shared with numerous other devices (although I would expect the traffic to be fairly light most of the time).

I have chopped a 1 minute segment of Gemini Man and copied it to the local storage on the Ugoos and the result was a lot smoother (although there were still a few minor stutters here and there - Iā€™m being very nitpicky), which hints that there is a networking component to the issue. My next step was going to be to try swapping out cables and other things just to rule out the more obvious stuff. Isolating the Ugoos and the server from all other devices is a good shout and I have an unused switch handy for just such a test.

Thanks, I have tried that unfortunately. I even went as far as to strip the audio streams from the file entirely, and the issue still presents.

Yes, I can confirm this. The dolby mat version cause lot of sound issue by me, with the dts-x, and the truhd-atmos sounds.
I returned to the update 7, all ok nowā€¦

Feature Complete - Update 9

  • Rushing this one out a bit (so not much testing my side - may break) as will not have much time to spend on this in the next couple of days, just revert back to Update 7 if you have issues.

  • HDMI Hot Plugin Event with device already on.

    • Display Led (DV-Std) looks good.
    • Player Led (DV-LL) will be purple and green, not sure why this is not working yet.
    • Player Led (HDR) looks good.
  • Dolby TrueHD MAT - Include everything from PR this time!


When testing use the below tar to update a fresh install of CE-21 ng.

Update tar


Dolby VSVDB Calc (no update)


If upgrading from an older version and you experience issues with wrong playback mode e.g. DV playing in HDR etc. then try:

  • Resetting the settings in the CoreELEC section.
  • Toggling the setting in question to another value, move off to another setting and then go back and toggle the setting back to the desired value.
1 Like

Thanks for the update! The wrong colours on input switch are fixed with this :slight_smile:

1 Like

Thanks, I tested the version 9.
I have this 2 files, same, in mkv, and m2ts format.
Both have atmos dropouts in 29s and 49s.
Version 7 has no audio dropouts.
Anyone can test too?

For those who have problems with tne new MAT packer code, did you try adding this setting to advancedsettings.xml as advised in the Kodi forum thread:

  <audio>
    <maxpassthroughoffsyncduration>50</maxpassthroughoffsyncduration>
  </audio>

Source: TrueHD passthrough Test Builds - New MAT Packer implementation

That setting works on android only.

I donā€™t think thatā€™s true. Kodi on CE picks up the setting and shows it in the debug OSD. And Iā€™ve even see the error counter going up in the OSD as well.

FYI 50 is already the value set from the code side.
here

If an installā€™s advanced setting have been changed and not reflecting that then can set back to 50 and try.

Thanks for testing, will have a go later this week to confirm - looks like will probably just pull this out - sounded good at the time but distracting from any other testing, want to work out any further corner cases for the DV element.

The new MAT packer code has already been merged into the Omega branch so it should be in the next nightly. I feel like itā€™s becoming a bit of a red herring. Maybe, it would make the most sense to stick to DoVi changes. Otherwise, weā€™re commenting on code that cpm did not author and probably has little control over.

1 Like