When a release has the Front cover art also marked as Booklet Picard will mark the release as having updated info or whatever this ICON is supposed to mean.
I can save it then reopen Picard and drop the release into it and again it marks this way again and shows all files need to be saved. It does this every time any release is loaded into the right pane with cover-art marked as a front, booklet. Screenshots below. Does anyone else experience this problem?
I voted but it doesn’t appear to be an issue worth the developers time. No real point in continuing to invest the time in scanning and uploading to not even be able to use the finished product. I can simply change the settings of the last photoshop droplet to resize as 1200 x 1200 jpeg and add cover-art during the ripping process and not make a dozen scans for every CD. dbpoweramp also does not assign multiple incorrect ISRCs that cause problems with my uploader and rights reporting.
Developers for Picard are all doing so on a volunteer basis. They often pop in work on Picard stuff for a day or maybe a couple of days and then disappear back into the realm of RL. We were blessed to have @samj1912 really dig into Picard a while back, but sadly, even he eventually had to succumb to outside-of-MeB forces. It’s not that the issue isn’t worthy of developers’ time… it’s just that there’s not a whole lot of time to go around.
One of the people working on Picard wrote a lengthy response on the linked issues where he says “i’m not sure what is the solution to this”. Picard is an open source community project: if you wish to help move the issue along, read over (all) the comments written on the ticket. If you have any useful feedback/comments, then please do post them there—this in turn will hopefully help developers figure out a way to best deal with this case.
Maybe I don’t understand your initial issue, but isn’t the issue entirely cosmetic in that Picard just marks the release in its interface as having changed? The cover art is still downloaded and used/usable, no? And by you uploading it to the Cover Art Archive, it is now also usable by lots and lots of other people around the world?
I mean no disrespect here, but that seems to be a fairly drastic reaction to a bug that, at worst, causes some files to be saved when they didn’t really need to be.
This is along the lines of what I meant but you said it much better. I did read all the comments and came to the conclusion it is not an issue worthy of the limited volunteered time. I truly do appreciate the massive amount of work that makes this database’s user interface awesome.
No insolence taken (username joke). The issue it causes is when I reload my core database to look for changes I run the plugin to remove gold albums and then delete the file from a cloud music server then remove the file from a server that removes it from some jukeboxes then give it a night so everything syncs then I resave the core FLAC file with the updated information scrub incorrect ISRCs and then Picard saves it to a folder that gets it reencoded to different file types and sends them on their way back out.
The process and its lack of efficiency are my problems I’m working on. This little annoyance for 99.9% of the users is a big annoyance for me. But I’m sure there is a way for me to fix it with some scripting, just got to start learning how to do that with Picard. You are right I was being a whiny little #^$%@ who hadn’t had a cup of coffee and a smoke yet.
Again, that is not the conclusion I come to from that discussion. @zas literally says he doesn’t know how to fix the issue. We could throw 100s of coders/coding hours on it, but as long as the fix remains undefined, they’re just going to waste their time. The best way to progress this issue is by helping to shape up a logic flow/algorithm that handles this issue while still addressing the concerns @zas put forward so Picard continues to work as expected in other situations. I left 5¢ on the ticket, but not sure if that’s enough or useful to progress on it.
Thanks a lot for your insights. FYI, we have a fix for it ready which will be in the next release (which is to be expected soon.
This issue had been on my personal list of annoyances, which is already a good thing for any issue because it makes it more likely for me to sit down and investigate it. However for me this really was just a small visual issue so not very high on the priority list. There are so many things we want to see improved in Picard. And actually we have still other cases where the save status gets indicated wrongly, this issue as a whole is way more complex than it may seem. But you explaining you use case and how this issue affects it helped a lot, thanks for this. So at least this specific case is fixed now.
