Please help us test Picard 2.7 beta

[PICARD-257] – Option to preserve artwork when selecting “clear existing tags”

At last, thank you for this!!

7 Likes

Submit Cluster as Release grabs the false Tag^^ It grabs albuminterpret instead interpret, the old Plugin “Add cluster as Release” does it right. :slight_smile:


3 Likes

Good catch. It just doesn’t submit per track artist credits at all. I added PICARD-2308 and submitted a fix.

5 Likes

Yes, it would be possible in a separate view. We considered tabs, but that’s something we don’t use anywhere else in options, instead we have different views selectable in the tree view on the left. But since we also had the feature request to have the renaming available in a separate window, and we would have splitted the scripting part from the rest of the naming options anyway (so users would need to switch between two views anyway), we went with a separate window instead. The advantage is that we can make this available independent from the options dialog.

1 Like

i perfectly understand that its easier to code with an outsourced window, i just say its more convinient to use tabs instead an extra window because foobar does it since years (and they use different selectable views aswell) and even modded components use this in foobar… or any Webbrowser out there, just imagine Webbrowsers dont use Tabs but an additional Window pops up every Time^^

That’s not at all the reason, in fact the separate window is more complex to implement. The choice of separate window instead of separate view inside options was really because it was explicitly asked for having the ability to edit the scripts independent of the options while working in the main view. The alternative to this would be to have the entire option dialog being non-modal, but this brings with it a level of complexity that we did not want to tackle for that release. Should we have non-modal options we can think again about re-integrating the script editor into the options dialog.

4 Likes

@Skeebadoo I added https://tickets.metabrainz.org/browse/PICARD-2318 for this.

Update: Sorry, that was the wrong link. Related thing, but not exactly your issue. That’s tracked at https://tickets.metabrainz.org/browse/PICARD-2319, but not yet resolved.

1 Like

A new beta is out: Picard 2.7 Beta 2 – MetaBrainz Blog

5 Likes

Anyone else having trouble with adding new file naming scripts? Whenever I try to save a new script and then want to close the window, I get the message “There are unsaved changes …” even if I haven’t made any in the meantime.

Somehow I once managed to actually add a new one, and I think that must have been with beta1, non-portable – beta1 and 2 portable as well as beta2 non-portable don’t work as I have just checked.

Note that, with beta1 non-portable, I still get the same message about unsaved changes but the script is being saved nonetheless.

Not opening a JIRA ticket since I’m currently dabbling in portable installations and the bug might be caused by me alone.

UPDATE (beta2, portable): Okay, so there’s a certain difference in behaviour between entering the file naming editor from the dropdown or from within the options dialogue, but they’re both buggy.

  1. The dropdown ‘method’ actually lets me add a new script, but does so by auto-saving, that is I don’t need to press “Save” manually, and there’s no warning on closing. However, while if I click “Save”, I get a confirmation about changes being apllied, I still get a warning on clicking “Close” even without any preceding changes. The script is added/edited/renamed successfully nonetheless.

  2. The Options ‘method’ is rather ephemeral, that is I see a new/edited/renamed script when I close the editor and can even select it, but it’s gone once I re-open the editor. Pretty confusing.

1 Like

Thanks for reporting this. I’ll take a look. Would you mind entering a ticket at https://tickets.metabrainz.org for tracking purposes? Thanks.

EDIT: Ticket added. See link in next message.

1 Like

You’re right in that the new script will be saved automatically when the script editor is closed. This is also the case when the script editor is opened from the Option settings dialog. The reason you don’t see it then is (sort of) explained below.

I can’t seem to reproduce the warning that you’re getting on closing after clicking “Save” and not making any changes. Can you provide a detailed step-by-step process that I can follow to reproduce this? If you don’t mind, please post this as a comment on the ticket (see link below)? Thanks.

