Delete Orphaned Files (Usually previously saved Cover Art)

#1

My incomplete albums are saved to a separate pathname and moved once they’re completed.

As such … I end up with many orphaned files.

02%20AM
02%20AM1024×585 175 KB

For naming Cover Art, I’m using the following:
$if($inmulti(%coverart_types%,booklet),AlbumArt/booklet,$if($eq(%coverart_maintype%,front),Cover,AlbumArt/%coverart_maintype%))

Can the Move Additional Files be configured similarly to move that whole directory, based on the file types that are in it… I’ve tried and gotten nothing from it … so… I’m presuming not.

*.pdf *.txt *.nfo *.m3u *.tif *.tiff *.afpk *.log *.mpg *.cue

#2

You cannot specifiy file types inside the AlbumArt subfolder (although supporting something like AlbumArt/*.jpg would probably be a good feature). But if you always want to move the entire AlbumArt folder you can specifiy that (*.pdf *.txt *.nfo *.m3u *.tif *.tiff *.afpk *.log *.mpg *.cue AlbumArt). Picard will then move the entire folder.

2 Likes
#3

Oh… so that entry is not just wildcard specified, it’s literal.

Seems I did try something like AlbumArt/* with no result. Handling a directory just as if it were a file? Imagine that!

Good deal!

If only the flexibility across Local Cover Art, Files to Move and Cover Art naming would support each other :wink:

'cause I’d like to figure out how to get Local Cover Art to see those files in AlbumArt too…

1 Like
#4

When you’ve got a Release that has 1GB of Artwork that it has to download again because it refuses to acknowledge what’s already there…

That poor Cover Art Archive server rack … :wink:

The functionality would be pretty negligible if we were doing cassette J-cards as a .gif but the capability has so far surpassed that now… that skipping artwork on an already tagged Album would be a Good Thing.

1 Like