My Vero V seems to get into a state where nothing plays. If I try to start a movie or TV show the screen will change for a split second as if it’s trying to play and sometimes it will play a few frames but then it just kicks back to the menu. Sometimes rebooting seems to fix it, sometimes it doesn’t. I managed to catch it with debug logging turned on.
Here is the media info for the particular file that I was attempting to play in the log, though when it gets this way it seems to do it on all videos: https://paste.osmc.tv/awexuzufay.mel
It’s lead to some very disappointing movie nights.
Unfortunately I just went to test this and I first tried to play it with it going through the AVR like normal and it is deciding to behave properly right now. I suppose I can wait until it starts to misbehave again and then see if connecting it directly to the TV changes anything. It’s hard to troubleshoot as I don’t know what exactly causes it and so I can’t perfectly replicate it every time. And if I make a change that seems to fix it I don’t know if it ACTUALLY fixed it or if it is just working for that particular moment. It mostly seems to happen when I gather the family together to watch something as if it’s actively trying to embarrass me.
Ok, so the first requirement is to have an audience. Keep us informed. If you want to keep debug logs on without the annoying info top left then make a file ~/.kodi/userdata/advancedsettings.xml with this content
OK I just got it to do it again. Same file I just stopped it and played it again until the problem happened again. After it kicked me back into the menu I unplugged the Vero from the AVR and plugged it directly into the TV in a different input than the AVR uses all while the Vero was on and sitting at the menu. Now it seems to play fine. I can keep it plugged in this way and see if it actually fixed it. Though I would wonder what issue is has with my AVR.
Thanks for the tip about turning of the debugging OSD. That could be very useful.
There’s something strange about that amp. In your log we see
Source Physical Address[a.b.c.d]: 0.0.0.0
That would normally read something like 1.2.0.0 showing Vero plugged into HDMI2 on the amp and the amp plugged into HDMI1 on the TV. It might be irrelevant as it’s only to do with CEC I think but it does indicate something’s not quite right with HDMI. I see the amp wasn’t cheap and is still under warranty so perhaps you need to speak to the suppliers (Kalibrate?)
I am in the U.S. so I purchased from Summit Hi-Fi. CEC is sort of a nightmare on the thing so I generally don’t use it and just do remote juggling. I also was just reminded that I need the Vero to go through it because the TV doesn’t pass DTSHD through to eARC (though it will Dolby TrueHD which is a curious choice I’m guessing has to do with licensing). That does point me in a direction though. Curious if it would report something more rational in instances where it does decide to work.
That is what I would predict as my laptop is plugged into input 1 on my AVR and the AVR is in input 4 of the TV (because it supports eARC). This is the path that the Vero V usually takes.
OK, so the Roku’s EDID is a dog’s breakfast. It has 3 128-byte blocks. This doesn’t comply with the VESA standard although Google AI tells me it’s not uncommon in consumer electronics. A compliant EDID would have a block map as the second block and 4 blocks altogether. It compounds this error by declaring only one extension block (ie 2 blocks total, not 3) in the penultimate byte of the base block.
When that EDID is parsed by Vero, it does seem to be reading the third block but completely misinterpreting it. The byte sequence 71 38 which is part of the DTD for 1080p60 in that third block ends up in that CEC address string 7.1.3.8, replacing the real one 1.0.0.0. This may be innocuous but since I don’t know why it’s doing that I can’t be sure some other corruption is not happening. Certainly the DTD is lost but if you are able to get a picture at 1080p it might not matter.
Your AVR can’t make sense of it, either. It too reads the third block and passes through a corrupt version of that DTD in block 2 and an almost empty third block. You can see that as DTD2 in the edid-decode you posted (garbage data).
So here’s a suggestion. You could grab the EDID sent by your AVR to Vero, correct the corrupt DTD and delete the third block. You can load that into Vero. That will either solve the problem or show us there’s something else that needs fixing.
That sounds like a plan. Sorry for my ignorance but how can I do that exactly?
Fascinating. I think I’ll also pass this information along to Summit/Tonewinner. Is this non-standard implementation something you think the more mass-marketed brands know about and account for in their designs? Tonewinner is more of a “boutique” Chinese brand themselves.
Some context: I’ve got dozens of EDIDs here for testing and this Ruku one is only the second I’ve come across with more than 2 blocks. Many, though don’t comply with the CTA/VESA standards. OSMC, like other companies, have to cater for that sometimes contradictory data.
I’ll be interested in what ToneWinner say. They have to take the Roku EDID apart, cut out the things they don’t support (like 4k120) and add in their audio caps, so they need to interpret the whole thing, not just pass it through.
I see. So it might not necessarily be out of compliance? Forgive me, I am an audio engineer for live productions and, to a smaller degree, an A/V technician so I have an understanding of EDID and what it is for but I’ve never gone this deep into how it actually works under the hood. It’s quite interesting. I’m heading home from work now. How might I go about implementing your suggestion of altering the EDID information that the Vero receives?
I thought it would take me less time to make one for you than it would take to explain it. Also, the tool I would use to do it is no longer available. But before that, more research, with some help from Google:
The HDMI Forum introduced the HF-EEODB in HDMI 2.1 to replace old VESA block maps and save precious byte real estate. It provides a modern way for a high-end display (such as a 4K@120Hz/144Hz or 8K TV) to immediately declare exactly how many total blocks must be read to get all the data.
So what I said before about non-compliance was wrong. It’s just not compliant with HDMI 2.0. It seems both Vero and your AVR are not recognising that data block (E2 78 02). Not surprising on Vero as it’s not specced to HDMI 2.1 but your AVR does claim 2.1 support so shouldn’t be mangling that EDID. It’s removing a Dolby Audio data block and the HDR10+ data block as well as messing up the DTD.
Since in this respect HDMI 2.1 is not back-compatible with HDMI 2.0, I wonder if there’s a switch on the Roku to make it output a HDMI 2.0-compatible EDID? Meanwhile, we’ll have a look at supporting that HF-EEODB on Vero.
Thanks for looking into all this! While it is a bummer I am having these issues what I’ve been learning through this thread is very cool.
The TV does have a per-input option for “Compatibility Mode” which I believe forces HDMI 1.4. I also just realized it’s default “Auto” option seems to flip a coin with the laptop as I have seen it output either 3 or 4 blocks at any given time. Here is some more info that might be useful. My laptop is an old MacBook Air (2015 i think) with CachyOS installed. Connected with a Thunderbolt to HDMI adapter.