I can reproduce this, and it’s actually pretty easy to explain. The change (new script) is actually being held in the pending changes, and doesn’t get written to the configuration settings until you click the “Make It So!” button. When you close the script editor and re-open it, it reads the settings from the saved configuration, and not from the pending changes. If you click “Make it So”, the new script will be saved and will appear the next time you open the script editor. I can see that this could be confusing because you’re expecting to see the new script when you re-open the script editor and it’s not there. I’ll see if we can update the code to use the pending changes when the script editor is (re-)opened from the Options settings dialog.

I also took the liberty of adding a ticket on your behalf.

4 Likes

@HumHumXX, I’ve made some changes so it you’re up for some more testing, please download and try the portable version available from the test build for my pull request. This should now retain the changes if you close and re-open the script editor while in the Options dialog. Please let me know if this (partially) addresses your concerns.

When a new script is added, it is automatically saved and shouldn’t prompt about unsaved changes unless changes are made (e.g. title, metadata or the script itself). When the Options dialog is open, the changes are saved to the pending changes, and will only be written to the configuration when you click “Make It So!”. If the Options dialog is not open, then the changes are saved directly to the configuration.

I still haven’t been able to reproduce the “unsaved changes” warning that you described earlier. I’ll keep trying as I check a few other things.


EDIT:

@HumHumXX, I think that we’ve now addressed the issues that you clarified on the PICARD-2330 ticket. Since that ticket was closed when the earlier changes were completed, I opened a new PICARD-2334 ticket to capture the additional changes.

Again, if you’re up for some more testing the test build of the portable version is available. Thanks.

4 Likes

There is I think a long standing bug when it comes to editing genres in a pane.

If you set in options Metadata > Genres > Join Multiple Genres with - if you set it to ; then all works well. Meaning, in the pane for tags, if you double click the genre and there are multiple of them separated with ; then you will get the genres parsed one per line. This is extremely useful if for example all I want to do is move an existing genre to be first, because my file naming script uses the 1st genre to make a directory let’s say.

Where the bug occurs, is if in the settings you set a different character - let’s say a comma. Then what happens in the edit pane, is that multiple genres separated by a comma will be parsed as a single value, which is obviously wrong.

Bottom line, picard has the multiple genre separation character hardcoded as ; and should instead use the value specified by user in the settings Metadata > Genres > Join Multiple Genres with.

Thank you!

Another bug: Authorization with musicbrainz.

I do not know when it occurs that picard asks for the auth. Perhaps the server expires it after few days; that would be my guess.

Well if you try to locate several albums, and picard needs auth - you log in, provide the code…but then picard keeps on asking to login for every single album it is trying to query. Perhaps these all run in different processes; that would be my guess. But there must be a semaphore or what you call it put in place that would notify the other processes that the login has already been completed to avoid the tens or hundreds of dialog boxes that must be dismissed, an then all those albums refreshed once more since they failed.

Thanks!

That’s not really a bug, and actually if you set the separator to “;” it works exactly the same. You have the choice of not using a separator, which means the genre tag will have multiple values and it will be saved as such (where the technical details on how multiple values are being stored depend on the tag format). This is the default.

Or you can choose to have all tags in a single value, separated by the configured separator. Then all the loaded values are combined into a single value separated by the separator. The input to configure this provides two default values for separators, " / " and ", ". But you can also enter anything you want. If you enter a semicolon here it will just work the same. This is mainly meant for use cases where e.g. your player software would not handle multiple separate values for the genre.

Yes, that’s a known issue, see PICARD-1638.

1 Like
2 Likes

Setting the interface language to system default makes the interface language English, in my case it should be Dutch (it worked normally in beta 2). Explicitly setting the interface language to Dutch does work. Does anyone have the same problem?

2 Likes

I’ll check. Which operating system are you running Picard on?

1 Like

Windows 10 Pro, 21H1

1 Like

Thanks a lot for the details. I have fixed that, that was a regression in the code to detect the system language on Windows.

And @mfmeulenbelt, also a huge thank your for your work on the Dutch translations!

3 Likes