Setatte META coverart only works on first file?

I want to strip the coverart from mp3s, so I used SETATTR META COVERART

Works fine, but only works on the first file?
So I tried adding (f!).
Same result.
Used doptest to make sure all the files are being parsed, they are.
Came here, did a search, saw a post from Leo on a similar thing where he said to use

Select DESELECTNOMATCH PATTERN="*.mp3"
SetAttr META coverart

Did that, same result, it only deletes the cover art from the first selected file.

It is broken, or is my brain broken (again!) :slight_smile:

ta

Using 11.13 if that matters.

I suspect it is working, but thumbnail caching combined with Preferences / File Operations / Metadata / Update last modified file dates when setting metadata inside files being off is making it look like it hasn't done anything.

If you copy the files after the change, do they still have the cover art?

It could also be something particular about certain files and the way they are tagged which is causing the problem (or file permissions etc.).

11.13 is almost a year old, too.

Leo: 1, Gus: 0

You are right. This seems to only happen on certain files, because if I try it on ones that I just did (where opus is adding the cover art) it works, so it would appear that only certain files behave this way.

11.13, only a year! Opus is the only program I EVER update. I just hate rebooting so much, it takes forever, stupid USB3 bugs means I have to uninstall drivers and then re plug and play them before they work. I have a scheduled power outtage soon, I'll update then, promise!

I'll see if I can find some more that won't work and play with that setting as well as copying them to force a refresh, just to see if I can sus why this happened.

Thanks Leo.

:slight_smile:

Update:

I just went back and had a look at some earlier dirs I was doing this to. Found one. The command definitely doesn't work on these files, it does the first file, and not the rest. If you repeatedly run the command on the files, the topmost one will get the art deleted, the rest remain untouched. I can give you the files if you want? Copying makes no difference, the copied files contain the cover art. Toggling that pref you mentioned made no difference in this case.

Actually, my comment re topmost isn't clear. If you run the command repeatedly on say 10 files, with all 10 selected each time, the first pass will do file 1, the second will do file 2, the third, file 3 and so on.

It sounds like the operation is failing/aborting after one file for some reason, which could be due to something in the files themselves. If you want to send a few tests/examples, we can take a look.

It's probably best to do that after updating to the current version, in case the problem has already been fixed.

oki doki :slight_smile:

Nup, same result after updating. How do you want the files? There is something weird though... rather than send 100s of megs of mp3s, I thought I could send one. So I got a file from a set that doesn't work, ctrl-c, then made a bunch of ctrl-v copies. Thing is, this DOES work. The art is stripped from them all, not just the first one. I will do some playing and see if I can pin this down. Maybe it is the naming, which is...

originalfilename.mp3

then...

originalfilename - Copy.mp3
originalfilename - Copy (2).mp3
originalfilename - Copy (3).mp3

...and so on.

Just remembered this thread, and wasn't sure if you were still trying things out, or were waiting for me to say how to send the files.

If you want to send the files, you could probably email them directly to leo@gpsoft.com.au if the total size isn't huge. Alternatively, share them via dropbox or similar and email me a link.

Of course, if you're still investigating and want to finish that before sending stuff, carry on. :slight_smile:

Sent

Spelling of commands on forums is not indicative of Opus skills. Man. :frowning:

You got the links and so on ok Leo?

Many thanks!

This turned out to be quite interesting. Due to the way the files were tagged, each one had the same image data and cover art type, but a unique description string for the cover in each file, which was confusing things.

We'll have a fix for this in the next update.

Ok, well, ok then. I am glad it was interesting, and I am glad it is fixable :slight_smile: Many thanks for this one. Appreciated.