Around a month ago it looks like we resolved the HDR flickering issue, but some banding was visible. We’ve been making some progress thanks to extensive testing, but this still required manual intervention to get this to work properly. This should now no longer be the case.
I’d appreciate it if you could test this and provide feedback before we potentially release this as an update to other users. To test this update:
Add the following line: deb http://apt.osmc.tv stretch-devel main
Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
Your system should have have received the update.
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.
With any luck, HDR playback no longer exhibits flickering or banding. We need to make sure this doesn’t cause problems for situations where a user is not playing HDR content.
Please post a debug log and output of: sudo systemctl status hdr.service. It can take a couple of seconds for banding to disappear because we have to poke it from user-space (although that will be addressed shortly)
Bitdepth and the actual banding patch are two different things. If you needed to set bitdepth before applying the actual patch, you have to continue doing so.
Something is not working the way it should:
Only in very rare cases the banding disappears by using the new timer method.
But if I start the new hdr service manual by using “sudo systemctl start hdr” the banding always disappears immediately. I therefore checked by using “systemctl list-timers” if the service is triggered within the given frequency by the timer and indeed it is.
So what’s going wrong here?
I changed the timer/service in order to switch between round0 and round1 everytime the service gets triggered, but this did not solve the issue. Then I tried to reduce the trigger frequency to 1s but this did not help either. I’m out of ideas now.
If you still have no joy I have a workaround – but I’d be surprised if any further changes beyond this are necessary.
As explained, this is a temporary fix. I did have a better fix, but this is now deferred to the SoC vendor as they have further improvements which will address the problem in a better manner. This requires a microcode update however (binary blob)
I did update again, but it still does only work in very rare cases (as Theetjuh already had written).
The only way it works reliable is to start the service manually after playback has been started.
