A few days later trying to narrow down the problem, but no luck, I’m afraid. I have tried a different HDMI cable, but no luck. At first I thought high resolution videos (720p and higher) were the problem, but with 480p the green saturation also occurs.
The line echo 'rgb,8bit' > /sys/class/amhdmitx/amhdmitx0/attr in /etc/rc.local doesn’t seem to affect anything. When I have the old command and the new command in /etc/rc.local Kodi becomes unresponsive (I can still issue commands via SSH).
The green saturation still occurs frequently and randomly, sometimes for quite some time, otherwise it’s flashing and going back to normal. Switching resolutions or changing the refresh rate helps to get rid of the saturation temporarily. But switching back and forth from a video to settings isn’t really a solution, of course.
I’ve used the May version of OSMC without any problems (using the older echo 1 > /sys/class/amhdmitx/amhdmitx0/output_rgb command).
I’m willing to try and reinstall OSMC, but I don’t have a spare SD card lying around. Is there a way to downgrade without one (e.g. using aptitude, or via network)?
EDIT: Will the instructions in this thread work, using OSMC_TGT_vero2_20170615.img.gz instead of the 2016 version mentioned in the original thread?
Since last update, there is no output_rbg anymore.
I got an Philips PHL9604h.
I also got saturnation since last update and isnt fixed with echoing ‘rbg,8bit’ to attr.
Perhaps you meant doing echo -n ‘rbg,8bit’ > /sys/class/amhdmitx/amhdmitx0/attr? Because with -n argument, attr get extra empty line. See below.
When saturation began(around between 22:50 and 22:55) I got the follow error in journalctl -k:
I’ve just checked the output of journalctl -k. I started a video around 15:59 and the saturation occurred around 16:02. There are no messages around the latter time. This is part of the output from when the video started playing:
Aug 10 15:59:50 vero kernel: [tsync_avevent]event:1, param 1
Aug 10 15:59:50 vero kernel: video pause!
Aug 10 15:59:50 vero kernel: DI: di_receiver_event_fun , is_bypass() 1 trick_mode 0 bypass_all 0
Aug 10 15:59:50 vero kernel: di_receiver_event_fun: vf_notify_receiver unreg
Aug 10 15:59:50 vero kernel: DI: di_unreg_process unreg start 1.
Aug 10 15:59:50 vero kernel: codec_mm:NULL mem_handle for keeper!!
Aug 10 15:59:50 vero kernel: codec:ge2d_store_frame_NV21 cur_index:s:0x121110
Aug 10 15:59:50 vero kernel: codec:ge2d_store_frame d:0xd9d8
Aug 10 15:59:50 vero kernel: codec:vf_keep_current: keep video on with keep
Aug 10 15:59:50 vero kernel: [tsync_avevent]event:2, param 0
Aug 10 15:59:50 vero kernel: codec:video first pts = 0
Aug 10 15:59:50 vero kernel: DI: di_unreg_process vf unreg cost 0 ms.
Aug 10 15:59:50 vero kernel: DI: di_unreg_process unreg stop 0.
Aug 10 15:59:50 vero kernel: codec:vdec1 video changed to 0 x 0 0 fps clk->200MHZ
Aug 10 15:59:50 vero kernel: codec:vdec_create instance ffffff8004198000, total 1
Aug 10 15:59:50 vero kernel: codec:Video stbuf alloced at 0000000063b00000, size = 10485760
Aug 10 15:59:50 vero kernel: codec:vdec_init, dev_name:amvdec_h264, vdec_type=VDEC_TYPE_SINGLE
Aug 10 15:59:50 vero kernel: codec:vdec_init set vfm decoder ffffff8004198000
Aug 10 15:59:50 vero kernel: codec:vdec_dev_reg.mem[0x64500000 -- 0x674fffff]
Aug 10 15:59:50 vero kernel: codec:H264 sysinfo: 1920x1080 duration=4004, pts_outside=1,
Aug 10 15:59:50 vero kernel: codec:vdec_request_irq ffffffc0016662fc, vh264-irq
Aug 10 15:59:50 vero kernel: DI: di_receiver_event_fun: vframe provider reg
Aug 10 15:59:50 vero kernel: set run_early_proc_fun_flag to 1
Aug 10 15:59:50 vero kernel: codec:vdec_init, vf_provider_name =
Aug 10 15:59:50 vero kernel: codec:video first pts = 0
Aug 10 15:59:50 vero kernel: codec:vdec_request_irq ffffffc0016576c0, parser
Aug 10 15:59:50 vero kernel: codec:video first checkin pts = 2ea7fc0
Aug 10 15:59:50 vero kernel: codec:first check in vpts <0x33:0x2ea7fc0> ok!
Aug 10 15:59:50 vero kernel: codec:Enter set parameter cmd1.
Aug 10 15:59:50 vero kernel: codec:vdec1 video changed to 3840 x 2160 60 fps clk->667MHZ
Aug 10 15:59:50 vero kernel: codec:actual_dpb_size 15 max_dpb_size 3
Aug 10 15:59:50 vero kernel: codec:video first pts = 2ea7fc0
Aug 10 15:59:50 vero kernel: pre_de_buf_config: source change: 0x0/0/0/0=>0x9000/1920/1080/0
Aug 10 15:59:50 vero kernel: DI:7920 disable post.
Aug 10 15:59:50 vero kernel: vpts to scr, apts = 0x0, vpts = 0x2ea7fc0
Aug 10 15:59:50 vero kernel: codec:new toggle keep_id
Aug 10 15:59:51 vero kernel: codec:finished correct frame dur
Aug 10 15:59:51 vero kernel: codec: new=4005,old_duration=4004,cnt=25
Aug 10 15:59:56 vero kernel: codec:fix_frame_rate mode play
There is more before the 15:59:50 mark, but I’m not sure if that’s relevant.
That’s a Vero 2 image – are you saying that you are experiencing this problem on a Vero 2?
@vero4k_user Do you find that the GUI colours are correct; video just isn’t? I suspect that when we switch video modes, the setting isn’t persisting. Annoyingly, this is because the TV claims to support a colour mode that it doesn’t (known bug with Philips sets).
The only error in your log is a PTS issue in the video.
[quote=“sam_nazarko, post:47, topic:37483”]
That’s a Vero 2 image – are you saying that you are experiencing this problem on a Vero 2?
[/quote]Sorry, I didn’t take a close enough look at the filenames. I have a Vero 4K, so I should probably use another disk image. But would the procedure from the thread work with the correct disk image?
I decided to gut my Raspberry Pi temporarily and use the SD card. But I feel like a total n00b at the moment, because I can’t seem to insert an SD card properly into the device. When I insert it I feel a bit of resistance (the typical springy feel you get when inserting a card into a reader), but I can still just pull the card out, it doesn’t seem to be mounted properly and is very loose.
I’m inserting a SanDisk Ultra into the top slot right of the second USB entry (there are two smaller slits beneath what I believe to be the SD card reader). I’m trying to insert the SD card as pictured here:
[quote=“bmillham, post:53, topic:37483, full:true”]
It’s a push in to lock/unlock style socket, so once inserted you push it in again to pop it out.
[/quote]It was a bit finicky, but I managed to insert the SD card as directed and do a reinstall. Thanks!
[quote=“sam_nazarko, post:54, topic:37483”]
Quite a few people make the mistake, so no biggee
[/quote]I was a bit hesitant at first, because you have to stick the card all the way in. Prying a small card from the Vero would have been a bit of a nightmare. But yay for push slots.
So now I’m running OSMC May 2017 (2017.05-2). Just had a green flash again and entered echo 1 > /sys/class/amhdmitx/amhdmitx0/output_rgb in /etc/rc.local. After rebooting and watching a video for the past hour I haven’t seen a flash since. So probably not a hardware issue?
Any news on how to prevent this saturation? Since August update I have no output_rbg file, is that correct? filing attr with rgb,8bit doesnt help either.
Hi – it’s being worked on. Unfortunately the issue with Philips TVs reporting the wrong colour space isn’t fixed in the latest version but does work as expected with older ones
I’ve downgraded to the May version of OSMC and won’t update for the time being. Of course downgrading isn’t a trivial procedure (it’s a complete reinstall so you’ll have to backup your Kodi settings, etc.), but that’s the only way to get rid of the saturation issues for now.
Hopefully the OSMC team will find a solution in a future update.
Did you try the HDR improvements in early July. I don’t think anyone experienced problems with saturation then, but they should have, if it’s present now
I’m always fairly up to date with the new releases, or was this an intermediate update? During the last update (the one where the output_rgb command was removed) the saturation issues started occurring. So that’s the early august release (July update), I didn’t notice any issues with the June update, but at that time, the output_rgb command was already present in /etc/rc.local/.
