Release vs release group


#1

Hi!
I’ve been using beets for a few months, and I love it. I have two problems however:
one is related to the MusicBrainz structure of release group and release: each release is in a release group that contains typically reeditions or remastered versions of a release. So two releases of the same group contain pretty much the same music.
Now in my library I noticed that I have sometimes more than one occurence of a release group. Would there be a way to make an option in the duplicates plugin to check albums which may not be identical, but which are in the same release group?
Another one is related to the update command: Each time I run it, it deletes some fields like albumartist or albumartist_sort, or modifies them, a particularly random occurence is Michel-Georges Brégent https://musicbrainz.org/artist/5f3029a1-3c10-4c06-a92c-77eaad2f5b31 whose name systematically gets replaced by “Canadian Composer” (which is his disambiguation).
I am tuning a config file specifically for classical music, I wil upload it when I’m satisfied with it.
Cheers,
Dorian


#2

Hello! I’m glad things are going well for you so far.

  • For the duplicates plugin, try fiddling with the keys config option. That lets you specify the fields that are used to decide whether items are duplicates. Setting this to include mb_releasegroupid might help.
  • For the update command, flaky changes like this are not too uncommon—especially when albums have different values for album-level fields. If something seems fishy here, it would be helpful to have a bug filed with complete details so someone can reproduce the problem locally.

#3

Hi! Thanks for the advice. I am a bit lost with all the options for the importer, is there one that when I import a folder, it only imports the files that are not already in the database? Also, how do you handle coverarts? Each time I do ‘beet move -d ’ I get at least 3 errors like ‘Error: No such file or directory while moving /run/media/dorian/Volume/Musique/Musique/MusicBrainz/Schumann, Robert/Chamber Works/cover.1.jpg to /run/media/dorian/Volume/Musique/Musique/beets2/Schumann, Robert/Chamber Works/cover.jpg’ and I don’t know how to tell this idiot that these files do not exist. For music files, it’s not a problem, a ‘beet update’ notices and removes unexisting files from the database but I couldn’t find out a solution for coverarts (see https://github.com/beetbox/beets/issues/886 ). To beets’ defence, this would not happen if I didn’t regularly delete coverarts, but it seems like 'beet move -d ’ doesn’t move coverarts, or at least some of them so I leave scattered folders containing just a ‘cover.jpg’ file . So how does ‘beet move -d’ move coverarts?
Cheers,
Dorian


#4

No; the closest thing is the incremental option, which records music you’ve already imported.

Have you tried the -a flag, which moves entire albums (including their cover art)?


#5

Thanks for the -a flag, I’m trying it out right now. Does it also move singletons?


#6

Ok, I tried fiddling with the -a flag, and the keys config option does what I want. However, I have a huge turn-off that is the error messages like Error: No such file or directory while moving /run/media/41715435-89cb-4e8e-b531-40708180c365/Musique/Dump/dump to /run/media/dorian/41715435-89cb-4e8e-b531-40708180c365/Musique/beets/Mozart, Wolfgang Amadeus; Academy of St. Martin in The Fields, Marriner, Neville, Sir/The Late Symphonies 21-41 (0000)/cover that I constantly get (at least 5 for each beet move that I have to correct somehow by using beet fetchart -f, and that works only for some albums, for others I simply have no clue how to deal with it (related to https://github.com/beetbox/beets/issues/886 ). This problem comes back constantly and I would like there to be a solution to get around it somehow. I would like to just remove all coverarts and more generally all files that are not music files (lyrics, coverarts etc) so that I just have the plain music files. For those, a beet update works to detect deleted files and remove them in the database. Is there a way to do that else than remove the database file and restart everything from scratch? I’m having so many problems that I would be willing to take this path even if that means wasting my whole weekend on this to retag my 3 versions of my database but I will do this only if there is no other solution.


#7

We don’t currently have a way to remove (references to) cover art files. That would certainly be useful, though, if you’re interested in helping out!

This issue might be relevant:
https://github.com/beetbox/beets/issues/559


#8

I will have to learn what sql is and how to deal with it. As a temporary solution, it turns out that reimporting an album removes the error about the missing coverart. I still have two pull requests that I would like to submit once and for all before.


#9

Hi! I’m fuzzling with the -i flag of the importer, how does it work exactly? Does he keep a trace of the files that have already been imported? Does he only keeps trace of the files that have been imported with the -i flag (or incremental: yes in the config)? From my personal experience, if anything it’s the second, but I’m still confused. Right now I’m reimporting my collection using incremental: yes but I cannot make a straight run through my collection, some albums need to be taken care of separately because they are too big (>700 tracks), however, if I import them separately with the -i flag they are not skipped when I import everything (where every already imported directory should be skipped). Additionally, does -i keep track of the files or of the directories? If I add a file to a directory that has been imported, will it be detected?


#10

Yep, that’s exactly how it works!

I’m pretty sure it’s the directories in album mode, and files in singleton mode.

Thanks for digging! I know I ask for your help a lot (and you have been very helpful), but if you come to any conclusions, would you please consider making additions to the documentation? Maybe you can answer these questions for future users definitively.


#11

Hi! I’m trying to get a usable setup for all my music (get all the tags I need and a protocol for synching my music up). Once it is done, I will document it on a separate post and add the corresponding infos to the documentation.
My main problem currently is to sync up my several libraries, what I thought of was to use the same sorting strategy for all library and than just do a cp -nr (copy non-clobber recursive) on my library, then import the library with incremental so that he imports only the files that have been added, but if for albums he only remembers the folders and not the files it doesn’t work.
About contributing: Is there anything wrong with https://github.com/beetbox/beets/pull/2563 or didn’t you just find the time to look at it into detail?

I know I ask for your help a lot

I feel like I’m asking for your help a lot, is it a typo?


#12

So far the best I can come up with is to cp -nr onle library onto another, then beet move -d move the library I copied on and then what remains are the files in one library and not the other, so I can import them. However, this is quite cumbersome (40000 files take quite some time to move) and to do it efficiently you need to name your files somehow like albumartist/album/tracknumber - title to be able to import the new files efficiently. So for a sync you need to
change the paths in the config file
move the first library to fit to the new paths
change the library; move the second library
cp -nr the first library onto the second
move the second with beet move -d
import what’s remaining in the directory into the second library
move the second library back in place
do the same the other way to import to the first what is only in the second
move both libraries back to their original paths

So this is horribly long and cumbersome if like me you have like 40 000 files, I am eager of any way to do this more efficiently.


#13

Basically I have a big music collection and I would like to keep it secure, so I have it on 2 harddisks and I want to keep them synched (as a protection against bitflips for example). Maybe a RAID is the better solution for this kind of cases.


#14

Thanks for the reminder; I didn’t realize it was in a ready state.

It’s mutual—you’ve been very helpful in contributing back.

Syncing is certainly a hard problem! One thing you might consider is an off-the-shelf backup-like tool—for example, using rsync to incrementally make a copy of your files could be productive.


#15

After trying it out: yes, -i keeps track of directories (except in singleton mode) which makes it unsuitable for syncing up as far as it’s not about adding albums but adding missing files to already-present albums. rsync is fine for backups but I would like to use beets so to sync the library files as well, and rsync cannot do that. However after thinking about it syncing is not that of an issue right now.