[F] Latest 2.86 and Cover art

#1

There seem to be somekind of random bug, when MP3Tag writes cover art without extension?

Has anybody else enconounteret it?

It seems to be pretty random, approx 100 files processed, only 5 random ones had cover embedded without extension.
So instead of Cover.jpg it would export it as Cover. Also cover filetype is unknown on such circumstance.
If you switch from APEv2 to IDv2.3 it screws up cover on the same files as well.
When you operate only with IDv2.3 everything works...

Verified files themselves, everything checked out, so not sure what and why. :flushed:
Even if I retag "known good file" it sometimes screws up Cover art, so I have to remove and reimport covers on such files.

Downgraded to previous 2.85 everything works without glitches.

Aktion für Sampler mit unterordner CD1,CD2, Cover
#2

A similar problem has been reported in the German section:
Embedded covers (sometimes) have no mime type.
Could you check if this has something to do with the (new) library?
As covers are now saved in the library, it could be that some information is lost on the way.

#3

Can you reproduce it with those files? If so, I'd be happy if you can send me one of those files to analyze it locally here.

Kind regards
— Florian

#4

Yes, I can reproduce it with pretty random set of files in my collection.

Switch on read/write to APEv2 and start saving, I also have enabled column with %_cover_mimetype% and these random occurences are clearly visible there, what makes things even more interesting is that each time you save tag, this error can jump around between files... :unsure:
Now if you uncheck APEv2, save and be hold...all this has been carried over to IDv2.3 too.

Side effect of this is, that no other program except MP3Tag itself can display cover images on such files.
Also I don't currently use library feature...yet... :rolleyes:

Anyway uploaded some stuff for you: http://www43.zippyshare.com/v/aWTbEMCm/file.html

I also included some screenshots, to explain better (click to enlarge):

#5

Many thanks for reporting and including the detailed description. The issue should be fixed with the latest Development Build Mp3tag v2.86a.

Kind regards
— Florian

#6

Thank you, run a quick test (same set of files), looks good now...

#7

For me, case is closed, have processed around 250+ files now, cannot reproduce the issue anymore.

#8

Great! Thanks for testing and letting me know.

#9

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