DaVinci Resolve on Linux - Install issues

I've been struggling to get Resolve running under Debian Stretch. Every release since 14.0b6 have resulted in segmentation fault crash when starting. Last lines in log before crash is:

Code: Select all

[0x7f99c1945b40] | DbCommon2            | INFO  | 2017-09-02 10:06:09,831 | Creating default dblist file: /opt/resolve/configs/.dblist
[0x7f98e9ffb700] | IP                   | INFO  | 2017-09-02 10:06:09,831 | Using NVIDIA driver '375.66'
[0x7f98e9ffb700] | GPUManager           | INFO  | 2017-09-02 10:06:09,831 | Let There Be CUDA Light!
[0x7f99c1945b40] | DbCommon2            | INFO  | 2017-09-02 10:06:09,831 | Loading dblist file: /opt/resolve/configs/.dblist
[0x7f98e8ff9700] | GPUManager           | INFO  | 2017-09-02 10:06:09,831 | Initializing GPU board 0 with context thread 0
[0x7f99c1945b40] | Main                 | INFO  | 2017-09-02 10:06:09,832 | Running DaVinci Resolve Studio v14.0.0b.072 (Linux)
[0x7f99c1945b40] | IO                   | INFO  | 2017-09-02 10:06:09,832 | Using DNxHR library v2.3.3.39r

gdb gives me:

Code: Select all

Thread 53 "resolve" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffef2ffd700 (LWP 30576)]
0x00007ffedabf1218 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.375.66

Should I interpret that as a problem with the DNxHR library or that perhaps the Nvidia Driver version 375.66 is not compatible with Resolve? I'm stuck at 14.0b5 for now.

Anyone else running Debian?

EDIT: When setting "Local.GPU.Mode = OpenCL" gdb instead gives me:

Code: Select all

Thread 52 "resolve" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fff097fa700 (LWP 31176)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51


Problem with threads/forks?

Debian has huge issues with OpenCL, Cuda stuff, I couldn't make it work at all with any OpenCL apps
I had to go back to Fedora

Hello

I have DeckLink Mini monitor 4k and i screen 4k whith sound. But my mother card ave not PCI express 4.

Just PCI-e 1.4

Ave you card with PCI-e-1.4?

Hello

I have DeckLink Mini monitor 4k and i screen 4k whith sound. But my mother card ave not PCI express 4.

Just PCI-e 1.4

Ave you card with PCI-e-1.4?

I installed mine in one of those small PCI-e express slots
the card connector is much smaller but it works in one of those

Thank you for your comeback. I found converters, but also people who cut either the slot or the card.

I read that there were fewer flows. No problem on a 4k screen and a pci-e1 port?

Thank you for your comeback. I found converters, but also people who cut either the slot or the card.

I read that there were fewer flows. No problem on a 4k screen and a pci-e1 port?

not sure mine is not the 4K version
just have HD, and works ok

Debian has huge issues with OpenCL, Cuda stuff, I couldn't make it work at all with any OpenCL apps. I had to go back to Fedora

no -- i definitely can not consent. the only important requirement you have to take care of, is using the proprietary nvidea-driver ('nvidia-driver'+'nvidia-kernel-dkms' from the non-free section) and not the free ones (nouveau).

to make use of cuda and opencl support, you have have to install a few additional nvidia-* packages (nvidia-opencl-icd, nvidia-cuda-toolkit), but otherwise i can not report any significant obstacles. it works very well and reliable. even updates work as smooth and reliable as for all other software on debian machines.

Debian has huge issues with OpenCL, Cuda stuff, I couldn't make it work at all with any OpenCL apps. I had to go back to Fedora

no -- i definitely can not consent. the only important requirement you have to take care of, is using the proprietary nvidea-driver ('nvidia-driver'+'nvidia-kernel-dkms' from the non-free section) and not the free ones (nouveau).

to make use of cuda and opencl support, you have have to install a few additional nvidia-* packages (nvidia-opencl-icd, nvidia-cuda-toolkit), but otherwise i can not report any significant obstacles. it works very well and reliable. even updates work as smooth and reliable as for all other software on debian machines.

unless you have a new card, I have a GTX 1080ti which is NOT supported by the drivers on any of the debian repos

Debian has huge issues with OpenCL, Cuda stuff, I couldn't make it work at all with any OpenCL apps. I had to go back to Fedora

no -- i definitely can not consent. the only important requirement you have to take care of, is using the proprietary nvidea-driver ('nvidia-driver'+'nvidia-kernel-dkms' from the non-free section) and not the free ones (nouveau).

to make use of cuda and opencl support, you have have to install a few additional nvidia-* packages (nvidia-opencl-icd, nvidia-cuda-toolkit), but otherwise i can not report any significant obstacles. it works very well and reliable. even updates work as smooth and reliable as for all other software on debian machines.

unless you have a new card, I have a GTX 1080ti which is NOT supported by the drivers on any of the debian repos

I must agree with Martin here. I've found Debian to be very stable for GPU intensive work both for CUDA and general graphics. I run Debian on several machines here with various Nvidia GPUs. My video workstation uses GTX1080 right now with Debian Stretch and it's been rock solid up until Resolve 14.0b6 began segfaulting on start. Had to revert 14.0b5. I wonder what changed...? 12.5.6 is also running fine fine on the same machine.

I realized just now that I had not shared my updated Resolve 12.5.6 install converter script for Debian.

