Hi,
The HDR improvements were released for public testing but not part of an update for a few weeks beforehand.
I suspect if you’d tested these improvement you’d also have found the problem, albeit a bit earlier. I just wanted to confirm that was the case.
Sam
Downgraded to July update. It still has the output_rgb setting and everthing is fine again. Will wait with updating until a solution is found(or i buy new tv :P). I am sure the pro developers will find some sort of a solution. In all honesty Philips should update it’s firmware tho, because i understand the problem lays there. Thanks Sam and Mensch for feedback.
Would you be happy to test a solution? It may not necessarily work and
require a downgrade again which would be a pain; but I would like to get
this resolved.
I think the Phillips TVs that are affected are quite old, so I think the firmware
updates are unlikely.
Sam
I would be willing to test, even if it means downgrading again. The process of getting the box up and running again is a bit of hassle, but if it means the problem will be fixed I’m not that concerned.
The last firmware update for my Philips model is from 2010, so I think it’s highly unlikely that there’s new software in the works at Philips. 
Okay – stay tuned. The issue seems to be caused by changes in the new kernel that refine the HDR-10 support.
I had to borrow an SD-card for the downgrade. So i rather not downgrade again. 
Maybe if booting/installation from USB could be available/fixed?
Should august update solve this issue? Is it the force hdmi video mode over TV EDID one?
Was your issue solved by downgrading?
That would be the first step in identifying the problem you’re experiencing; because it may not be related to OP’s.
The EDID override option is a bit different: it’s now possible to set a video mode even when the TV’s EDID reports a different preferred mode.
Sam
Hello Sam,
As i mentioned 15d ago, downgrading to july update solved the problem.
Hi,
It seems I have similar issue with my Vero 4k connected to Sony TV (KDL 40w4000).
Everything is fine when it is connected directly.
But when connected via Yamaha receiver (RX-V463) the black levels 0-16 are reproduced as completely black.
Could you please check what can be wrong?:
Connected directly:
osmc@osmc:/sys/class/amhdmitx/amhdmitx0$ cat edid
Rx Brand Name: SNY
Rx Product Name: SONY
Manufacture Week: 1
Manufacture Year: 2008
Physcial size(cm): 160 x 90
EDID Verison: 1.3
EDID block number: 0x1
blk0 chksum: 0xe4
Source Physical Address[a.b.c.d]: 3.0.0.0
native Mode 70, VIC (native 255):
ColorDeepSupport 80
31 16 20 5 19 4 18 17 22 21 3 2 7 6 1 32
Audio {format, channel, freq, cce}
{1, 1, 7, 7}
Speaker Allocation: 1
Vendor: 0xc03
MaxTMDSClock1 1135 MHz
ColorMetry: 0x3
SCDC: 0
RR_Cap: 0
LTE_340M_Scramble: 0
osmc@osmc:/sys/class/amhdmitx/amhdmitx0$ cat rawedid
00ffffffffffff004dd9015c010101010112010380a05a780a0dc9a05747982712484c21080081800101010101010101010101010101023a801871382d40582c450040846300001e011d007251d01e206e28550040846300001e000000fc00534f4e592054562058560a2020000000fd00303e0e460f000a20202020202001e402032b70501f101405130412111615030207060120230907078301000066030c00300080e3050301e20039023a80d072382d40102c458040846300001e011d00bc52d01e20b828554040846300001e011d8018711c1620582c250040846300009e011d80d0721c1620102c258040846300009e000000000000000000000000aa
Connected via receiver:
osmc@osmc:/sys/class/amhdmitx/amhdmitx0$ ^C
osmc@osmc:/sys/class/amhdmitx/amhdmitx0$ cat edid
Rx Brand Name: SNY
Rx Product Name: SONY
Manufacture Week: 1
Manufacture Year: 2008
Physcial size(cm): 160 x 90
EDID Verison: 1.3
EDID block number: 0x1
blk0 chksum: 0x3c
Source Physical Address[a.b.c.d]: 1.2.0.0
native Mode 76, VIC (native 255):
ColorDeepSupport 80
31 16 20 5 19 4 18 22 21 3 7 6 1 32 14 15 29 30 10 11 25 26
Audio {format, channel, freq, cce}
{1, 1, 7f, 7}
{1, 7, 7f, 7}
{2, 5, 7, 0}
{7, 6, 1f, 0}
{9, 5, 2, 0}
Speaker Allocation: 5f
Vendor: 0xc03
MaxTMDSClock1 5 MHz
SCDC: 0
RR_Cap: 0
LTE_340M_Scramble: 0
checkvalue: 0x3cf60000
osmc@osmc:/sys/class/amhdmitx/amhdmitx0$ cat rawedid
00ffffffffffff004dd9015c010101010112010380a05a780a0dc9a05747982712484c21080081800101010101010101010101010101011d80d0721c1620102c258040846300009e011d8018711c1620582c250040846300009e000000fc00534f4e592054562058560a2020000000fd00303e0e460f000a202020202020013c02033676561f101405130412161503070601200e0f1d1e0a0b191a2f097f070f7f071507503e1fc04d0200835f000066030c00120080011d00bc52d01e20b828554040846300001e011d007251d01e206e28550040846300001e8c0ad090204031200c405500c48e210000188c0ad08a20e02d10103e9600c48e2100001800f6
The only difference I can see except of audio format support is “native Mode 76” vs. “native Mode 70”.
Thanks!
Thanks for your report. I’ll investigate further
Sam
Hi
I’ve taken a further look at this and tested to see if we can get this to work as it did before on the new kernel.
I’d appreciate it if you could try this new kernel and report back.
Currently, we’ve added a quirk for Philips TVs. More fixups may be needed.
/etc/apt/sources.list
deb http://apt.osmc.tv jessie-devel main
sudo apt-get update && sudo apt-get dist-upgrade && reboot
Please see if the issue is resolved.
I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.
I’ve just updated my installation with the release from the development channel as detailed above. grep VERSION_ID /etc/os-release returns: VERSION_ID="2017.09-1".
Unfortunately the issue still persists. After about a minute in the main menu of OSMC the screen switches to the saturated greens.
Can you post a log? I want to check if my changes are detecting your TV properly
Sam
Maybe too soon to ask, but was the log of any help? If I can test a new build I’d be happy to do so.
I actually pinged another user; but a second set of full logs would definitely be appreciated.
Sam
Which log file should I provide, is the output of journalctl I posted earlier enough? If necessary I can save the output again when it happens.