Fixing OBS Studio not seeing any plugins

Guides
1

I’m writing this down as it took me forever to debug this but OBS studio on nix can be missing plugins if it’s defined more than once. For example this nix config will be missing plugins despite appearing perfectly valid:

{
     obs-studio
     (pkgs.wrapOBS {
       plugins = with pkgs.obs-studio-plugins; [
         droidcam-obs
         obs-backgroundremoval
         obs-composite-blur
       ];
     })
}

The plugins will be missing despite successfully installing as obs is defined twice here one with plugins and one without and for some reason the former takes precedence. To fix this just remove the obs-studio package and just keep the wrapOBS definition.

If someone could expand exactly what’s going on here it’d be great!

1 Like
2

The plugins will be missing despite successfully installing as obs is defined twice here one with plugins and one without and for some reason the former takes precedence.

I’m not sure what further explanation you need, since it seems like you understand what’s happening already :slightly_smiling_face: I’ll try anyway.

In “normal” FHS Linux distros, it is usually enough to install things “side-by-side”. You install OBS and it produces /usr/bin/obs-studio. You install OBS plugins and they end up somewhere in ~/.local/... or maybe /usr/lib etc. OBS knows to search these global paths, so everything works.

NixOS mostly does not conform to FHS, so we need an alternative approach. What wrapOBS does is to build a modified obs-studio package to set environment variables that point to a Nix Store directory where all of the plugins you specify can be found.

In short, obs-studio and pkgs.wrapOBS { ... } are two different packages, and they conflict when both are included in environment.systemPackages - one will take precedence over the other, since NixOS will attempt to link both at /run/current-system/sw/bin/obs-studio, and filesystems do not support multiple files with the same path.

The answer is to not install variations of the same package in the global environment twice. As for

for some reason the former takes precedence.

I’m not sure that environment.systemPackages provides any guarantees in regards to which package will take precedence when such conflicts happen.