For those of you who are running Debian or Debian based distributions (such as Ubuntu) I have created the makeresolvedeb tool for converting the Resolve installer into a proper Debian package. makeresolvedeb supports both Studio and Lite version.
The version is selected by giving makeresolvedeb the argument "studio" or "lite".

I have tested this mainly on Debian Stretch with good results but I can take no responsibility for any problems this procedure may cause. Use at your own risk!

HOWTO - Resolve Studio
Download DaVinci_Resolve_Studio_12.5.6_Linux.zip from the BMD web site and download makeresolvedeb_12.5.6-1.sh.tar.gz from this post and place them in a new empty directory.
For example ~/resolvedeb

From a terminal, run:
cd ~/resolvedeb
unzip DaVinci_Resolve_Studio_12.5.6_Linux.zip
tar zxvf makeresolvedeb_12.5.6-1.sh.tar.gz
./makeresolvedeb_12.5.6-1.sh studio

After a while, if everything goes well, you end up with a DEB file:
davinci-resolve-studio_12.5.6-1_amd64.deb

For installation you can use dpkg:
sudo dpkg -i davinci-resolve-studio_12.5.6-1_amd64.deb

HOWTO - Resolve Lite
Download DaVinci_Resolve_12.5.6_Linux.zip from the BMD web site and download makeresolvedeb_12.5.6-1.sh.tar.gz from this post and place them in a new empty directory.
For example ~/resolvedeb

From a terminal, run:
cd ~/resolvedeb
unzip DaVinci_Resolve_12.5.6_Linux.zip
tar zxvf makeresolvedeb_12.5.6-1.sh.tar.gz
./makeresolvedeb_12.5.6-1.sh lite

After a while, if everything goes well, you end up with a DEB file:
davinci-resolve_12.5.6-1_amd64.deb

For installation you can use dpkg:
sudo dpkg -i davinci-resolve_12.5.6-1_amd64.deb

HOWTO - Uninstall
Simply remove the package "davinci-resolve-studio" (or "davinci-resolve" if you are running the "lite" version) from your system using your preferred Debian package management tool. All system modifications will be cleaned up and the only stray files left over are in the /opt/resolve/ directory. For complete removal of Resolve, also remove the /opt/resolve/ directory (rm -rf /opt/resolve)

unless you have a new card, I have a GTX 1080ti which is NOT supported by the drivers on any of the debian repos

i'm used to utilize debian an 'testing' in a rolling release mode on my private desktop just as on our production servers (mostly internet related service, where frequently updates and security patches are indispensable). the actual version of the nvida-drivers on this kind of machines is the quite recent version 375.82 -- but you could even get 381.22 ready packed for debian from the experimental branch, if you feel even more adventurous (https://tracker.debian.org/pkg/nvidia-graphics-drivers)

running debian testing as rolling release on important production infrastructure, may be seen as utterly irresponsible by some people, but i can only tell you the opposite on the basis of practical experiences managing linux clusters since the early 90ths.

you only have to watch out the periods after the official/classical releases, when the feature freeze period for new packages gets terminated again and a vast amount of deferred changes rush in. that's always a quite exciting and advantageous time. but this doesn't take very long. a few weeks later everything has calm down again.

the only advice i would give anyone adopting this approach, is utilize up-to-date setups on his one machines as well, to become more sensible and aware for changes, which may also affect the servers soon thereafter.

but it's indeed a style of continuous delivery and rolling update, which you can not realize with most other distributions, because you really need an enormous large active user base and absolute reliable software update mechanisms to handle this kind of tasks without inevitably drifting into fatal consequences.

unless you have a new card, I have a GTX 1080ti which is NOT supported by the drivers on any of the debian repos

i'm used to utilize debian an 'testing' in a rolling release mode on my private desktop just as on our production servers (mostly internet related service, where frequently updates and security patches are indispensable). the actual version of the nvida-drivers on this kind of machines is the quite recent version 375.82 -- but you could even get 381.22 ready packed for debian from the experimental branch, if you feel even more adventurous (https://tracker.debian.org/pkg/nvidia-graphics-drivers)

running debian testing as rolling release on important production infrastructure, may be seen as utterly irresponsible by some people, but i can only tell you the opposite on the basis of practical experiences managing linux clusters since the early 90ths.

you only have to watch out the periods after the official/classical releases, when the feature freeze period for new packages gets terminated again and a vast amount of deferred changes rush in. that's always a quite exciting and advantageous time. but this doesn't take very long. a few weeks later everything has calm down again.

the only advice i would give anyone adopting this approach, is utilize up-to-date setups on his one machines as well, to become more sensible and aware for changes, which may also affect the servers soon thereafter.

but it's indeed a style of continuous delivery and rolling update, which you can not realize with most other distributions, because you really need an enormous large active user base and absolute reliable software update mechanisms to handle this kind of tasks without inevitably drifting into fatal consequences.

too much variables that can break the system for a solid workstation that I need to be working constantly so, that's why I did not use debian, love Debian don't get me wrong, but they need to be more up-to-date with nvidia drivers

too much variables that can break the system for a solid workstation that I need to be working constantly so, that's why I did not use debian, love Debian don't get me wrong, but they need to be more up-to-date with nvidia drivers

that's easy written down, but what should be seen as brighter alternative?

if you want more actual software -- and this concerns not only nvidia drivers --, you simply have to update your system much more often.

debian uses a very clever chain of stages, to avoid possible troubles, which could by caused by updates:

