search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.06k stars 14.08k forks source link

picard records chromaprint's store path in its INI file but doesn't update that path when chromaprint changes #96199

Closed schmittlauch closed 1 year ago

schmittlauch commented 4 years ago

Describe the bug One of the main features of musicbrainz picard is being able to identify music. But this feature is not working in picard-2.3.2 because the required fpcalc binary cannot be found.

To Reproduce Steps to reproduce the behavior:

  1. nix-shell -p picard --run picard
  2. add a music file
  3. Click on "Scan"
  4. See the following error message in the terminal: E: 20:24:35,435 /nix/store/ji2f4gx9d3l68c46z72rak7lgfcg8vzp-picard-2.3.2/lib/python3.8/site-packages/picard/acoustid/__init__._on_fpcalc_error:208: Fingerprint calculator failed error = execvp: No such file or directory (0)

Notify maintainers

Metadata Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute: picard
# a list of nixos modules affected by the problem
module:

pinging @ehmry as the maintainer

peti commented 4 years ago

Picard records the path of the fpcalc executable in its ~/.config/MusicBrainz/Picard.ini file:

$ grep fpcalc ~/.config/MusicBrainz/Picard.ini
acoustid_fpcalc=/nix/store/cqkrim4iy4y8kb2xmvzpp9m1cg0vvf4j-chromaprint-1.5.0/bin/fpcalc

Now, when Chromaprint is updated or re-built, you'll get a new version of Picard, because depends on Chromaprint. That new version has the new and proper path to Chromaprint, but since your Picard.ini file still contains the old path, you'll be using the wrong store path for fpcalc. That works fine for a while, but eventually the Nix garbage collector runs and deletes the old version of Chromaprint, and then Picard will no longer be able to execute it. This is what happened on your machine.

What can you do to fix that?

  1. In Picard, choose the "Options" item in the "Options" menu. Select the "Fingerprinting" tab. Select the "Restore Defaults" button to update the "Fingerprint calculator" to the new path. It's kinda ironic that Picard knows the proper path but won't use it until you tell it to.

  2. Alternatively, install chromaprint into your $PATH and change the configured path in ~/.config/MusicBrainz/Picard.ini to fpcalc, i.e. use no explicit path for the binary so that Picard will find it through $PATH resolution.

Unfortunately, we cannot easily fix that issue in Nix. I suppose we could patch Picard to record the choice fpcalc by default and then add Chromaprint's store derivation to $PATH in the generated wrapper script.

doronbehar commented 4 years ago

If we consider patching picard, we could also patch it so it'll always use our build time given fpcalc. EDIT: Clarification: And not write that path to the config file.

schmittlauch commented 4 years ago

If considering to patch at all, maybe the patch can be designed in a way that upstream accepts it? The question is whether upstream deliberately wanted to hardcode the fpcalc path or whether that was just the quick'n'dirty way to achieve the desired outcome.

doronbehar commented 4 years ago

The question is whether upstream deliberately wanted to hardcode the fpcalc path or whether that was just the quick'n'dirty way to achieve the desired outcome.

Yea it's a bit peculiar why they did it. Another option which might be accepted upstream, would be to patch it so that it'll read an env var for the value of this config variable. So if it starts up in an environment including say PICARD_FPCALC=/my/fpcalc/bin/fpcalc, it'll use that no matter what the config says. With this patch it'd enable us to patch our expression to add that env var with the proper value to the wrapper.

stale[bot] commented 3 years ago

I marked this as stale due to inactivity. → More info

doronbehar commented 3 years ago

Still an issue.

timor commented 3 years ago

At this point, is it more important to have it running correctly under NixOS, or to have an upstream-compatible fix?

doronbehar commented 3 years ago

At this point, is it more important to have it running correctly under NixOS, or to have an upstream-compatible fix?

I think the upstream compatible idea I suggested should be useful also for OSs such as Guix and users as well. In anycase, the behavior of the program should be modified via a patch as I see it.

phw commented 1 year ago

The proper solution to this is to not configure a path to a specific fpcalc path but leave that configuration empty (the default) so Picard searches the path for fpcalc.

This works since Picard 2.5.6. I think this issue can be closed.

DeeUnderscore commented 1 year ago

We already have chromaprint in PATH in the Picard wrapper, so leaving the setting empty indeed works.

doronbehar commented 1 year ago

To be more precise, I'd conclude that since a certain Picard update, it no longer records the path to fpcalc from $PATH in Picard.ini, hence this is no longer an issue, at least if you remove the ~/.config/MusicBrainz directory and launch Picard again.