1170 Disc# and Track# fields incorrectly padded in masks

by **Seeker** » Wed May 21, 2008 9:43 pm

I will admit I was shocked when about 3000 of my files suddenly got renamed (I use auto-organize extensively).

Then again, I said "oh - it's now right". But then yet again, I think more people would be angry than have my reaction.

I do NOT think we should make it wrong again, but you have an extremely valid point that this fix will shock a lot of people.

by **Teknojnky** » Wed May 21, 2008 6:00 pm

jiri wrote:This will be fixed in the next release as follows: Everything will remain as currently is (i.e. in the latest beta build 1174), but <track#:2> won't cut numbers longer than two digits. This cutting doesn't make much sense, and in case anyone would ever need it, e.g. $right(<track#:2>,2) could be used to achieve the same.

Jiri

Ok, so just to be clear then, <track#:2> will pad track #1 thru #9 with 0, and won't affect anything with 2 or more digits?

I can accept this solution, although I don't like having to change all of my various file masks to account for it, but I suggest that background auto-organize be disabled when upgrading existing installations so to avoid general outrage of a bunch of background organization that will then need re-organized yet again to put them back how they (the user) wants them to be.

Another alternative is to make sure the download page or installer notify the user of the change so they can be ready for it and/or fix their ini manually before starting MM after upgrade.

The main reason I am so concerned is, that I don't believe that users should have some behavior change in such a manner that it modifies there library in an unknowing manner.

I would not be happy if MM suddently started changing all of my tags or files from the way I had it configured, just because I upgraded to a new minor version. (like say changed all my tags from 2.3 to 2.4 or vice versa without my approval)

by **MoDementia** » Wed May 21, 2008 5:51 pm

jiri wrote:This will be fixed in the next release as follows: Everything will remain as currently is (i.e. in the latest beta build 1174), but <track#:2> won't cut numbers longer than two digits. This cutting doesn't make much sense, and in case anyone would ever need it, e.g. $right(<track#:2>,2) could be used to achieve the same.

Jiri

Woot,
I have never exploited the Track# behaviour all my masks have track#:2 but i did have a second set for track#:3

So I'm pretty happy

by **jiri** » Wed May 21, 2008 5:30 pm

This will be fixed in the next release as follows: Everything will remain as currently is (i.e. in the latest beta build 1174), but <track#:2> won't cut numbers longer than two digits. This cutting doesn't make much sense, and in case anyone would ever need it, e.g. $right(<track#:2>,2) could be used to achieve the same.

Jiri

by **Teknojnky** » Wed May 21, 2008 5:10 pm

Here is one other very critical thing to consider:

Everyone who has setup background auto-organize masks based upon the previous behavior, will upon installing 3.03 will have there files re-organized without any notice.

People with huge carefully organized libraries are likely not going to be very happy having MM start changing their files, and even if they don't care they will suddenly have massive resource usage that this process takes (cpu/disc etc) for large collections.

by **Teknojnky** » Wed May 21, 2008 3:23 pm

I hate to disagree, but the installed base acustomed to the prior behavior has to be far greater than the handful of people using the latest beta and preferring this new behavior.

If/when this release goes live, over time your gonna get thread after thread asking/complaining that MM is no longer behaving the same with auto-organize masks.

by **chrisjj** » Wed May 21, 2008 2:20 pm

Teknojnky wrote:a simple option to automatically pad track and/or disc numbers (during auto-organize) would be fine. Basically allow choosing of old behavior and new bahavior.

I think that would not be fine for the product. If every fixed dodgy behaviour was preserved as an option... yuk.

What I want is for tracks to be on the file system PADDED, but displayed in the track list without padding. I don't really care if the UI hides the zeros in the fields

I do really care. Please, no (further) false property display in the UI.

perhaps use @ instead of : (or some other delimiter/control character)

@ is already used (for grouping). I'd go for ~ (twiddle, suggesting 'approximate').

by **Seeker** » Wed May 21, 2008 2:10 pm

I disagree with rollback - as you say - we are late in the cycle.

And part of beta testing is to roll with the new work - some people (like me) now depend on the new behavior; and spent a bit of time to accommodate it.

I do sympathize though, I've only depended on mediamonkey for 2 months, and did have to change quite a bit - I'm sure it must be worse for you.