• 'experimental' is really bleeding edge stuff, which is usually only of interest to developers preparing and testing coming software.
• 'unstable' -- also known as 'sid' ("still In development") is a much more mature set of software as maight be expected by its label. fortunately it's actively used by a lot of people, and their bug reports an feedback is one of the most important reasons, why all later stages can be used in very reliable manner.
• 'testing' include only packages, which have been in unstable for at least one ore two weeks and didn't induce horrible issues.
• 'stable' should be better seen as a kind of officially released software museum, which only sees a renovation once in a blue moon.

you may not agree, but in fact you will not simply "break your system", if you share the large community of people using the 'testing' rolling release.

if you only use the 'stable' releases, most of the stuff is often outdated and unsatisfying old, as soon as it gets published. that's IMHO really unpleasant. i'm quite sure, you also wouldn't want to work on a davici resolve release published one or two years ago.

but what's more important, if you really have to maintain important production infrastructure:
most radical changes and threatening incompatibilities are anyway introduced in a well moderated fashion in advance, if you follow the discussions in the upstream communication channels. it's much more uncomfortable to find answers for stupid bugs concerning outdated software from years ago, than to work around the little adaptation necessary in the course of continuous software updates occasionally.
that's why i deliberately prefer to stay in sync with the actual upstream software development in a reasonable way. and on debian systems, this is indeed possible in a responsible manner. you can update your machine frequently, without fear of horrible consequences.

Here is my Resolve 14.0 install converter script for Debian/Ubuntu.

For those of you who are running Debian or Debian based distributions (such as Ubuntu) I have created the makeresolvedeb tool for converting the Resolve installer into a proper Debian package. makeresolvedeb supports both Studio and Lite version.
The version is selected by giving makeresolvedeb the argument "studio" or "lite".

I have tested this mainly on Debian Stretch with good results but I can take no responsibility for any problems this procedure may cause. Use at your own risk!

HOWTO - Resolve Studio
Download DaVinci_Resolve_Studio_14.0_Linux.zip from the BMD web site and download makeresolvedeb_14.0-1.sh.tar.gz from this post and place them in a new empty directory.
For example ~/resolvedeb

From a terminal, run:
cd ~/resolvedeb
unzip DaVinci_Resolve_Studio_14.0_Linux.zip
tar zxvf makeresolvedeb_14.0-1.sh.tar.gz
./makeresolvedeb_14.0-1.sh studio

After a while, if everything goes well, you end up with a DEB file:
davinci-resolve-studio_14.0-1_amd64.deb

For installation you can use dpkg:
sudo dpkg -i davinci-resolve-studio_14.0-1_amd64.deb

HOWTO - Resolve Lite
Download DaVinci_Resolve_14.0_Linux.zip from the BMD web site and download makeresolvedeb_14.0-1.sh.tar.gz from this post and place them in a new empty directory.
For example ~/resolvedeb

From a terminal, run:
cd ~/resolvedeb
unzip DaVinci_Resolve_14.0_Linux.zip
tar zxvf makeresolvedeb_14.0-1.sh.tar.gz
./makeresolvedeb_14.0-1.sh lite

After a while, if everything goes well, you end up with a DEB file:
davinci-resolve_14.0-1_amd64.deb

For installation you can use dpkg:
sudo dpkg -i davinci-resolve_14.0-1_amd64.deb

HOWTO - Uninstall
Simply remove the package "davinci-resolve-studio" (or "davinci-resolve" if you are running the "lite" version) from your system using your preferred Debian package management tool. All system modifications will be cleaned up and the only stray files left over are in the /opt/resolve/ directory. For complete removal of Resolve, also remove the /opt/resolve/ directory (rm -rf /opt/resolve)

Monitoring and metering features
...
System Audio or connected USB audio devices still not for Linux

Please enable System Audio support/output for Linux-long over due.

Thank you

Thank you for the script and details. I ran through this on my Ubuntu 16.04 and while it installs Resolve.. when I start it nothing shows up and the icon eventually goes away. Is this all that is needed to run Resolve on Ubuntu? Or do I need to do some other things?

Also, I originally tried installing Studio (plan to buy it soon actually). But then I found your details here, and got the lite version. I cant seem to remove the icon for Resolve Studio. I did wipe out the /opt/resolve folder though. But when I tried installing your .deb lite version, it said I had Studio already installed.. which I then selected to remove (via the installer). That indicated it worked.. yet when I go to Search Computer I still see the Resolve icon there. Not sure if that may somehow be affecting me being able to run Lite.

Lastly, I do have an nVidia video card on this machine. Is it required to install nvidia drivers for resolve to work?

...Lastly, I do have an nVidia video card on this machine. Is it required to install nvidia drivers for resolve to work?

Yes, you need to uninstall and blacklist Nouveau drivers and install nVidia drivers for resolve to work on linux.

when I start it nothing shows up and the icon eventually goes away.

you should try to start it from the command line to get more useful debugging output.

Also, I originally tried installing Studio (plan to buy it soon actually). But then I found your details here, and got the lite version.

yes -- resolve for linux can't be seen as a useful and customer friendly replacement for mac and windows version, as long as it doesn't get some significant improvements.

Lastly, I do have an nVidia video card on this machine. Is it required to install nvidia drivers for resolve to work?

simple answer: YES!

and that's the case for most other professional video software on linux (nuke, mistika, flame...) as well.
the free 'nouveau' driver will not support them sufficiently.

System Audio or connected USB audio devices still not for Linux
Please enable System Audio support/output for Linux-long over due.

yes -- i have to agree! -- that's indeed an unacceptable deficiency in a final release!

