$delete(tag) in Filenaming Script Ignored

tdiaz · January 5, 2020, 5:48am

I’ve got this optional Tagger Script setting place holders for editing if they’re not already set and scripting in the File Saving script that should drop any of these that were not changed from their default values.

$set(title,$if2(%title%,Title))
$set(titlesort,$if2(%titletitlesort%,%title%))
$set(subtitle,$if2(%subtitle%,Subtitle))

$set(album,$if2(%album%,Album))
$set(discsubtitle,$if2(%discsubtitle%,DiscSubtitle))
$set(albumsort,$if2(%albumsort%,%album%))

$set(artist,$if2(%artist%,Artist))
$set(albumartist,$if2(%albumartist%,%artist%))
$set(albumartistsort,$if2(%albumartistsort%,%albumartist%,%artist%))

$set(artists,$if2(%artists%,Artist;AdditionalArtists))
$set(compilation,$if2(%compilation%,1))

$set(tracknumber,$if2(%tracknumber%,1))
$set(totaltracks,$if2(%totaltracks%,1))

$set(discnumber,$if2(%discnumber%,1))
$set(totaldiscs,$if2(%totaldiscs%,1))

$set(media,$if2(%media%,Media))
$set(label,$if2(%label%,Label))
$set(catalognumber,$if2(%catalognumber%,Cat#))

$set(date,$if2(%date%,1982))
$set(originalyear,$if2(%originalyear%,1982))

$set(genre,$if2(%genre%,0))
$set(genresort,$if2(%genresort%,%genre%))

$set(releasetype,$if2(%releasetype%,album))
$set(releasestatus,$if2(%releasestatus%,official))

$set(releasecountry,$if2(%releasecountry%,US))
$set(language,$if2(%language%,eng))
$set(script,$if2(%script%,Latn))

$set(comment,$if2(%comment%,Ex Libris Audio..))

I have this in my File Saving Script (and it’s not doing anything, as in the placeholder tags are getting saved with the files)

$if($eq(%title%,Title),$delete(title)$delete(titlesort))
$if($eq(%subtitle%,Subtitle),$delete(subtitle))
$if($eq(%discsubtitle%,DiscSubtitle),$delete(discsubtitle))
$if($eq(%artists%,Artist;AdditionalArtists),$delete(artists))
$if($eq(%artistssortorder%,Artist),$delete(artistssortorder))

$if($eq(%album%,Album),$delete(album)$delete(albumsort)$delete(albumartistsort)$delete(albumartist))
$if($eq(%media%,Media),$delete(media))
$if($eq(%label%,Label),$delete(label))
$if($eq(%catalognumber%,Cat#),$delete(catalognumber))

But if I run that optional Tagger Script myself then the unused tags are marked for deletion.
(They’re red in the metadata view)

outsidecontext · January 5, 2020, 8:03am

The file naming script is just for generating the file names, you can’t use it for manipulating the saved tags.

tdiaz · January 5, 2020, 9:01am

But they’re not saved yet.

Shouldn’t be any different than any of the other conditionals that are determined from the top to the bottom of the script.

Mineo · January 5, 2020, 10:00am

Allowing the file naming script to manipulate the tags that will be saved to the files would not be useful, because the metadata box at the bottom would then not show you the metadata that’s going to end up in the tags, just some weird in-between state.

tdiaz · January 5, 2020, 10:09am

Okay, based on the UI and Function I can see where that would be counter-intuitive.

But… from a functionality standpoint… it’s as if it’s being blocked from doing so, rather than not being able to do it. So maybe I can unblock it…

outsidecontext · January 5, 2020, 10:21am

Yes, it’s intentional. The file naming is operating on a copy of the metadata, that’s done somewhere in file.py where the naming script gets run.

If the script would have side effects that wod be bad in general. In addition to hear mineo said we also currently don’t make any guarantees to when the script gets run. E.g. a currently missing feature is displaying the saved file path. To implement this the naming script needs to be executed at different points. If the naming script would have side effects that would be hard to implement.

tdiaz · January 5, 2020, 6:29pm

That came to mind when I read Mineo’s reply too. I’m just not all that interested in what the path name will be at that point. My curiosity was already satisfied with the pseudo simulation that gets done below the Naming Script editor.

That’s why I added some more variables in renaming so I had a more realistic idea what was coming out.

Otherwise, yes- I know that displaying that data now both in itemviews and metadatabox breaks the premise of everything Picard showing you is how it is now or how it will be. The ability to see the pathname data as it is when the files are first loaded into Picard is far more useful to me than than knowing what it is “going to be”. A quick look at the Status Bar answers that on a case by case basis. I can live with those metrics being stale data on the screen.

It’s why I’d like to re-arrange the status bar so that it always shows the current path/file in the center area, The dynamic messages, Ready, Loading Track Information…, et al. can go to the left as they are now and be updated as things change. But seeing the actual “Loading Cover Art ^@#$@^12323134^^53–front-w3425542” and similar messages in the status bar is pretty useless. The information does not display long enough to be interpreted. So why not just have them be a generic message like “Loading Track Information” as well?

Fetching Cover Art
Querying the MB server.
File Error #20.

Then that center area of the status bar can be like the example in the File Naming options. It can use up as much or as little space as it needs/can based on the width of the main window.