Uploaded image for project: 'Picard'
  1. Picard
  2. PICARD-259

Make file-specific variables and metadata available to tagger script

XMLWordPrintable

    • Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Normal Normal
    • 2.5.0b1
    • 1.0
    • Scripting
    • None

      There are many individual tickets for allowing the technical variables in scripting, but they all are blocked by the (current) design of tagger scripting - that is it operates on metadata retrieved from elsewhere (+ plugins) and so at the point it runs, the files linked to that abstract metadata are irrelevant. Doing it this way does have many advantages in simplicity and clarity.

      There are technical problems with implementing this such as:

      • if multiple files are currently linked to an abstract track, what do you do? Ignore them both? How do you "merge" the metadata?
      • you would then have to re-evaluate tagger script every time a file is moved/linked. Will this be a problem? (performance? complexity/predictability?)
      • how about the relationship with plugins - if you re-evaluate the tagger script every time will this lead to some inconsistencies with the plugin "lifecycle"?

        1.
        		 Allow applying tagger scripts to existing metadata (not just MB metadata) Sub-task Closed Calvin Walton
        2.
        		 make %_extension% available in TaggerScript Sub-task Closed Calvin Walton
        3.
        		 Make _bitrate (and other bitrate variables, when/if added) available to tagger script Sub-task Closed Calvin Walton

          [PICARD-259] Make file-specific variables and metadata available to tagger script

          GitHub Bot added a comment -

          See code changes in pull request #1631 submitted by phw.

          GitHub Bot added a comment - See code changes in pull request #1631 submitted by phw .

          Calvin Walton added a comment -

          Sadly, I haven't had any time to look into the bugs that caused this feature to be reverted. For the time being, I'm also continuing to use an older version of picard.

          Calvin Walton added a comment - Sadly, I haven't had any time to look into the bugs that caused this feature to be reverted. For the time being, I'm also continuing to use an older version of picard.

          Steve Martin added a comment -

          Ugh, I updated many of my scripts to use these new capabilities and now I assume if I upgrade to the latest version of Picard they will be broken. Is it the plan to bring this functionality back soon? I will sit out a few updates in hope...

          Steve Martin added a comment - Ugh, I updated many of my scripts to use these new capabilities and now I assume if I upgrade to the latest version of Picard they will be broken. Is it the plan to bring this functionality back soon? I will sit out a few updates in hope...

          Sambhav Kothari added a comment -

          Reopened with the merge of https://github.com/metabrainz/picard/pull/913 until related issues are solved.

          Sambhav Kothari added a comment - Reopened with the merge of https://github.com/metabrainz/picard/pull/913 until related issues are solved.

          Calvin Walton added a comment -

          Currently in review at https://github.com/musicbrainz/picard/pull/170

          Calvin Walton added a comment - Currently in review at https://github.com/musicbrainz/picard/pull/170

          Calvin Walton added a comment -

          That mostly means that I haven't tested it with any picard plugins, so I'm not sure what the behaviour would be. I think everything will still work as-is with the current patch.

          Calvin Walton added a comment - That mostly means that I haven't tested it with any picard plugins, so I'm not sure what the behaviour would be. I think everything will still work as-is with the current patch.

          Zas added a comment -

          As "it might break interaction with picard plugins", perhaps we should upgrade plugins API version ?

          Zas added a comment - As "it might break interaction with picard plugins", perhaps we should upgrade plugins API version ?

          Zas added a comment -

          PR: https://github.com/musicbrainz/picard/pull/170

          Zas added a comment - PR: https://github.com/musicbrainz/picard/pull/170

          Calvin Walton added a comment -

          I have a very experimental branch for this up at https://github.com/kepstin/picard/compare/picard-259

          I'd appreciate comments on it; it fixes the issue for my use case. However, it might break interaction with picard plugins, since the tagger script evaluation now happens at a different point, and is run on the file metadata rather than the track/album metadata.

          Calvin Walton added a comment - I have a very experimental branch for this up at https://github.com/kepstin/picard/compare/picard-259 I'd appreciate comments on it; it fixes the issue for my use case. However, it might break interaction with picard plugins, since the tagger script evaluation now happens at a different point, and is run on the file metadata rather than the track/album metadata.

          Michael Wiencek added a comment -

          Regarding technical problem #1, in PICARD-83 I suggested altogether removing the "feature" of being able to match >1 files to a track, and instead adding some kind of duplicate-files cluster. I don't know how popular of an idea that is.

          Michael Wiencek added a comment - Regarding technical problem #1, in PICARD-83 I suggested altogether removing the "feature" of being able to match >1 files to a track, and instead adding some kind of duplicate-files cluster. I don't know how popular of an idea that is.

            outsidecontext Philipp Wolfer
            voiceinsideyou voiceinsideyou
            Votes:
            7 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:

                Version Package
                2.5.0b1