I cant seem to remove the icon for Resolve Studio. I did wipe out the /opt/resolve folder though. But when I tried installing your .deb lite version, it said I had Studio already installed.. which I then selected to remove (via the installer). That indicated it worked.. yet when I go to Search Computer I still see the Resolve icon there. Not sure if that may somehow be affecting me being able to run Lite.

When Resolve is installed using my deb-package you can remove it using a package manager. It is not enough to just remove the /opt/resolve directory.

To remove the package you can use this command:
sudo apt-get remove davinci-resolve-studio (or sudo apt-get remove davinci-resolve)

When the process is complete there will probably be files left over in /opt/resolve so to completely remove Resolve delete that directory manually:
sudo rm -rf /opt/resolve

Keep in mind that this will also remove all Resolve settings and the disk based project database!

When running Ubuntu/Gnome/Mate there may be some lag when removing/changing program icons. Logout and back in again or reboot the machine to make sure the application icons and menu is updated.

Lastly, I do have an nVidia video card on this machine. Is it required to install nvidia drivers for resolve to work?

Yes. I write this directly from memory so take it with a grain of salt but to install the Nvidia driver + CUDA I think you can add the following main packages.

Debian Stretch: sudo apt-get install nvidia-driver nvidia-cuda-toolkit
Ubuntu Xenial: sudo apt-get install nvidia-375 nvidia-cuda-toolkit

You will have to unload the standard nouveau driver after install is complete. Easiest way is to reboot.

Hello,

I already have open a post but as I have no answer until now, I try to explain my problem here.

I'm using Resolve 14 on a linux laptop and for the most parts everything is ok (timelines, clips, edits, nodes).

But when I save a project, quit resolve and then come back later to work on this project, all my color corrections are lost ! Parameters for sharpen are also lost but stabilization or open fx effects are not.

Is it a bug someone already encounters or did I miss something ?

System Audio or connected USB audio devices still not for Linux
Please enable System Audio support/output for Linux-long over due.

yes -- i have to agree! -- that's indeed an unacceptable deficiency in a final release!

I agree that it's a bit strange to not have system audio. To me is sounds like a relatively simple thing to implement. However I can't see how it would be usable in any serious setup. I would only use it in a laptop-like situation anyway.

This is how I have my have my Resolve setup right now. My Resolve workstation has a Decklink SDI for output. The SDI signal is split between the edit monitor and my bigger client monitor. For audio monitoring I rely on the analog audio output from my edit monitor. This also ensures that the image and sound is in sync. All audio is then routed to an analogue mixing console. The system audio from the workstation is also routed to the mixing console even though it's not used by Resolve.

Perhaps this can spark some ideas?

resolve_setup.png (34.12 KiB) Viewed 25232 times

However I can't see how it would be usable in any serious setup.

Since the lite version is free, I think there is (going to be) a lot of not-so-serious setups. And I think the biggest complaint is not about not having system audio but rather about linux not having system audio and windows having system audio for the same (zero) price.

I think there are many potential linux users who would love to use davinci for their hobby stuff (because it is free) but they can't because of no audio. They could buy some minimal hardware to get the audio but that defeats the purpose of being free. Count me among such users, though I can (barely) work without audio...

Unable to run on debian 9 64bit, install log:

Extracting files...
tar: /usr/lib64: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
./install.sh: line 49: Exit_With_Error: command not found
resolve: no process found
Copying Resolve files...
Copying scripts...
Copying docs...
Copying Onboarding package...
Copying Onboarding package...
Copying UI resources...
Copying libraries...
Creating shortcuts...
bmdpaneld: no process found
Resolve System Updated

#ldd resolve:
libpng12.so.0 => not found

So unable to run it as libpng12.so.0 is not available anymore (only on debian 7,8 and sid)
https://packages.debian.org/search?keywords=libpng12-0
Please fix this dependency or provide some workaround.

Thanks!

concerning the removed bug report by Boris Kovalev...

I guess my post was removed because of the link to...debian website
So sad it's not working just out of the box. Sure some workaround can be found to make it work.
Appimage would be great, official .deb or just making sure it's working with top 5 stable linux distros

concerning the removed bug report by Boris Kovalev...

I guess my post was removed because of the link to...debian website

sorry -- just removed my answer as well, because i couldn't reproduce your findings in a quick test within a container.
in my test case the installer always created /usr/lib64, which unfortunately also should never happen on a debian/ubuntu/mint machine...

