Import Cover from file fails but shows no error

mista_j · May 3, 2025, 9:49pm

I can't figure this out for the life of me.

I have an action that attempts to import album art from 1 of two places & with 1 of two extensions
• Either from my "Database" folder or from an album artist's "Album" Folder
• JPG or PNG

When I run this action I've noticed I often can't get the back cover to import from the Database folder. If I move that art to the album artists folder, it imports no problem

If I run a quick action I CAN get the art to import as a back cover from the Database folder

The kicker is when I attempt my action & read the error message MP3TAG does not say that it cannot access my album art file. It knows the file exists in my Database folder it just doesn't import it.

In short This import here works on its own but not within my action group
C:\Users\USER\Music\Album Covers\Database%BC_Filename%.png

Here is my full action
Album Art + &Description# Album Art (&Import).mta (3.9 KB)

Please someone tell me I'm doing something wrong, I'm going mad

ohrenkino · May 3, 2025, 10:05pm

If I run the action group, I get (naturally) a number of error messages:

The only thing I could think of: there is a space in the path.
Instead of
C:\Users\USER\Music\Album Covers\Database%BC_Filename%.png
try
"C:\Users\USER\Music\Album Covers\Database"%BC_Filename%.png
So that the part with space characters is enclosed in "

mista_j · May 3, 2025, 10:14pm

Using the Double quote changed the whole file path so that gave me an error.
Encasing the path just before the album art filename in single quotes ' ' gave me the same results, other errors but MP3TAG still knows my particular file is present

The other errors are expected failures to import as the file is only actually in one spot & of one filetype / extension. I usually keep error messages off unless my action fails then I switch them back on to take a peak & see what the problem is but this time...I couldn't find one lol

If you recreate my action or pull that mta file into notepad & replace the path "User portion" does it work for you?

ohrenkino · May 4, 2025, 6:32am

No. In the end I get an empty filename as %bc_filename% is not present.

mista_j · May 4, 2025, 6:13pm

The issue is more with the import. If you create an action like this

Import cover from file: Path1_Filename1.jpg
Import cover from file: Path1_Filename1.png
Import cover from file: Path1_Filename2.jpg
Import cover from file: Path1_Filename2.jpg

Import cover from file: Path2_Filename1.jpg
Import cover from file: Path2_Filename1.png
Import cover from file: Path2_Filename2.jpg
Import cover from file: Path2_Filename2.jpg

I'm curious if the problem can be recreated. If so we have a consistent issue that may be due to the consecutive import attempts. If not then It's just something on my end likely to do with my file path. for now i've just been moving files to Path 2 & it works there which is baffling but hey

ohrenkino · May 4, 2025, 6:25pm

I created the following action group:

The path is an absolute one.
The target file is in a different folder and now has 7 embedded pictures as 6 have been added to the existing one.
So it looks ok to me over here.

mista_j · May 4, 2025, 6:44pm

I'll play around with it a bit more but im stumped

Running the import action on its own is flawless but copying that action into the group causes a failure to import but not a failure to locate the file.

I'm going to try cloning that action group & deleting individual actions one by one from the top / bottom & seeing if anything changes

mista_j · May 4, 2025, 8:10pm

Well the lore continues

So this line is causing the problem

What is still confusing is this string is Formatting the value of %BIN% Which should have 0 bearing on my import from the "Database" folder as %BIN% is not included in the filename or file path when I'm looking to import from the "Database" folder.

So how is this:
C:\Users\USER\Music\Album Covers\Database%BC_Filename%.png

Being affected by this string setting the value of %BIN%
$ifgreater($strstr($REPLACE(%AlbumArtist%,Ft.,|,&,|,',',|),|),0,$cutRight($REPLACE(%AlbumArtist%,Ft.,|,&,|,',',|),$sub($len($REPLACE(%AlbumArtist%,Ft.,|,&,|,',',|)),$sub($strchr($REPLACE(%AlbumArtist%,Ft.,|,&,|,',',|),|),2))),%AlbumArtist%)

mista_j · May 5, 2025, 5:24pm

I figured it out, It's stupid

Its my order or importing

Context

Path 1 = Root Folder "Database"
Path 2 = 2 Levels deep into Database: >Album Artist>Album

Path two is my final archival folder.

This action in total does the following:

Export Current Album Art to a "Recycle Bin" (Spare Folder)
Formulate Filenames for Front & Back Covers
Import & embed Front & Back Covers from either Path 1 or 2
Formulate my Archival Folder's Path (Path 2)
Export Front & Back Covers to an Archive Folder (Path 2) Which is based on the Album Artist & Album name (all characters that cannot be in filenames on Windows are Removed)

The Problem:
My order of operations:

FrontCover - Path 1 - PNG
FrontCover - Path 1 - JPG
BackCover - Path 1 - PNG
BackCover - Path 1 - JPG

FrontCover - Path 2 - PNG
FrontCover - Path 2 - JPG
BackCover - Path 2 - PNG
BackCover - Path 2 - JPG

Solution 1:
New Order of Operations:

FrontCover - Path 1 - PNG
FrontCover - Path 1 - JPG
FrontCover - Path 2 - PNG
FrontCover - Path 2 - JPG

BackCover - Path 1 - PNG
BackCover - Path 1 - JPG
BackCover - Path 2 - PNG
BackCover - Path 2 - JPG

WHY

My import of front cover replaces the current Art, the import of back covers does not replace current art.

In my previous order the Back cover art was getting embedded VIA path 1 in (STEP 1) The Front Cover art was being embedded via Path 2 in (STEP 2) so the embedding of the Front cover in (STEP 2) was completely negating progress made in (Step 1).

I've been using the action for almost a year & a half & it was working flawlessly.

This was probably because when I tag new tracks the album arts, front & back are always in Path 1

When I tagged older tracks that already have their art Archived the covers are always in Path 2

Solution 2:

Alternatively I could have simply removed the setting so that when front covers import they are not replacing the current image.

In my case this would mean I'd need to delete the current art before or after running this action otherwise it would still be there as an extra cover afterwards

MP3TAG: ∞
ME: 1

I had a similar blunder a while back...

If you tried to export tags to a .txt file & in the same action group you attempt to import that .txt file your action will FAIL.

MP3TAG will run through the Steps of your action group faster than the time it takes for that .txt file to "materialize" & be recognizable on your Computer. So at the instant MP3TAG goes to import that .txt file it DOES NOT YET EXIST & therefore cannot be imported.

Simple fix, split up your action groups

Sorry for the wasted time...I pray this helps some poor frustrated soul one day