I have an issue which starts to be seriously annoying. From time to time, during a video playback (tv show / movies) the screen goes black for a couple of second and then video continue to play.
I’ve found some threads with same issue, tried a looot of things, but nothing work.
Tried both LE and CE
Changed HDMI cable
Remove everything was plugged on C2 usb
Changed HDMI port on TV (Samsung UE58RU6105)
Changed color settings on TV / Kodi
I’ve not been able to understand when it occurs, can be every few seconds, or never during a whole movie…
So far, the only things which works is : echo 0 > /sys/class/amhdmitx/amhdmitx0/output_rgb during a playback. It does one more flash but usually solve it for, at least, the end of the movie.
Yes, I know, some threads about similar issues recommend to echo 1 to force rgb, what seems to work for me is 0.
I’ve seen this too on my N2. In my opinion, I think it appeared in some nightly build between 9.2.1 and 9.2.2, much closer to 9.2.2 than 9.2.1. Too bad I didn’t note it then as I use the box only occasionally.
I have this issue, and had it with 9.2.1 (official). Tried various nightlies along the way to 9.2.2 - all still have the issue, and still have it currently.
It’s very annoying.
I just can’t pin it down. It doesn’t really seem like hardware as a reboot will solve the issue (for a while at least).
I really don’t think it is bandwidth related - I can play 4K movies just fine. It’s just as likely to happen with the Kodi UI (1080[/50 in my case) - as during playback (if not more so - indeed the pictures screensaver is one of the main things that seems to set it off).
I can’t find anything in the Kodi logs about it, it doesn’t even seem to think anything is happening, so feels lower level…
I reckon it is this issue of PLL drift: https://forum.odroid.com/viewtopic.php?t=8764
Solved in some builds here apparently: https://forum.odroid.com/viewtopic.php?t=12827
“My custom build contains new PLL settings for HDMI, these are shared by AMLogic. It’s just a code with understandable constants for particular registers, so I thought it is meaningless to share at the moment. Obviously it will be opened to GIthub when this changes helps to fix HDMI issues we have.”
It definitely sounds like very much the same issue.
Would the above give team Coreelec the sort of info they might need to look at this issue?
"Or if the clock is being kept to frequency by a PLL, and the PLL has wider tolerances than some HDMI devices like, it may be that it is drifting a little too much? (I think this was the issue with the Pi / Pi 2 and AVRs where we were getting black flashes, and a config parameter allowed you to reduce the amount by which the HDMI clock could drift? The drift was intentional to allow for small video or audio timing errors to be corrected without dropping / repeating frames?):
It is indeed a bandwidth issue because at 1080p 60Hz, it defaults to a higher chroma setting, whereas for 4K 24 Hz it uses a lower chroma setting.
I was having the exact same issue and I solved it by adding the following line to ~/.config/autostart.sh
echo 422 > /sys/class/amhdmitx/amhdmitx0/attr;
It forces YUV422 on all modes.
Moreover, this problem was resolved when I upgraded my TV/receiver. So, it appears that the problem was with the TV/receiver rather than the cable.