1170 Disc# and Track# fields incorrectly padded in masks

[Teknojnky]

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.

[Seeker]

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#

[chrisjj]

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').

[Teknojnky]

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.

[Teknojnky]

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.

[jiri]

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

[MoDementia]

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

[Teknojnky]

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)

[Seeker]

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.