Closed DanielDowling1 closed 3 years ago
Hmm… the "file not found" error indicates something weird going on where the filesystem itself is doing something weird. Is this on a network filesystem? If so, you could try copying the file somewhere local and fingerprinting again, which would let you "blame" the network filesystem. At that point, it's still not exactly clear how to reproduce the problem, but maybe it would indicate what's going wrong?
Thanks for your response. The folder is stored locally on the filesystem, but under "/srv" in an exported samba share. The filesystem is also encrypted with LUKS. Following your advice, I moved the files in that one album to a directory I created in my home directory (~/music), whereupon it no longer seems to be throwing the exception, so perhaps it was an issue with access privileges or something. It could be that I'd forgotten to "chown" the directory of that album when I imported it into the filesystem, although doing an "ls -lah" on the moved directory shows me as the owner with full user access but no group write access (could that be it? -- but that wouldn't explain why it worked this time around).
In any case, since I was able to get it to work, we probably can "blame" the filesystem, and close out this issue.
Huh! That is pretty odd. I think the filesystem has something to do with this, but nonetheless, it would probably be a good idea for beets to log a sensible error message instead of crashing with a traceback (which is what I assume it did, right?). So maybe the chroma
plugin just needs a little extra error handling.
Problem
Running this command in verbose (
-vv
) mode:Led to this problem:
Here's a link to the music files that trigger the bug (if relevant): 03 - 401.3 Contractor.flac https://musicbrainz.org/recording/d8a663cf-ad27-409a-9db5-ce1b605ce023 ^^ This is the only file that won't fingerprint. I can still generate a fingerprint via fpcalc from bash
Setup
My configuration (output of
beet config
) is: