Re: Picard 1.0 released

TheMonkofDestiny wrote:
voiceinsideyou wrote:

Sounds like you were running Picard from the installer on Vista or Windows 7. Did it work correctly after restarting Picard?

Seems to have straightened out after a restart of the OS itself.

I imagine it was because you were running from the installer, nothing to do with a restart. The installer runs as an Admin and you can't drag and drop from user-mode Explorer to an admin process on Windows Vista/7. This option will be removed from the installer in Picard 1.0.1+.

Re: Picard 1.0 released

voiceinsideyou wrote:

No, that's not how the clear + preserve works, but I don't really understand what the use case is - please give a concrete example so it's clearer. "Don't get cleared, but can be updated" is the default Picard behaviour when "clear existing tags" selected.

As far as i can tell, the current options are:

- uncheck the 'clear existing tags' -> all tags are preserved, but updated with mb-data if available
=> either the tag contains original data, or mb-data

- check the 'clear existing tags':
  - tags not defined inside the 'preserve...'-box are cleared and updated with mb-data if available
    => either that tagfield doesn't exist, or it contains mb-data
  - tags defined inside the 'preserve....'-box are not cleared, but neither updated
    => this tag simply doesn't change

So, it is not possible to use the 'clear existing tags', but keep the original data for certain tags if no mb-data is available
e.g. if you want the genre-tag updated if available, but want the original genre-tag preserved if that data is not available

I was trying to find a way around this with the scripting, but as far as i can tell that doesn't seem possible.

Re: Picard 1.0 released

voiceinsideyou wrote:

I imagine it was because you were running from the installer, nothing to do with a restart.

I didn't elaborate much on the last post but I'd closed down Picard repeatedly when it was having the issue and this was post-installer run. I needed to replace a blown outlet so I ended up shutting my entire system down and after I'd restarted everything it was working without issue.

But you're probably right in general. It's a bit baffling to me as to why despite repeated shutdowns of Picard after the upgrade and starting it normally it wasn't allowing it but it's working now and that's all that really matters.

Re: Picard 1.0 released

voiceinsideyou wrote:

A multi-select dropdown isn't actually a correct description of what I was thinking though, apologies. Possibly dual lists in another modal dialog is really what I meant, with something like the << and >> buttons to move tags to and from the 'available tags' +  'preserve me' lists; like you would have when configuring a grid's displayed columns in a decent UI.

This sounds pretty cool! Maybe it takes a little space, but definitely more user friendly than now. The thing is, the feature was on the general (and my personal) wish list for such a long time, that I just wanted to implement it somehow. I'm not a very good UI designer, so I left that for others...

Tantali wrote:

So, it is not possible to use the 'clear existing tags', but keep the original data for certain tags if no mb-data is available
e.g. if you want the genre-tag updated if available, but want the original genre-tag preserved if that data is not available.

The genre isn't an mb-tag... How are you getting the genre-tag? If it is with some plugin, maybe this should be handled by the plugin (don't overwrite the data if no data is available). I use a custom lyrics-plugin which works just fine this way (I have lyrics in the "preserve-tags").

Re: Picard 1.0 released

hrglgrmpf wrote:

The genre isn't an mb-tag... How are you getting the genre-tag? If it is with some plugin, maybe this should be handled by the plugin (don't overwrite the data if no data is available). I use a custom lyrics-plugin which works just fine this way (I have lyrics in the "preserve-tags").

Ah, I hadn't thought of the fact that the plugin can still change data even though the tag is present in the 'preserve-tags'. That was a simple solution :)

Btw1, Any chance you could share that lyrics-plugin? :)
Btw2, I think you overlooked my previous post:

Tantali wrote:

I'm using mp3's, with id3 2.4 utf-8, and I'm using the mac-version of Picard.
I tried it with the correct capitalization, but that didn't work either.
And apparently the tags aren't case-sensitive, e.g.: 'LyRics' works the same as 'lyrics', maybe this has something to do with the problem?

Re: Picard 1.0 released

Tantali wrote:

I'm using mp3's, with id3 2.4 utf-8, and I'm using the mac-version of Picard.