but again, the problem was still reported a few times (e.g. http://liftgammagain.com/forum/index.ph ... post-93646) and would be quite trivial to fix by BMDs developers.

So sad it's not working just out of the box.

yes -- and the fact, that the installer leaves a big mess behind on your machine, which will neither work nor be removable in a simple way, makes it even more annoying!

Sure some workaround can be found to make it work.

sure -- there are some private workarounds available, but this doesn't make much sense in the long run.
the suggest simple changes simply have to find their way into to official installers, to improve the situation for all affected users in advance...

Appimage would be great, official .deb or just making sure it's working with top 5 stable linux distros

the necessary changes are minimal -- it's only trivial stuff, which causes this incompatibilities -- but it simple has to be fixed.

it's really a pity, that BMD didn't even solve the most basic troubles on the linux side in this final release.

So unable to run it as libpng12.so.0 is not available anymore (only on debian 7,8 and sid)
https://packages.debian.org/search?keywords=libpng12-0
Please fix this dependency or provide some workaround.

that's a really nasty issue, because it's one of the rare cases, where you can not use resp. install an old package of the library on a newer debian system to simply fix the dependency, because the complex order of indirect symolic links in the old packages has become incompatible. therefore you have to work around in quite unusual ways...

BaldavengerOFX plugin collection has been updated. Separate collection for DR12.5 and DR14 (though persistent limited functionality with DR12.5).

I originally set up a CUDA 8.0 development environment (assuming DR14 depended on this) but the plugins failed to show up. On macOS and Windows it's CUDA 8.0, but apparently it's still CUDA 7.5 on Linux. Anyway, I rebuilt the development environment for CUDA 7.5, compiled successfully, and they now show up and work well in DR14 (all 18 plugins).

https://github.com/baldavenger/Linux-OFX/tree/master/BaldavengerOFX

i have audio issue with fedora 26 unrelated to resolve. Using an gtx970 with invidia driver... So i don't have time to be playing around with linux (reason i went back to windows ...sigh) So i want to give Resolve 14 a try in Ubuntu 17.10 since its the only Linux that installs on my ryzen 7 1700 system without me having to do hours of research to figure out why it wont install (solus works too but its not Debian based) anyhow. Has anyone gotten resolve to install on 17.10 Ubuntu? will the script posted earlier work? any dependencies that i need to install first?

However I can't see how it would be usable in any serious setup.

Since the lite version is free, I think there is (going to be) a lot of not-so-serious setups. And I think the biggest complaint is not about not having system audio but rather about linux not having system audio and windows having system audio for the same (zero) price.

I think there are many potential linux users who would love to use davinci for their hobby stuff (because it is free) but they can't because of no audio. They could buy some minimal hardware to get the audio but that defeats the purpose of being free. Count me among such users, though I can (barely) work without audio...

Fair point. I agree. BMD are missing out on this potential user group.

One interesting thing though is that it looks like the Resolve binary have some links to PulseAudio. My guess is that there is some technical issue they have to solve but they have other priorities right now.

Code: Select all

$ ldd /opt/resolve/bin/resolve | grep pulse
        libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007fa6302ab000)
        libpulsecommon-10.0.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-10.0.so (0x00007fa628d10000)


