$mid(%_file_mod_datetime%,5,4)


#1

Hi!

This one is hard to report and I won't be surprised if you're not able to duplicate. But I'll do my best. I am using MP3TAG version 2.50. I am a very enthousiam user and I've made my 50$ donation for sure. But here is a little slight problem that I can go over easily but now I am taking the time to report it.

Let's suppose I want to rename the filename of an entry from the modified date of the file itself. I will use ALT-1, so "TAG - FILENAME".

If I type directly "%_file_mod_datetime%", the application uses "06042012 23136 PM" for example with a sample file.

Let's suppose I am interrested to use only the YEAR in my name, I would use "MID$" and assume I need to type "$mid(%_file_mod_datetime%,5,4)" to get my 2012...

06042012

12345678
____1234

BUT NOT! When I do that, it will report simply "420"!!!
It looks like I need to type one position more than expected with one character lenght longer than expected!
If I want my "2012" reported, I need to type "$mid(%_file_mod_datetime%,6,5)" with the 5!!!

Oh! I see we can attached a file? I will attached a screenshot of what I am talking about then.

See the preview of the resulting name under in the requester.
I typed the "_" to help to see and make sure there is no annoying space inserted.

The capture I attached there shows the thing:
1st) you see the result of simply "%_file_mod_datetime%"
2nd) you see what I got with "$mid(%_file_mod_datetime%,5,4)"
3rd) you see what I got with "$mid(%_file_mod_datetime%,6,5)"

It could be nice if "%_file_mod_datetime%" would report the same thing in ALL places. When proving tag for album name for example (and it's an example), the date is reported differently...

Thanks.

Denis.



#2

Please try out your example and check the result using the converter "Tag-Tag" preview and come back to report.
Oh I see you did it already.
So ... what do you think ... what is the difference between a filename value and a tag-field value?

By the way ... for this example format string ...
%_file_mod_datetime%'~~'$mid(%_file_mod_datetime%,1,4)
... with System Date Time set according to ISO 8601 ...

... the result is in converter "Tag-Tag" preview ...
2012-04-05 16:26:21~~2012

... the result is in converter "Tag-Filename" preview ...
2012-04-05 162621~~2012

Both previews are correct.

DD.20120408.2010.CEST


#3

Hello Sir!

I am not sure about the purpose of your reply. You've seem to have replied to 99% of all the cases I've read here so I am sure you're very good and it's my fault if I don't understand... But still, I don't. Are you asking a question? Are you explaining it's normal? Am I doing something wrong?

If your replied is to say "That's normal the expression %_file_mod_datetime% does not report the same thing when I want to use it to rename a filename then when I want to use it into a MP3 tag itself", that's fine. Even if I don't see why an expression a software would use to rename something is different from a situation to another, that's fine.

For having done many programming in the last twenty years, I know reporting the datetime is something that has been "inconsistant" for many many many reasons like DOS legacy, Windows versions, FAT versions, Windows regional settings, etc... BUT inside one software, I was expecting that when we would use an expression to report the date, it would be the same through the same software, in other words, that if "%_file_mod_datetime%" is 2012-04-05" for using it in renaming the file, it would be the same for using it in a tag. Certainly I would understand that MAYBE from a computer to another the filed would be reported differently (unfortunately...) but I was expecting that once on a specific computer, for ONE software itself the same expression would report the SAME thing from a place to another...

But that's fine. My main observation was ragarding the MID$ that seems strange used in combinaison of the %_file_mod_datetime%. I've seen that in the past a few times, I simply change the parameter to make it work and that's not a big deal. Today I had time so I took the time to report it. Me I like when my colleagues take the time to report an error or what seems to be an error in the internal application I do for us so I though I could do the same now for someone else. That's simply it.

Dennis.


#4

%_file_mod_datetime% returns a text string, which contain some characters not to be allowed to be used in the file sytem.
The "Tag-Filename" preview removes such forbidden characters automatically, that's all.
I tend to say it is not a heavy bug.

But there might be a quirk in the sequence of applying the validating rule.
See there ...
Converter Tag - Filename validates part of format string before applying other functions around

DD.20120408.2058.CEST