15.0.1.003 - GUI flashes

Boris, does the flickering also appear in the final render for you?
It does for me and sometimes the flickering starts mid-render.

I have the flickering during entire exported video. Will retest after adding some ram to my setup
It just switches between graded (most of the video) and ungraded (i'd say 1 frame only every 2-3 second) version during entire footage.

p/s your makeresolvedeb is great! Using it with debian 10 also, thanks!

I ran several tests yesterday and I think I have found a solution. My theory is that this somehow boils down to how Resolve loads libraries, mainly CUDA, that is based on CentOS paths and in some configurations this can behave unpredictably. It's difficult to tell without knowledge of the inner working of Resolve. But by some creative symlinking, Debian can be made to behave more like CentOS. This appears to fix the issue. (ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib64). I'm not very fond of modifying Debian in this way but for Resolve I'm afraid we have no other choice for now.

This also means that this flickering situation is most likely unrelated to the original problem described in this thread even though it appears to be very similar.

I have updated makeresolvedeb (16.0-3 or 16.1b3-2) with this workaround. Download and update to one of these and I'm pretty confident that your problem will go away also.

I have updated makeresolvedeb (16.0-3 or 16.1b3-2) with this workaround. Download and update to one of these and I'm pretty confident that your problem will go away also.

I rebuilt resolve 16.1b3 with new script and it stuck now at "Loading Waveform monitor" screen.
Retested with previous build - all fine
Reinstalled new one - stuck at same screen again.

Debian 10 64 bit.
p/s maybe we should separate makeresolvedeb issues from this topic, do you have one already?

I have updated makeresolvedeb (16.0-3 or 16.1b3-2) with this workaround. Download and update to one of these and I'm pretty confident that your problem will go away also.

I rebuilt resolve 16.1b3 with new script and it stuck now at "Loading Waveform monitor" screen.
Retested with previous build - all fine
Reinstalled new one - stuck at same screen again.

Debian 10 64 bit.
p/s maybe we should separate makeresolvedeb issues from this topic, do you have one already?

I agree. I created a new thread for Debian issues. We should step away from this thread since this is, as far as I can tell, unrelated.

New thread --> viewtopic.php?f=21&t=99747

I ran several tests yesterday and I think I have found a solution. My theory is that this somehow boils down to how Resolve loads libraries, mainly CUDA, that is based on CentOS paths and in some configurations this can behave unpredictably. It's difficult to tell without knowledge of the inner working of Resolve. But by some creative symlinking, Debian can be made to behave more like CentOS. This appears to fix the issue. (ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib64). I'm not very fond of modifying Debian in this way but for Resolve I'm afraid we have no other choice for now.

i know, that you are really doing your best to avoid this kind of hardly acceptable dirty workarounds, but some issues can only solved by fixing the actual cause in the manufactures code. i still have my doubts, if it's really helpful to hide this actual need resp. sound bug fix requests and instead prepare workarounds, which just increase the negative side effects and debian incompatibilities even further. nevertheless i still like your well intentioned practical efforts.

i personally still prefer container solutions to work around this issues in a more radical way, but this approach also comes with some drawbacks and is hardly usable for simple end user because of its complexity.

I ran several tests yesterday and I think I have found a solution. My theory is that this somehow boils down to how Resolve loads libraries, mainly CUDA, that is based on CentOS paths and in some configurations this can behave unpredictably. It's difficult to tell without knowledge of the inner working of Resolve. But by some creative symlinking, Debian can be made to behave more like CentOS. This appears to fix the issue. (ln -s /usr/lib/x86_64-linux-gnu/ /usr/lib64). I'm not very fond of modifying Debian in this way but for Resolve I'm afraid we have no other choice for now.

i know, that you are really doing your best to avoid this kind of hardly acceptable dirty workarounds, but some issues can only solved by fixing the actual cause in the manufactures code. i still have my doubts, if it's really helpful to hide this actual need resp. sound bug fix requests and instead prepare workarounds, which just increase the negative side effects and debian incompatibilities even further. nevertheless i still like your well intentioned practical efforts.

i personally still prefer container solutions to work around this issues in a more radical way, but this approach also comes with some drawbacks and is hardly usable for simple end user because of its complexity.

I totally agree with you Martin. The current situation is very inconvenient. I do utilize containers for most of my testing and is something I seriously considered but, as you say, containers are not something the average user wants to deal with. I have really tried in the longest to avoid bad workarounds but we have sadly come to the point where we really have no other choice. The way Resolve handles libraries is not done properly and that really is something that only the developers can fix. In the meantime I try to keep these ugly fixes in a deb that can at least remove them in a controlled manner once we have a proper solution.

The amount of questions I receive regarding this really is beyond my capacity. That's the main reason I finally decided to include this fix in the deb instead of advising users to manually modify their systems.

Did you managed to fix the issue? What was the problem?
I'm On Davinci Resolve 19 and Color Correction starts flickering after 10 minutes from DR startup.