#beets

sampsyo: i mean does scrub support selecting files?

Yes, it takes a query parameter like most other commands.

Do the docs not say that?

good. i suck at regex. i'll try to figure it out

Cool, good luck :)

axion: What's the problem with regex?

maybe something like "^[W-Zw-z].*" ?

lemme try

i thought i tried something similar

beet ls "^[W-Zw-z].*" returns nothing

kpj: ^

axion: that's because that's not a regex query; you need to say something like beet ls field::regex

(see the query page in the docs)

ok i got it, thanks guys

sampsyo: still there?

sampsyo: i did a beet update after my partial scrub and it worked. just finished the regex scrub and went to update: http://pastebin.com/raw.php?i=E9Ftmhgn

axion: That's a bug; thanks for the report. I'll look into it.

sampsyo: ok. in the meantime i'm doing -AWC again :D

Fwiw, an update after scrub should be unnecessary

Since scrub does not affect tags that beets tracks

sampsyo: interestingly only files that were scrubbed are seen by update then

Not sure if I get it; are you saying beets loses track of non-scrubbed files?

sampsyo: all i'm saying is say i do "beet scrub [some regex]"...

then a generic "beet update" will only display output for the files filtered through the scrub.

with something like "disctitle => none"

and a subsequent update produces no output

so it must be doing something, no?

Ah, cool, yes -- it's doing something, but just barely

Replacing the empty string with a null value, which is unimportant and should probably be skipped

Just unpleasant implementation details -- nothing substantial gained

makes me wonder why update failed then :)

I can explain more if you're interested, but long story short, it doesn't do much

with a python dictionary error on an _important_ field

ok

no prob

It's just a cleanup that's part of the update when *any* field changes

The albumartist field is adjusted in the case when it's missing to match the majority artist

sampsyo: i think i found another bug (another traceback) if you're interested

axion: I <3 tracebacks

sampsyo: give me 5 mins. in the middle of a beets operation and db is locked

Cool, take your time

sampsyo: http://pastebin.com/raw.php?i=3LEymZp3

there was a stray file called 00.mp3 in the root of my music dir. i removed it from disk and db with rm -d. and ran beet fetchart again and got a different traceback, but i cant produce that one at the moment

that stray file is the " - " result though in that traceback

actually the traceback is identical...i thought it was different but its not

i could try beets-git version to be sure it wasnt fixed recently, my distro is using 1.3.0

gonna try a 'beet mv' first

heh that traceback probably isnt very helpful

other than it seems to be a filesystem/db inconsistency

axion: Sorry, I was already asleep ;-)

btw, is there any way to remove duplicates from the database?

axion: Which command did you use in the end?

sampsyo: If you don't mind, could you explain more?:-)

kpj: have you looked at the duplicates plugin?

and of course -- but about what in particular?

sampsyo: Uh, never heard about that, I'll check it out!

sampsyo: Can I somehow alter the way duplicates are found? The doc doesn't say so (I think) and "beet duplicates" does not find all of them.

What do you have in mind? You can always hack the plugin to suit your needs.

I have a couple of obvious duplicates (same title, artist, etc) but beet does not detect them

it uses MBIDs

can beet print the detected MBID for some file?

beet ls -f $

sorry

beet ls -f '$mb_trackid' <your query here>

It only returns an empty string

I noticed something weird though

then the track doesn't have an MBID

First path: /Compilations/Album/Song.mp3

Second path: /Compilations/Album 4540/Song.mp3

Is this the result of the autotagging?

beets tries to disambiguate paths for identically-named albums: https://beets.readthedocs.org/en/v1.3.0/referen...

so I have to use "beet move" for a bit