#beets

Hey there, I have a problem/question

I'm curretly experimenting a bit, and this involves importing a song, removing it again, import again, and so on

and now i have about 10 times the same song in my music directory

beet move doesn't delete them

Oh wait, isn't there a plugin for that

when you remove do you do it with the -d flag?

Ohhhh

thanks, i did not indeed

The badfiles plugin could detect missing ones, which would be the alternative

Okay, another question, can i limit the number of items a query should return?

e.g. the most recently added one

beet ls -f '$added $album' query | sort -k1 | head -n 10

I haven't tested that, but I think it should work

polemic: yeah that works, but i need it for other commands, such as `beet play`, etc.

should've mentioned that

beet ls -f '$added $album' query | sort -k1 | head -n 10 | while read line; do beet play "$i"; done

i know i know, i'm asking for a way to do it with beets, but it doesn't seem to be possible

since beets uses a proper database, i don't think it should be too hard to enable limiting the amount of results

And btw, it would be better to do something like `beet ls added- -f '$id' | head -1 | xargs -I{} beet play id:{}

I see. I didn't know about xargs -I{}, what makes it superior?

oh

I've been using lltag (linux CLI tool) to tag and rename albums on a one-off basis as I download them. Eg. `lltag -a "Some Artist" *.mp3` and it fixes tags how I want. Without any database or library or anything. Just fix some tags on album at a time. Can I use beets CLI in a similar way?

jwr: Well, sort of! We don't have a "database-free" operation mode yet, but it's possible to get almost the same behavior with the `info` plugin.

If you `import -A` the files, you'll get a database containing the music without making any changes—then you can use `beet modify` in a similar way to tools like lltag.

(I'm not sure why I said `info` above; I really did mean the `modify` command.)

Hey

IrosTheBeggar: Hey! I was just responding to you on GitHub :)

Thanks, it's been a few years since I've used IRC

Took me a bit to get back into it

It truly is technology from the past

Still better than FB chat lol

:)

I remembered I was talking to you a while back about mStream

Anyway! First of all, I really like mStream and I think this could be a cool opportunity to leverage both projects

The projects come pretty far since then so I figured it might be worth working together since mStream fills in some features Beets is missing

Yea, I'm excited to work together

Totally

Here's one thing I don't completely understand yet, which perhaps you can help me with: how much responsibility does the current mStream server-side component have?

What do you mean by responsibility?

Does it feel more like a "dumb" database that just serves up the data over a CRUD interface, or are there specific things that the server is responsible for (e.g., transcoding, resizing images, etc.)?

Ah ok, the DB side is meant to be as thin as possible

Cool

It scrapes data from ID3 tags and dumps them into a SQLite DB

I never intended mStream to do meetadata management

The goal was to focus on the streaming, security, and client UIs

That makes sense

One other dimension seems relevant: when querying for music, how much of that is done client-side vs. server-side? (I imagine it's server-side, but you can also imagine a different design that just ships the whole DB to the client to filter)

That'sa good question. Right now it's done mostly server side

Usually the server provides a list of all artists/albums/playlists/etc and the client is responsible for organizing and searchign the data

This has been fast enough and assures the data is never stale

Ah, neat

OK, so regarding the central question you asked on the GitHub thread: it

I'm looking into adding a caching layer on the server side for some additional speed improvements

's starting to sound to me like the right thing to do would be to make a beets server plugin that works, in some way, as a "drop-in replacement" for the current mStream server

That is, since the server has relatively few responsibilities as it stands, it shouldn't be *too* hard to add the additional data that the mStream client needs

It seems like that makes a clean interface for us to collaborate on, but it lets us avoid disrupting the current way the mStream server works

Does that seem like roughly the right deduction to you too?

Sorry, I'm a little confused

Are you suggesting making a new project that stands as a drop in replacement to the mStream server with the same API scheme?

Yes, with a couple of refinements: (1) the "new project" would actually just be a fairly thin plugin that ships with beets, and (2) no need to keep the API exactly the same—maybe a slightly different design would make sense for interacting between the two projects.

(Maybe that could even become what we codify as AURA, if you remember that old project…)

Ok, that might be a bigger project that expected

Ah, sorry if I've overshot the target here :)

The API to DB part is pretty easy

sampsyo: so i do `import -A` and i get a database without making any changes. then I use the modify command to fix tags. Do I then need to care about the database at all? I want to avoid a situation where I can't fix tags on some album because the database is complaining that I moved some other album around, and etc.

But once you add things like SSL support, proper token verification, logging and caching it gets complex

Ok, so I think we should do this in two steps

OK, yes, good point—so I guess that makes it more challenging to recreate all those details in a separate server implementation

jwr: Sure! You can ignore the database and, if it ever gets out of sync with the files, just delete it and recreate it with `import -A` again.

my workflow is to usually download an album to /tmp, fix up the tags how I want them, then move the resulting files into my "real" storage location. I don't necessarily want beets to have anything to do with my files except when I'm fixing tags in /tmp.

sampsyo: cool, that's workable. is it sqlite? probably in some dot directory in my home dir?

jwr: Yep! It's ~/.config/beets/library.db by default (but you can customize it in your config)