I tried it with the correct capitalization, but that didn't work either.
And apparently the tags aren't case-sensitive, e.g.: 'LyRics' works the same as 'lyrics', maybe this has something to do with the problem?

Right, I forget to answer that! The tags aren't case-sensitive in 1.0, but they will be case-sensitive in the next version. The comment descriptions however are case-sensitive also in 1.0. It is strange that it doesn't work (mac shouldn't be an issue). Maybe you can upload the MP3 somewhere and send me the link via PM?

Tantali wrote:

Btw1, Any chance you could share that lyrics-plugin? :)

I'm afraid not... it uses LyricWiki, which forbids screen-scraping, so I don't want to publish it. But I think there are others who do...

Re: Picard 1.0 released

hrglgrmpf wrote:

This sounds pretty cool! Maybe it takes a little space, but definitely more user friendly than now. The thing is, the feature was on the general (and my personal) wish list for such a long time, that I just wanted to implement it somehow. I'm not a very good UI designer, so I left that for others...

Completely agree with this approach - and not complaining. :-) this is how I visualised implementing the general feature for "control which tags are written to files" in general. What we have now doesn't give complete control, as Tantali's requirement notes. We should probably re-open specific JIRAs for these missing use cases. :)

hrglgrmpf wrote:
Tantali wrote:

So, it is not possible to use the 'clear existing tags', but keep the original data for certain tags if no mb-data is available
e.g. if you want the genre-tag updated if available, but want the original genre-tag preserved if that data is not available.

The genre isn't an mb-tag... How are you getting the genre-tag? If it is with some plugin, maybe this should be handled by the plugin (don't overwrite the data if no data is available). I use a custom lyrics-plugin which works just fine this way (I have lyrics in the "preserve-tags").

Well, genre is a core Picard-supported tag, and indeed it's an mb-tag if you have "use folksoonomy tags as genre" or either of the last.fm or last.fm+ plugins enabled. None of these features override the data if there's none available though, so consistently with the rest of Picard's behaviour.

I think the root problem is that "clear existing tags" applies to anything; it doesn't allow you to say which ones to clear, and which ones to not clear - but then "preserve tags" prevents Picard from being able to update an existing tag.

So, say you want to

1) clean junk tags from your files. (say "comment", legacy MusicIP tags etc) --> So you enable "clear existing tags"
2) but you don't want it to delete your current genres --> So you add "genre" to your Picard 1.0 "preserve me" tags.
3) But you do want it to update genre from MB if MB has a genre (otherwise leave the existing tag)

I don't think there's a way to achieve this right now.

a) if you disable "clear existing tags", your genres will update when MB has behaviour as expected, but you can't delete crud entries from your files
b) if you remove genre from "preserve me tags" Picard will delete your genres where MB/last.fm/whatever has no data

In conclusion, I think you'd either
* need more fine grained control over "clear existing tags" and which tags to clear
* OR "preserve" would need two options "preserve if MB has no data" vs "preserve and dont overwrite" (current behaviour - the "I dont want Picard to touch my data" option)

Make sense?

Re: Picard 1.0 released

hrglgrmpf wrote:

Right, I forget to answer that! The tags aren't case-sensitive in 1.0, but they will be case-sensitive in the next version. The comment descriptions however are case-sensitive also in 1.0. It is strange that it doesn't work (mac shouldn't be an issue). Maybe you can upload the MP3 somewhere and send me the link via PM?

Sent you a PM.
Do note that It's not an issue with a specific mp3, every single one has that problem.

hrglgrmpf wrote:
Tantali wrote:

Btw1, Any chance you could share that lyrics-plugin? :)

I'm afraid not... it uses LyricWiki, which forbids screen-scraping, so I don't want to publish it. But I think there are others who do...

Saw that one coming :)
Maybe if I have some time, I'll write one of my own.

Re: Picard 1.0 released

Tantali wrote:
hrglgrmpf wrote:
Tantali wrote:

Btw1, Any chance you could share that lyrics-plugin? :)

I'm afraid not... it uses LyricWiki, which forbids screen-scraping, so I don't want to publish it. But I think there are others who do...

Saw that one coming :)
Maybe if I have some time, I'll write one of my own.

I don’t know if LyricWiki works the same but here is such a script for utamap, you can have a look, if it can helps.

