Seeing detailed changes before applying

[henk84]

Hi

I’m looking into managing my existing audio collection with beets.
When I import (or reimport) my files, I only get to see very little information about what beets is going to do a given file or set of files.
More specifically, I’d basically like to be able to see all changes beets will perform for every file, i.e.:

• old path => new path, when moving files is enabled, especially important for me is to know whether it considers something a compilation, audiobook, soundtrack, etc and will move it to the configured folder or just the normal album folder
• every change to every tag, whether that is "deleting a comment", "adding a genre tag", or changing from "rock" to "classical rock" or whatever
• files ignored in a processed folder, because sometimes they contain notes, album art, lyrics, whatever I or some tool thought would be good to accompany the audio files and I want to know when something is just "left behind" so I can take care of it immediately and don’t have to get back to it later when the context is gone

I tried with -v but that seems to be mainly for diagnostic, in that it spews out a lot of lines about what beets is doing in terms of its logic but doesn’t really increase the amount of information about the points listed above.
Similar with --pretend: it only lists which files would be processed but not what changes it would make to them.

Am I missing some option, plugin, or approach I could be using to get this information?
If it’s not possible yet, could this be added as a feature request? Or bug? Depending on point of view, I guess this could be seen as a bug as having a --noop flag that goes through all the motions without actually performing them could be considered standard for tools that potentially perform lossy operations

Thank you very much

henk

[snejus]

Hi @henk84, regarding your second point, I had a similar issue in the beginning where I wanted more visibility in the tagging process since I wanted to understand what sort of tags were coming from each of the sources. I ended up making some adjustments in my fork and I currently have something like this:

Is this the kind of thing you're looking for?

[henk84]

Is this the kind of thing you're looking for?

Yes, pretty much!
I guess my first point (file paths) could theoretically also be included in that overview.
That would make output with long artist names and titles (such as often the case with classical music) even less likely to be readable on "small" screens, though. I figure it might already be hard as it is.
Maybe put the path in a second line?

some adjustments in my fork

I see that you are maintainer in this project here. Will those adjustments make it into an official beets release?
Or what would be the right way to get them?
Could they be a plugin that I can load into the beets version I’m currently using which is the one from debian stable?

[snejus]

Is this the kind of thing you're looking for?

Yes, pretty much! I guess my first point (file paths) could theoretically also be included in that overview.
That would make output with long artist names and titles (such as often the case with classical music) even less likely to be readable on "small" screens, though. I figure it might already be hard as it is. Maybe put the path in a second line?

Note that in the tagging stage you'd only be able to see the input file paths.

At this point the final file paths are not yet resolved, so you would not see this information. At best, it may be possible to log out where the files have been moved, after the tags have been applied. This is so because the tagging functionality is completely separate from the functionality that deals with the file system. The latter may be completely disabled with move: no, copy: no and write: no options.

some adjustments in my fork

I see that you are maintainer in this project here. Will those adjustments make it into an official beets release?

Unlikely, at least not anytime soon - this is a significant rework/change so it would require a fair bit of testing to integrate properly, and currently I can't see maintainers having capacity for something like this.

Or what would be the right way to get them?

You'd probably want to install beets from the fork directly: pip install git+https://github.com/snejus/beets. Let me know if you'd like to, and I'll double-check/verify that my changes are compatible with upstream. And you'd most likely want to drop me a message on Telegram (see my profile for the link) for support if you decide to try it out.

Could they be a plugin that I can load into the beets version

This is a very interesting idea - currently the way things are displayed in the terminal is fixed and cannot be replaced by a plugin, but I am not going to check whether it's possible to make it pluggable!