I’m just thinking out loud here - if there are no immediate plans to make it possible to tag pending edits in Picard, I wonder if there could be a way to use Picard to save things that you know you’re going to need to retag in seven days, once they pass voting. I know you could add things to a collection, but I’m thinking more of a list internal to Picard, where you could flag a release, which sets a date for it of a week later, and then whenever you come back to Picard you can push a button and it will automatically reload any releases that should be ready for tagging based on that date. Or if that’s too complicated, just save a list of releases you know you will need to retag, without worrying about the date.
Having Picard tag my pendings edits would be great!
I have a bookmarked search that shows me which releases have recently closed edits by me. It is rather more verbose than I would like, but it works reasonably well for me.
Maybe this is a bit much, but always checking your collection for updates in general would be awesome.
Because of the amount of requests and Picard not being that quick anyway I don’t think that’s feasible currently (?), but it’s definitely worth aiming for - it would make Picard and MB an amazing always-on tool (or plugin for your player) in the future.
It would need a bit of work to make it all feel integrated smoothly, but if Picard could connect to and edit a release collection and if collection subscriptions could automatically generate RSS feeds, it could probably be done with a minimum of requests: when saving a file, add its release to the collection according to the added Release MBID if it’s not already there, and on program start or in reasonable increments, query the RSS feed and check for new applied updates since the last run; display them in a popup or add them to the right pane and ask the user to load the affected files (while it would be nice to use the naming script to find them automatically – and may be possible for simple scripts – there’s too much variability in edited or non-standard fields to rely on it). Standalone recordings would be tricky, as would partial albums, and removing releases would probably have to be a manual process, but the last seems like the one that would most affect the target audience, and may not be too difficult to work around.
Given how manual it is, it may be best as a non-default feature, but it’s probably still easier than doing the same for a large collection without any aid.
Nice, though I wasn’t picturing any kind of manual clicking involved for 95% of users (if MB ever wants to break out of the tech audience).
But great idea re. using feeds.
Yeah, I knew writing that it was a bit too involved for just about anybody not already editing the database, but I figured there’s something to be said for getting a basic idea out there and seeing if other people can refine it. Glad at least one part of it may wind up helping!
To be fair, you are being practical while I am being recklessly fantastical