#beets

WINDOWS :(

uggh i feel so dumb about all this

so is there anybody interested in testing the py3 version of beets? you'd likely wanna make a backup first though.. just in case

probably use a separate music directory too

oh, and you should be running linux or mac.. I'm still not so sure what to do about windows yet!

jrobeson: I'm off to a festival in the next couple of hours, but I made good strides in setting up the partitions of the new disk last night, so I should be able to play with it sometime next week. :)

i was hoping to get anybody to test it before the next beets release

we're not promising anything, but it'd be nice to get anything obvious and easy fixed beforehand

i am using it for all my personal beets usage, but that's certainly a very limited subset of usages :)

Freso, i'm just a little sad, because it's been ready for testing for > 2 weeks.. and nobody has even tried it but me :(

i do plan on asking on the mailing list, but I'd really like some known saavy users to mess with it first

i should but JesseW when i see him again

jrobeson: Well, my 120 GB disk is only a couple of G's from being filled up, so I don't want to mess too much with making backups of stuff and copying stuff around until I get some more space. Which I will with the new disk.

only 120?

that's a small disk for sure

It's served me well for ~2 years.

jrobeson: I'm not really up to speed with the py3 situation, but I might give it a try this weekend. Is there anything specific I should try beside some beet import/modify/list?

why are beets imports so slow? Importing from local disk -> local disk (same ssd), -A and -W, so theoretically it shouldn't be trying to do *anything* to to the files

in 8-ish hours it's managed to import around 250 albums.

is it possible it's still trying to run the plugins, for some reason?

jdoe: AFAIK, plugin stages still run. Most (maybe all?) have an 'auto=yes|no' config option to not run them on import.

erg.

that's unintuitive. Okay, thanks, I'll give that a shot.

removing the plugin line from config.yaml entirely improves things a bit, but it's still taking much longer than copying the files and snarfing their data into the db should.

ah well. Good enough I guess.

the fact that plugins run when you configure them to run is "unintuitive"?

the throttle you are seeing is likely the musicbrainz request rate

set up a local musicbrainz mirror (use the VM) and increase the request rate?

unless you have evidence of a CPU or disk bound?

darwin: plugins running when autotagging/writing metadata is disabled is unintuitive, yes

(imo)

jdoe: writing metadata to the *files* is not the same as writing metadata to the *database*

beets is not a stateless mp3 tagger. it's a database attached to a mp3 tagger.

plugins running when writing to the files disabled makes perfect sense with this background?

yeah, I suppose. So what I'm trying to do is move a library/filestore from one machine to another. The paths will all change. Somewhere in tickets, I found the suggestion to just reimport everything as the easiest way to do it, but I'd rather not wait a day or so for that to complete. How can I copy over the existing files, and just fix the paths?

"beet move" is what you're looking fro, I'm pretty sure

and it's in the FAQ

the way that's written implies local moves

I don't want beets to move anything, I just need to fix the paths in the db.

(... or does the db not store full paths?)

if they're just relative to the base directory in config.yaml, I'm being an idiot and this is all unnecessary.

jdoe: http://beets.readthedocs.io/en/v1.3.19/faq.html...

darwin: right, so that set of bullet points describes me. The two paths are on different machines, so I can't let beets handle the move. Recreating the DB got me the pain above (since it wants to scan musicbrainz for everything)

then your option is to modify full paths, or

1) simulate the path on the source machine

2) beet move

3) move the now-correct DB

I would do the numbered process, not mess around in sqlite.

probably a good idea. I guess it stores full paths because the library doesn't care where your music is, and if you don't move/copy it, it might be outside the base dir.

welp.

jdoe, the easiest is to rename the full paths in the db :)

they aren't relative

not yet

darwin, what's wrong with messing with sqlite?

jrobeson: it is Not Supported, but otherwise it's fine? try on a copy

i have done it, worked fine

sure, it's fine, but I hesistate to recommend it to joe random (or john doe..)

what i should have done (but didn't) was try to unpickle quodlibet's db and rewrite it!

especially when there are less error-prone ways to the same result :)

darwin, what OS do you run beets on? (darwin? *heh*)

benedikt93, imports, queries, whatever you do with beets. it'd be best if you made a backup though.

I run it on linux

LINUX

darwin, what does locale say to you?

i mean `$ locale`

LANG=en_US.UTF-8

(I figured it out, heh)

do you wanna be a guinea pig?

ギーニピグ

somebody please :) <3

and now my problems with the edit plugin on windows have become clear

this would bite us anyways eventually

sampsyo, are you about?

jrobeson, darwin: thanks for your help, I'll screw around with it a bit more later. I've got backups anyway, what's the worst that can happen.