But rolling back is just like putting bugs back INTO a program - even if they were bugs we were used to and counted on.

but I do agree that an option to do what you want would be good. OTOH - is there any reason you couldn't go with <track#:3> and use 001 002 003 in your file system? It's not really that different than 01 02 03.

As for me, I tried to figure out ways to insure I didn't have track#s above 100 - usually be giving part of the tracks a different disc#

by **Teknojnky** » Wed May 21, 2008 1:47 pm

if there was a way to pad double digits without screwing up triple (or more) digits, it might be ok.

<track#:2> screws up track# > 2

perhaps use @ instead of : (or some other delimiter/control character)

ie <track#@2> to pad only double digits without changing 3 digit fields.

but I really think its too late in the release cycle to be making these kinds of changes.. I would suggest reverting it to previous behavior (wrong or not), hammering out some way to achieve both types of desires and roll it into the next round of releases post 3.03.

by **Seeker** » Wed May 21, 2008 1:41 pm

As always, when two ways of doing things are diametrically opposed, we're back to a checkbox option for how something should act - and I think you said that yourself.

But the fact it was "backward fixed" as you said, doesn't change the fact that simply undoing the fix would make it wrong - even if we liked it wrong. The person who reported it and the person who fixed it did the right thing.

But maybe we need a clickbox to say "do it wrong - I'm used to it that way" in addition to it being correct now.

by **Teknojnky** » Wed May 21, 2008 1:31 pm

Seeker wrote:Well, whether I like it or not, now it is "right".

Padding anything behind the scenes (even if it is intended to help) is really breaking the rules set for how these masks work.

I took advantage of it myself - my disc #s were single digit, and I liked how it added a 0 in front.

But "it was wrong". When the fix came, I used a script to make each numeric disc # to have a 0 within it. (I did it this way because I have non numeric fields like A B and even "Image Album" in the Disc #.

So, yes it is a pain both for tracks and disc #s - but I think we all need to belly up to the bar and fix our own masks or pad our tracks with 0s ourselves . We took advantage of the "wrong" way to do it.

I agree somewhat.

What I want is for tracks to be on the file system PADDED, but displayed in the track list without padding.

I don't really care if the UI hides the zeros in the fields, or if the auto-organize pads the zeros, but I would just rather not have to go and re-do a bunch of masks (and fix a bunch of data) because of this bakcwards change or 'fix'.

by **Teknojnky** » Wed May 21, 2008 1:27 pm

a simple option to automatically pad track and/or disc numbers (during auto-organize) would be fine. Basically allow choosing of old behavior and new bahavior.. noting to the user that new behavior supports text/non-numeric track/disc fields where as the old behavior is more limited.

I am still thinking about it, but I can't see any simple way to achieve work arounds (file masks) to the previous behavior while keeping the new.

by **Seeker** » Wed May 21, 2008 1:26 pm

Well, whether I like it or not, now it is "right".

Padding anything behind the scenes (even if it is intended to help) is really breaking the rules set for how these masks work.

I took advantage of it myself - my disc #s were single digit, and I liked how it added a 0 in front.

But "it was wrong". When the fix came, I used a script to make each numeric disc # to have a 0 within it. (I did it this way because I have non numeric fields like A B and even "Image Album" in the Disc #.

So, yes it is a pain both for tracks and disc #s - but I think we all need to belly up to the bar and fix our own masks or pad our tracks with 0s ourselves . We took advantage of the "wrong" way to do it.

by **chrisjj** » Wed May 21, 2008 1:25 pm

rusty wrote:If anyone has any bright ideas to satisfy all needs, bring 'em on.

Re the specific issue of whether the default pads or not, I think by definition no solution can satisfy all needs since they are contradictory. Re the issue of delivering /options/ that satisfy all needs, then surely the current design (and proposed implementation) is fine.

by **rusty** » Wed May 21, 2008 1:17 pm

If anyone has any bright ideas to satisfy all needs, bring 'em on.

(I personally liked the 'old' approach with padding, but agree that it was confusing/inconsistent/problematic for users who didn't want the padding.)

-Rusty

1170 Disc# and Track# fields incorrectly padded in masks

Post a reply

Expand view Topic review: 1170 Disc# and Track# fields incorrectly padded in masks

Re: Track# mask default setting

Track# mask default setting