Is there a wait in the execution of the actions;

Maybe a stupid question but here is an example of what i am dealing with.

I try to use this actions as the image shows.


So when i move the files to the folder i should get the path of the one who have been moved and the other should show me the same path.

But as you can see in the image i get the same path for both of them.


If i look at the real %_path% column it shows this, which is the right one because the one of them can't be moved because it has the same tags as the other one.


I suppose that the actions are executed from TOP to BOTTOM, so i wonder why is this happening. "Because of the speed of the light maybe!!!!!!!!! :)" Or am i doing something wrong, "Again!!!!!!!!! :)"

Actions that modify the filename or path are always executed last.
You would have to split them up unto different action groups.
I found this thread on a similar topic:

I can not reproduce this behaviour.

After creating the 3 actions in the same actiongroup and then executed it, you can see the different path contents in the columns as well as in the Alt + T window


So! What are you doing right;

Just to make it clear I use two files not one. With the same tag values.

Also i think we have a conflict here with you "LyricsLover" and "ohrenkino"

You can not move two files with the same identical target path and filename, as you try it with
*.\____MOVED\%album%\%artist% - %title%

You get an error message saying "Cannot create a file when that file already exists" for the second and following files trying to be moved to the same target path and filename.

That's why the one should not show the same value. That is what i am saying in the first post.

The only way I can explain the whole thing:
The first file gets treated as it should.
Which means that all actions except the one to make an OS call to rename the file are carried out.
This includes the creation of the new name.
_FOLDERPATH is also resolved to a fixed string and set to the new name. All this happens to the file in the old location.
That is why you see the same string twice: old and new match.
When the second file - that already has all the new data set - is finally renamed then that fails and the OS returns the error and the file stays in the old location. The modified user-defined tags stay the same, though - and that is what you see.

In short: first all the tag data is set (and nothing read again),
then finally, the file gets renamed.
If that fails, the set data in the tags stays.

Is this the right approach;
Shouldn't every file been checked for what it has to do;
I am only making rhetorical questions here, i don't have knowledge of programming .
Just saying that every file should be checked. something like clearing only the cache of _FOLDERPATH in every cycle/file if this is approachable or maybe check the paths from the very start.
Are you sure this is not a bug;
Again just saying, i have no idea how the whole thing works in the background.
Probably you are right. Anyway thanks.

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