In 2.84+, batch importing cover art into OGGs via an action takes forever, compared to 2.83

bug-fixed

#1

Hello,

Several months ago, I reached out to Florian via email regarding this issue, and we were in contact for a little while, but there was never any resolution. In the meantime, I've kept on using 2.83, as that's the last version where my actions still perform at normal speed. Testing a sample set of 200 OGGs, 2.83 was able to import cover art into all of them in 12 seconds. However, in 2.89, not even 10 songs were done in 10 seconds (I abandoned the test after 10-15 seconds because I knew it was going to take well over a minute.)

I'm using Windows 7 x64, but have also observed the issue on Windows 8.1 x64. All my files are on my local hard drive. I only observe this issue with OGGs.

My cover art import action in question is N:\covers\$validate(%album%-_-%albumartist%,_).??g. I mostly work with JPGs, but I deal with a few PNGs too, hence the wildcard extension. And, I have the $validate function to account for invalid characters in Windows.

Did anything change with cover art handling after 2.83? Or could it be some other change that impacted actions?

While 2.83 still serves me well enough, I would like to be able to upgrade to the newer versions. Hopefully there's a fix for my issue! Please let me know if any further info is needed. Thank you.


#2

Just some more test ideas:
a) N: is really a local hard drive? Does it change anything if you put the cover to the same directory as the *.ogg?
b) Does it change anything if you change the import action to the most direct possible mask, like
N:\covers\%album%-_-%albumartist%.jpg or even
N:\covers\revolver-_-beatles.jpg


#3

Thanks for your reply.

A) N:\ is a partition on my hard drive, and yeah, the songs I work with are all on that partition.
B) I download music in bulk, anywhere from 200-2000 songs at a time. My workflow involves importing the cover art in bulk, so, testing individual file names won't really do me any good. I can say that I do other tasks involving masks such as %album% and %albumartist%, and they're still reasonably fast, but anything involving cover art handling is super slow for me after 2.83.


#4
  • deleted -
    The source for the observed behaviour was something completely different than what I had in mind.

#5

Thanks for bringing this back to my attention. I've did a thorough code review today and was able to spot the issue.

Mp3tag v2.89a should bring back the expected performance.


#6

Thanks for the update! 2.89a has fixed my issue. I tested my same sample set of 200 songs from before, and my import action now works as fast as it does in 2.83. Thank you!


#7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.