[TESTING] Linux 4.9 kernel and improved video stack for Vero 4K / 4K +

Last time I looked, Kodi wasn’t touching the whitelist unless and until you go and look at it. So as soon as you have a screen, Kodi will be reading the EDID and all the modes supported by your display will survive in the whitelist.

If you then go to look at the whitelist, when you leave that setting screen any modes not supported by by your display will be gone from the whitelist.

Logs of a reboot with the TV off:

https://paste.osmc.tv/ebojuyowuy

After uploading the logs, with the TV now on, I went into Settings/System and the only resolution in the whitelist was 1080p/59.94. After rebooting again with the TV on, the whitelist was restored to what it should be.

Well in the logs you surely have the EDID problem as no resolutions are shown.
So Kodi doesn’t “change” the whitelist but it only shows the one resolution that is your GUI configured one while the rest remains configured.

GUI Resolution: 1920x1080 @ 59.94p
Whitelist:
720x576: 50p
720x480: 59.94p
640x480: 59.94p, 60p
4096x2160: 23.976p, 24p
3840x2160: 23.976p, 24p, 25p, 29.97p, 29.97p, 30p, 30p, 50p, 59.94p, 60p
1920x1080: 23.976p, 24p, 50p, 59.94p, 60p
1280x720: 50p, 59.94p, 60p
1024x768: 59.94p, 60p

===================== Display Mode =================== Q72ho215
VIC:16

---------------------- Display Mode END --------------- Q72ho215


====================== EDID =================== wE0go885
Rx Manufacturer Name: 
Rx Product Code: 0000
Rx Serial Number: 00000000
Rx Product Name: 
Manufacture Week: 0
Manufacture Year: 1990
Physical size(cm): 0 x 0
EDID Version: 0.0
EDID block number: 0x0
blk0 chksum: 0x00
Source Physical Address[a.b.c.d]: 0.0.0.0
YCC support 0x00, VIC (native 0):
ColorDeepSupport 0x00 10/12/16/Y444 0/0/0/0

Audio {format, channel, freq, cce}
{1, 1, 0x07, 0x01}
Speaker Allocation: 0x00
Vendor: 0x000c03 (HDMI device)
MaxTMDSClock1 0 MHz
vLatency:  Invalid/Unknown
aLatency:  Invalid/Unknown
i_vLatency:  Invalid/Unknown
i_aLatency:  Invalid/Unknown
SCDC: 0
RR_Cap: 0
LTE_340M_Scramble: 0

checkvalue: 0x00000000

---------------------- EDID END --------------- wE0go885

Just for info, the problem i was having with a blank or corrupt edid being read and giving me only a low res display and no cec is a lot better in recent updates. Not sure which update got it better.
I’ve had cec for the last few days and all resolutions seem to be available. Only thing is last couple of times I’ve turned the tv on the vero has been on a really obscure resolution. 728p i think. But i can manually switch back to 1080p. I’ll try grab a log when it does it again
But definitely working better
Cheers

I am still working on this – as it affect a few users with specific displays.

Well, yes. It’s correct that the whitelist should be (effectively) filtered to include only modes present in the EDID. But what seems to be happening here is that if the Vero is rebooted with the TV turned off, it requests an EDID, doesn’t get one, and then behaves from that point on as if it had received an EDID with no valid modes.

Presumably the problem is that when the TV turns on, it isn’t refreshing the EDID at that point - it’s continuing to use the blank version it got when it rebooted. If it boots up with the TV on, then it requests, and gets, a valid EDID at that point and sticks with it, and everything is okay.

After experimenting a bit more, it looks as if having the “Lock HDMI HPD” option set is triggering the problem. (I was advised to set that some time ago to avoid some other issue, the details of which now escape me). I’ll try running without that set for a bit and see if anything bad happens.

But I think the way that option works at the moment doesn’t make sense. If the Vero doesn’t get any EDID info at all, it ought to use the last valid cached version, not treat it as a valid, but blank, EDID.

Locking HDMI HPD will suppress hotplug events and would indeed cause this issue.

1 Like

I am also seeing a green screen after skipping through a 4k mkv, you need more logs for this?

1 Like

No – we have enough to work on this now

Sam

1 Like

Hi guys! Some news or update about HDR to SDR conversion and MaxFALL/MaxCLL metadata? Now works?

Discussed recently here

Two different things. For HDR-SDR conversion see the thread @fzinken linked. MaxCLL/MaxFALL is being read from the stream (if available) and passed through to HDR displays. 3.14 kernel wasn’t reading it, 4.9 is.

I decided to try out this update. By using the instructions I was able to update without problems to kernel 4.9.
All my settings (Aeon Nox Silvo skin for instance) look intact. Very cool to see!

How do I upload logs if Vero freezes and I cannot log in via SSH? Do I retain logs if I power cycle? Vero 4K froze trying to play VP9

You can enable persistent journal
Do you have a sample of the file so we can try and reproduce?

I’ll try to grab a 10 second clip

Can you check that the 10-second clip causes a crash / freeze?

sure thing.

@sam_nazarko vp9 was a bad encode. Sorry it long to get back on this issue.

1 Like

Getting the same issue with green screens here. Any ETA on a fix for this please?