I can understand their struggle (don't get me started on PulseAudio )

Fair point. I agree. BMD are missing out on this potential user group.

sure, that's more than obvious! -- but you have to still have to respect the fact, that interested linux users are a more or less negligible minority in comparison to the more common other operating systems. i think, for BMD it's only useful to have an available linux edition for PR reasons and tender terms of some important customers, but interested individuals on the linux side are [with good reason] not seen as a significant market.

One interesting thing though is that it looks like the Resolve binary have some links to PulseAudio. My guess is that there is some technical issue they have to solve but they have other priorities right now.

what's even more significant, is the dysfunctioning switch in the config,
that's why i would simply speak of a significant BUG, not just only a postponed feature!

I can understand their struggle (don't get me started on PulseAudio )

most competitors simply utilize PortAudio to support all common linux audio output variants in an acceptable manner. It's not the perfect way to go, but it usually works sufficiently for most purposes, and it's very easy to use.

I've been struggling to get Resolve running under Debian Stretch. Every release since 14.0b6 have resulted in segmentation fault crash when starting. Last lines in log before crash is:

Code: Select all

[0x7f99c1945b40] | DbCommon2            | INFO  | 2017-09-02 10:06:09,831 | Creating default dblist file: /opt/resolve/configs/.dblist
[0x7f98e9ffb700] | IP                   | INFO  | 2017-09-02 10:06:09,831 | Using NVIDIA driver '375.66'
[0x7f98e9ffb700] | GPUManager           | INFO  | 2017-09-02 10:06:09,831 | Let There Be CUDA Light!
[0x7f99c1945b40] | DbCommon2            | INFO  | 2017-09-02 10:06:09,831 | Loading dblist file: /opt/resolve/configs/.dblist
[0x7f98e8ff9700] | GPUManager           | INFO  | 2017-09-02 10:06:09,831 | Initializing GPU board 0 with context thread 0
[0x7f99c1945b40] | Main                 | INFO  | 2017-09-02 10:06:09,832 | Running DaVinci Resolve Studio v14.0.0b.072 (Linux)
[0x7f99c1945b40] | IO                   | INFO  | 2017-09-02 10:06:09,832 | Using DNxHR library v2.3.3.39r

gdb gives me:

Code: Select all

Thread 53 "resolve" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffef2ffd700 (LWP 30576)]
0x00007ffedabf1218 in ?? () from /usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.375.66

Should I interpret that as a problem with the DNxHR library or that perhaps the Nvidia Driver version 375.66 is not compatible with Resolve? I'm stuck at 14.0b5 for now.

Anyone else running Debian?

EDIT: When setting "Local.GPU.Mode = OpenCL" gdb instead gives me:

Code: Select all

Thread 52 "resolve" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fff097fa700 (LWP 31176)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51


Problem with threads/forks?

I found a solution by some trial and error editing of config.dat

Replaced:

Code: Select all

LsManager.Count = 3

LsManager.1.Guid = 30
LsManager.1.Algo.1 = IpWindowTrackingObj

LsManager.2.Guid = 31
LsManager.2.Algo.1 = IpConvertObj
LsManager.2.Processing = Input

LsManager.3.Guid = 32
LsManager.3.Algo.1 = IpVaGPUGraphObj
LsManager.3.Processing = InputOutput


With:

Code: Select all

LsManager.Count = 2

LsManager.1.Guid = 30
LsManager.1.Algo.1 = IpWindowTrackingObj

//LsManager.2.Guid = 31
//LsManager.2.Algo.1 = IpConvertObj
//LsManager.2.Processing = Input

LsManager.2.Guid = 32
LsManager.2.Algo.1 = IpVaGPUGraphObj
LsManager.2.Processing = InputOutput

I obviously disabled something but I'm unsure what the implications might be. I've imported a few of my old projects and so far I have not found anything that is not working?!

Any Resolve devs reading this? What does this IpConvertObj thingy do?

EDIT: When Restolve has started once with these altered settings I can quit and change config.dat back to it's original state and Resolve will start again without issues.

Thanks for the script Daniel,
I was finally able to install 14.0 release on Debian 8.
Is there really no sound support? I mean without special hw?
Regards!

So it appears that MP4 use and audio is being held ransom in Resolve for linux.. I wish this was just more openly documented. Like maybe on the download page or the install instruction sheet. So that a lot of people including myself would not have to waste so much time trying to figure out why there is no sound or why no mp4 files appear in the media pool.

I don't mind spending money on good software. But if i am going to shell out 450+ dollars (sound hardware & 299 for studio version) i would like to know if there are other limitations on the Linux version. What advantages does the 450 dollars offer me that i cant get on the windows free version?

Im grateful for the software but it would be nice to be more upfront about its limitations on linux. ohh and Debian based distros are the most popular linux distros. Not sure why BMD decided to go with a RedHat distro instead. It's stuff like this that always drives me back to Windows.

Sorry Apple is just out of the question. No value there for me.

After importing an xml from fcpx I got no sound from clips in the timeline and Fairlight didn't work at all. I selected everything in the timeline and copied, made a new project, paste and voilà, everything worked fine.

I used the make deb package instead of installing it the way I've done it in the past (extra, make minor changes to their install script and be happy)... Works except I have some older RED library I installed that I forgot how I installed before and needs to be updated?!

(attached it photo)

On startup, yellow exclamation with text "Error: Decoder client version (14.0.0.078) does not match RED Decoder version (14.0.0b.067)

Somebody help jar my memory. This is a minor thing as I (currently?! probably never?!) no RED source material... BUT it would be nice to fix this start up warning!

--Doug (dx9s)

I just did the portion of their installed (which was to install into /usr/lib(64)) of the drivers effectively (I cheated and extracted --noexec --keep --target ... and then changed lib64 to lib and removed the OS level testing and ran the install.sh) ..

Fixed the RED library version conflict between previous betas... I know dirties the filesystem with libraries not tracked via deb... At least it isn't as bad as crud (left over files after uninstall) like on windows.

--Doug (dx9s)

On startup, yellow exclamation with text "Error: Decoder client version (14.0.0.078) does not match RED Decoder version (14.0.0b.067)

Somebody help jar my memory. This is a minor thing as I (currently?! probably never?!) no RED source material... BUT it would be nice to fix this start up warning!

I have seen this also. I think it can happen when you upgrade Resolve and keep the existing disk database. Right-clicking the project(s) and choosing refresh, or opening them and saving them again fixed this for me.

I took a look at the Blackmagic Desktop Video Linux driver sources and I think that for someone who has experience with ALSA and writing kernel modules it probably wouldn't be that difficult to write an audio driver module that masquerades as BMD Mini monitor and then forwards the stream to ALSA. Perhaps the ALSA loopback device could work there as the base?

Unfortunately I don't have the necessary experience, but I'm sure some programmer in the open source community would certainly be interested in taking up this kind of challenge, perhaps encouraged with some small bounty from users, should BMD not implement the functionality themselves in DR (which, of course, I think they should).

I took a look at the Blackmagic Desktop Video Linux driver sources and I think that for someone who has experience with ALSA and writing kernel modules it probably wouldn't be that difficult to write an audio driver module that masquerades as BMD Mini monitor and then forwards the stream to ALSA. Perhaps the ALSA loopback device could work there as the base?

there is no need to write kernel code to emulate decklink cards. everything could be done in user space. but it's based on ugly windows COM calling conventions and indirection, which makes it a little bit less inviting to linux hackers.
but in principle this option would be open to us as a last resort.
i'm just afraid, experienced open source enthusiasts and developers are usually not all that motivated to waste their time on developing improvements and workarounds for closed source solutions.

i'm just afraid, experienced open source enthusiasts and developers are usually not all that motivated to waste their time on developing improvements and workarounds for closed source solutions.

That's true. However, if there are no alternatives, someone is going to do it regardless. Otherwise there wouldn't be WINE or even many drivers for hardware without Linux support. And open source NLEs / color grading software just isn't there yet, if it'll ever be. I myself have trouble believing it, but some people are actually still using Cinelerra for their editing needs. I think that describes the context pretty well.

It might be that most Linux users haven't heard of Resolve. Which might be a good thing, because otherwise there would be quite a lot more messages from (Ubuntu-)people asking for those same things people have already been asking for in this thread

I have seen this also. I think it can happen when you upgrade Resolve and keep the existing disk database. Right-clicking the project(s) and choosing refresh, or opening them and saving them again fixed this for me.

I am not certain because I have not looked closely at the deb created version, but I suspect it loads the "System" libraries (normally on RHEL /usr/lib64) into the /opt/resolve path. Whereas I just changed the Blackmagic install script to ignore/skip over the RHEL testing code and change the system path to /usr/lib (which is the 64-bit directory on Ubuntu)..

I think the older "system" libraries from previous Betas where still on my system when I tried creating the deb and installing it (after MOSTLY removing the previous beta -- I didn't clean up the files it put into places outside of /opt/resolve .. I know not a clean install/remove process).

My solution was to go back to the install process (script) (slightly modified) from the RHEL world and that fixed it for me.

I have seen this also. I think it can happen when you upgrade Resolve and keep the existing disk database. Right-clicking the project(s) and choosing refresh, or opening them and saving them again fixed this for me.

I am not certain because I have not looked closely at the deb created version, but I suspect it loads the "System" libraries (normally on RHEL /usr/lib64) into the /opt/resolve path. Whereas I just changed the Blackmagic install script to ignore/skip over the RHEL testing code and change the system path to /usr/lib (which is the 64-bit directory on Ubuntu)..

I think the older "system" libraries from previous Betas where still on my system when I tried creating the deb and installing it (after MOSTLY removing the previous beta -- I didn't clean up the files it put into places outside of /opt/resolve .. I know not a clean install/remove process).

My solution was to go back to the install process (script) (slightly modified) from the RHEL world and that fixed it for me.

Yes, it's very unfortunate that BMD does not provide an uninstaller. I guess it makes sense since Resolve was originally supposed to be installed on a dedicated workstation where OS and application were generally installed together.

Regarding system wide libraries affected by Resolve, there isn't that many really. The only libraries that are installed into the system library path /usr/lib64 by the original installer are the dvpanel libraries. All other libraries are installed into /opt/resolve/libs or /opt/resolve/bin. The dvpanel library package also contain avahi, libc++, libusb and libdns if I remember correctly. This may be okay for CentOS/RH but is not something I want to just copy into the system library path on another Linux distro such as Debian or Ubuntu. My script instead places these libraries into the /opt/resolve/bin directory to avoid corrupting the OS. My main concern here is the libDaVinciPanelAPI.so library which I'm not sure how it's used. My guess is that bmdpaneld or DaVinciPanelDaemon uses it somehow but it does not show up as a linked library using ldd. If we are unlucky, that file must still be placed in the /usr/lib64 path. I don't have a panel so I can not test this and I'm actually not very keen on buying one until I know it works. Anyone running Debian or Ubuntu along with a panel and managed to get it working?

I would say the issue you had with the RED library version is normal when you upgrade Resolve. I've seen it since at least version 12 during upgrades. It goes away when you open/modify/close your projects or sometimes just opening and closing Resolve is enough. If that's not the case then there is probably conflicting files left over in /opt/resolve/libs by the previous version. If you use the deb to install/upgrade then this will not be an issue but as soon as you run the original installer then there is nothing keeping track of the installed files anymore.

I urge anyone running Debian/Ubuntu to not install programs using any method other that a proper *.deb package. That's the beauty of Debian and is one of the reasons it's very stable.
https://wiki.debian.org/DontBreakDebian

I took a look at the Blackmagic Desktop Video Linux driver sources and I think that for someone who has experience with ALSA and writing kernel modules it probably wouldn't be that difficult to write an audio driver module that masquerades as BMD Mini monitor and then forwards the stream to ALSA. Perhaps the ALSA loopback device could work there as the base?

Unfortunately I don't have the necessary experience, but I'm sure some programmer in the open source community would certainly be interested in taking up this kind of challenge, perhaps encouraged with some small bounty from users, should BMD not implement the functionality themselves in DR (which, of course, I think they should).

That's a really great point. I would certainly be willing to contribute to such a bounty. Audio is something I can't believe is left out. The lack of audio is not practical for laptop users who want to do edits while on the move. For instance, I often do rough editing on the train on my laptop, and then finish things off on my dedicated desktop system at home. Without full audio support, Resolve is not really a viable solution on Linux.

That's a really great point. I would certainly be willing to contribute to such a bounty.

from a developers point of view it looks very inefficient to work on such a kind of solution.

adding sufficient system audio support in resolve itself, wouldn't need much code. if you utilize ready made compatibility solutions (e.g. portaudio), it can be realized withe a minimum of development efforts. i think, it's realistically done within hours.

this other suggested workaround is much more complected to realize, because you have to handle very uncommon circumstances and write a crazy hack from scratch. it would also represent a kind of software, which doesn't make any sense beyond the scope of proprietary blackmagic products. the free software ecosystems wouldn't benefit from it.

and you also have to see the fact, that it will never be more than just a crazy hack to somehow bypass an intentionally established artificial limitation, which BMD in all likelihood doesn't want be ignored. they could always prevent this kind of workaround at any time quite easy by simple changes in resolve.

sure -- it would be possible to play this cat-and-mouse game with them, but IMHO it doesn't make much sense.

it looks more reasonable to me, to reflect BMDs actual decision making concerning this very significant particular topic as a classic example, which should call to mind, why this kind of products and dependency on closed source stuff in general will never by a desirable alternative to real "free" (in the sense of freedom of use and improvement) linux like solutions.

Hello,
I read that the AVCHD would be supported in version 14 under centos. I import and I read the image of my rush without problem. But no way to have sound on my rush avchd my sony cameras. I have no problem on kdenlive with the same rush.

I can listen to mp3 and other music formats thanks to the card decklink mini monitor 4k. Looking at the capture it looks like it does not recognize the codec.

capture.jpg (38.28 KiB) Viewed 24790 times

thank you to tell me if I need to add a plugin or other codec.


Best regards

[Dwaine Maggart]

Can you provide a link to a sample file that doesn't work?

That's a really great point. I would certainly be willing to contribute to such a bounty.

it looks more reasonable to me, to reflect BMDs actual decision making concerning this very significant particular topic as a classic example, which should call to mind, why this kind of products and dependency on closed source stuff in general will never by a desirable alternative to real "free" (in the sense of freedom of use and improvement) linux like solutions.

While I understand this philosophy, I think Resolve is so much ahead of open source equivalents. In fact I don't think there are any other solutions that even come near. That's why I feel we need a practical way forward with this.

While I understand this philosophy, I think Resolve is so much ahead of open source equivalents. In fact I don't think there are any other solutions that even come near. That's why I feel we need a practical way forward with this.

please don't get it as a completely stubborn and dogmatic statement, which lost any relation to reality. in fact, i'm also making compromises in real life and often handle things in a more eclectic and opportunistic manner too.

but to make it a little more plausible:
take natron as a realistic example, to analyze this kind of problem more realistically. natron is a really exciting professional grade open source compositing solution. sure -- it's quite young and in some aspects not yet as powerful and mature as nuke and fusion. but for many common tasks it's a perfect replacement of those commercial products. it's more then sufficient for daily common compositing work and i really prefer it over closed source solutions in most cases. but this personal preference is also driven by some kind of long term perspective and promises associated with this development project. if you only look on the price tag and already supported features, the commercial offers may look more attractive. and that's the real problem: if all users now switch to fusion cause of this enticing aspects, the foreseeable future for natron doesn't look very bright anymore.

but i agree with you, that the situation concerning more advanced but still affordable editing and mastering solutions for linux looks even much more worse than available options for shot based composing and color grading. that's a really unsatisfying situation, and like may others i mostly use resolve as temporary workaround to fill this gap. nevertheless i try to look out for other alternatives all the time, to keep a little bit of independence and broaden my mind. the danger, that resolve could lead straight into a very unpleasant monopolistic future, doesn't look utterly unrealistic to me. therefore i really like to practice "nuke studio" and "mistika insight" resp. "mamba fx" as well. both of them look much more open and developer friendly to me. and that's a really important aspect! resolve is so much more focused on a mass marked of almost entirely silent and passive end users, that it really doesn't give you any freedom, to extend functionality or adapt it for better cooperation with already available and well working open source tools. that's such an important limitation, that i really do not see any future for this particular application concerning a more symbiotic completion of the surrounding linux ecosystem.

so -- to draw a conclusion -- i really understand your point, but i still think, we have to keep our minds open to find more satisfaying solutions in the long run.

Can you provide a link to a sample file that doesn't work?

Hello Dwaine. The rush from my Sony A77 mark II
http://cloud.audacieuse-galerie.ch/inde ... fRt54jA1ub
Pass: davinciresolve

I have test Davinci from rush AVCHD to 2 cameras.

- Sony A77 mark II
- CANON XA25

...No sound codec.

Best regards.

I would say the issue you had with the RED library version is normal when you upgrade Resolve. I've seen it since at least version 12 during upgrades. It goes away when you open/modify/close your projects or sometimes just opening and closing Resolve is enough. If that's not the case then there is probably conflicting files left over in /opt/resolve/libs by the previous version. If you use the deb to install/upgrade then this will not be an issue but as soon as you run the original installer then there is nothing keeping track of the installed files anymore.

No... I get it (don't break). And I believe I remove /opt/resolve before trying the .deb ... I'll have to read their installer and do a better manual cleaning and retry the .deb way. The RED library warning happened each time it loaded.

Thanks for your work. As for the "shared" system libraries, I think the reason why they want it in /usr/lib(64) is because other programs expect it there (or in the ld.so.conf paths)... Probably the best solution is to put all their libraries in /opt/resolve/libs and create entry in /etc/ld.so.conf.d/99-resolve.conf and point to them (note there is a zz_i386-biarch-compat.conf in my mixed 64/32-bit system(s)) and THAT probably should be last. Probably could also make the symlinks for other libraries that might be needed (i.e. crypto or what-not) there as well?!

Not sure, I don't do this kind of thing much.

--Doug (dx9s)

UPDATE: I studied their install script a bit closer to make sure I knew what it was doing and cleaned up the barbaric non-deb method and reinstalled the .deb way and it is all good! FWIW:

Code: Select all

/usr/(lib|lib64)/lib/libavahi-client.so.3
/usr/(lib|lib64)/lib/libavahi-common.so.3
/usr/(lib|lib64)/lib/libc++.so.1
/usr/(lib|lib64)/lib/libc++abi.so.1
/usr/(lib|lib64)/lib/libdns_sd.so.1
/usr/(lib|lib64)/lib/libusb-1.0.so.0
/usr/(lib|lib64)/libDaVinciPanelAPI.so

and those libraries are now inside /opt/resolve (I believe) via your install script. I also checked up on the udev rules (75-*) to make sure they where all good. AGAIN, nice script.

I'm a new Linux user. I have the latest version of Ubuntu installed and I <think> I have the Light version of Resolve 14 installed using that script someone kindly provided.
It won't run. When I click on the icon it pulses for about 10 sec and then stops pulsing but nothing else happens.
The command nvidia-settings produces a small gui called NVIDIA X Server Settings plus in the terminal it gives an error:
"nvidia-settings could not find the registry key file blah blah blah"
Two questions:
1) Do I have the right nvidia driver installed? If not where can I get it.
2) Why would my attempt to become a super user not work? (I type su and press enter then it asks for but does not accept my password).
Cheers, Bill