[dangravell]

Nice approach. I'm the developer of https://www.blisshq.com/ and other projects. The key insight there is that managing large collections is easier with rules applied continuously, rather than thoughts-in-the-moment "I'll run a batch command with a tagger".

You could have the rules encoded in your config (or the DB) and apply those. For example, someone may want a "portable mirror" of their gold library, but that means transcoding AND chopping the embedded album art to size (or maybe their player has max resolutions).

I guess having the DB means you could potentially version control the metadata changes?

[sohex]

Oh very nice, bliss looks pretty slick. I see musefs as being kind of an unglamorous middle man layer that ultimately just has one job, separate the metadata handling from the backing files.

Since the DB is the source of truth you can absolutely version your metadata. The portable mirror use case is definitely one that people run into, but I see musefs more enabling that than handling it directly. It’d be really easy to handle transcoding and art handling just pointing at a musefs mount or by having a plugin for whatever you’re using handle it.

I definitely agree that continuous automation is the way to go, personally I set it up differently though. Whenever I have a new album in my music folder it gets detected and then beets imports it and museFS autoscans it. That handles 99% of cases silently in the background and the other 1% are the ones I’d want surfaced to make a judgement call on anyway.

[dangravell]

That's what I mean by continuous automation, using rules (constraints) to dictate how the library is managed (in your case, what beets does, e.g. auto download art of the given size and format, constrain the genre etc etc).