Musicbrainz forums enhancer (LA TÉLÉ FAIT GROSSIR ET NUIT À L’ÉVEIL DU CERVEAU)
☞ other cross-browser OMG MB scripts for editors and voters (♪ jesus2099)

Re: Picard 1.0 released

Tantali wrote:

Sent you a PM.
Do note that It's not an issue with a specific mp3, every single one has that problem.

Thanks! Very strange, it works perfectly for me (with comment:iTunNORM). I noticed there is another comment (chk; iTunes Art; Separate; What.CD; V0) which has no description, so it gets cleared. Maybe you can try it again, and if it doesn't work open a bug ticket in JIRA. I don't have a mac so I can't test it there...

voiceinsideyou wrote:

In conclusion, I think you'd either
* need more fine grained control over "clear existing tags" and which tags to clear
* OR "preserve" would need two options "preserve if MB has no data" vs "preserve and dont overwrite" (current behaviour - the "I dont want Picard to touch my data" option)

I actually had this implemented first (preserve if MB has no data), but thought it has no real application, so implemented the second one instead. I thought about adding a switch, but that wouldn't have made the UI any easier... :-(.

Re: Picard 1.0 released

Argh, sorry for not getting this earlier: I ran the latest git master, not 1.0!

@Tantali: It is a bug in 1.0, bitmap has committed a patch that fixes this:
https://github.com/musicbrainz/picard/c … 3f7fb5c4b4
Just update to the latest git master, and it works!

@voiceinsideyou: Bitmap also wrote a nice other feature: An auto-completer for the free-text field (suggests known tag names):
https://github.com/musicbrainz/picard/c … 2664713582
You should try it out, it's really nice!

I guess it would be nice to have 1.0.1 soon...

Re: Picard 1.0 released

hrglgrmpf wrote:

Argh, sorry for not getting this earlier: I ran the latest git master, not 1.0!

@Tantali: It is a bug in 1.0, bitmap has committed a patch that fixes this:
https://github.com/musicbrainz/picard/c … 3f7fb5c4b4
Just update to the latest git master, and it works!

Ah, that explains it, thanks :)

Now, I just noticed that artwork gets cleared as well (should have thought of that before retagging my library, thank god for backups :) )
I can't seem to find how to get it in the preserve tags... 'artwork', 'art', 'albumart' aren't the right ones apparently.

It would be handy as well to see in the bottom before-after panel whether artwork gets preserved or deleted, similar to all other tags.

Re: Picard 1.0 released

Tantali wrote:

Now, I just noticed that artwork gets cleared as well (should have thought of that before retagging my library, thank god for backups :) )
I can't seem to find how to get it in the preserve tags... 'artwork', 'art', 'albumart' aren't the right ones apparently.

It would be handy as well to see in the bottom before-after panel whether artwork gets preserved or deleted, similar to all other tags.

Yes, that doesn't work right now... ideally, you could just upload every cover you want to keep to the cover art archive, that way it would be overwritten by the same picture (or a better one!). But I know that is not really a satisfying answer. It would be great if you could open a feature request for this on http://tickets.musicbrainz.org/browse/PICARD!

Re: Picard 1.0 released

Done:
http://tickets.musicbrainz.org/browse/PICARD-257
http://tickets.musicbrainz.org/browse/PICARD-258

Re: Picard 1.0 released

Thanks, voted!

Re: Picard 1.0 released

Another thing I noted that could be a bug:
with the 'clear existing tags' selected, if I set $unset(musicip_puid) in the taggerscript, that tag doesn't get deleted.
Trying this with other tags like $unset(artist), it actually works as expected and removes the artist-tag.

Anyone an idea why it works this way?

Re: Picard 1.0 released

It's like that by design. acoustid_id and musicip_puid are always written to files even if you have "clear existing tags" set. Now that we have the user-specified "preserve tags" settings; we could probably change this behaviour to have these two tags as the default value of the "preserve tags" options; but allow users to remove even these from being preserved if they want. What do you think, hrglgrmpf?

https://github.com/musicbrainz/picard/b … le.py#L138

Re: Picard 1.0 released

http://tickets.musicbrainz.org/browse/PICARD-268