Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[glynor]

Clean() Mode 3 appears to either be broken, or to consider the term "special characters" in a way that doesn't match user expectations.

Examples:

Clean([Artist],3) where [Artist] is

!!! = !!!
10,000 Maniacs = 10,000 Maniacs
Amadou & Mariam = Amadou & Mariam
B-52's = B-52's

Other examples with all things that a normal person would consider "special characters" (?$%^#!@$*) all result similarly as far as I can tell.  So, it seems like it is broken, or it means something like non-printable characters, which I didn't try.

This is on 17.0.182.  I haven't tried with MC18, but I will if you fix this, and the Library Server is stable enough for day-to-day use for now.

Also, what I'm really trying to do...

[glynor]

Is clean to match MC's normal filenaming behavior, which it doesn't provide, so I actually can't do it right.  But for my purposes, it would half-way work.  However, while you're at it, wouldn't a Clean() mode that actually does that - generates a "filename cleaned" version of the string, as MC would output it if used in Rename, Move, and Copy files and the Handheld Sync facilities - be more useful?

What I want to do is make my [iTunesFileKey] work right. Prod's iTunes Library Sync plugin (MCiS) can use a special [iTunesFileKey] field in the library to contain an "alternate file location" so that it can point iTunes at separate "physical" copies of the files in your library than the "real source" files.

I do this because:

1. I have a lot of files that iTunes won't support (FLAC, etc).
2. I don't want that piece of trash touching my original files.

So I sacrifice one for the team hard-drive wise.  I have a Handheld in MC that syncs my entire MC Music Library (or nearly everything) over to an "iTunes cache" folder on my RAID.  This happens once per day, automatically (which only works because it is the only handheld I have, since you can't address them by name via a MCC).  Then MCiS runs and syncs these files/folders into iTunes, and syncs some playstats from iTunes back into MC.

This works, kinda.  Except for those darn "special characters".  When you feed the Handheld system a field value to use as "destination path" it, of course, replaces illegal characters with the underscore character.  But I don't have a way to parse a field to return that same result, so I can't make my [iTunesFileKey] match the actual destination filename for these kinds of Artists, Albums, whatever.  I'd really like to be able to wrap the entire [iTunesFileKey] expression in a Clean(My Big Expression Here,4) and have it spit out the proper filenames.

I could even half-way hack it with the existing Clean(,3) mode if it worked, but it doesn't seem to.  Or I'm doing something wrong.  Or you mean something weird by "special characters".  Or some jerk edited the wiki, I suppose.

Lastly, if I could add iTunes as a Handheld, none of this would be necessary.

[Matt]

I think it removes characters that aren't supported in filenames.

For example:
Clean(<>?:!@#$%^&*/(/), 3) = ----!@#$%^&-()

I'll check the code tomorrow and post for sure.

[glynor]

For example:
Clean(<>?:!@#$%^&*/(/), 3) = ----!@#$%^&-()

Okay, so it is supposed to be an illegal filename filtering version of Clean().  I'd just assumed that it was general purpose since it doesn't use the right character, and that it would apply to all special characters, so I was surprised I didn't see those changes as expected.  Now I see (and I've tested) that it does indeed replace colons and whatnot as it should, and it leaves valid NTFS characters like ? and <> alone.

Great!  As I said, I want a filename version of Clean().

But even still, this one doesn't work right.  MC replaces the illegal characters with a _ when renaming, and Clean(,3) uses a -.

So, since this is supposed to be a filenaming specific version of clean() (a good thing) then it should be fixed to match MC's behavior.

[glynor]

I noticed another inconsistency going through my sync error logs.  I have this [Album] name in my Library: No Album Folks....

That's the words "No Album Folks" followed by four periods.  (Don't ask, that's just how it was in the tags.  It is a "junk track".)

The Clean() mode passes through as: No Album Folks....
MC's Handheld Sync ignores the periods and writes the folder as just plain: No Album Folks

So, it seems to drop the . character, not replace it with an _ like it does colons and other stuff.  You listed the . character above in your example as well, but the period character IS valid in NTFS filenames (though they are special because the last one is the extension, and there might be other limits).  In any case, keeping the it consistent seems like the best call: (1) fixing Clean() to obey your special purpose period cleanup rule to avoid uglyness like: No Album Folks____ OR (2) fixing the renaming to stop not using periods.

[glynor]

Any love on this?

To review:

1.  Clean replaces special characters with a -.  Renaming uses _
2.  Clean ignores (preserves) periods, but they are omitted when written to filenames (by the handheld engine, at least).

[Matt]

1.  Clean replaces special characters with a -.  Renaming uses _
2.  Clean ignores (preserves) periods, but they are omitted when written to filenames (by the handheld engine, at least).

Using a dash is intentional in the code, but I don't know why.

As for periods, they're a special thing.  They're not allowed as the trailing part of a folder name, but I think they're allowed everywhere else.

I wonder if Clean(..., 3) should just use the same filename cleaning function that's used everywhere else?

Or there could be a new CleanFilename(...) function.

[glynor]

I wonder if Clean(..., 3) should just use the same filename cleaning function that's used everywhere else?

Or there could be a new CleanFilename(...) function.

I'm fine with either, though I can't imagine what someone would want the current Clean(,3) mode for now.  If it did actually strip out ALL special characters (perhaps with an optional "replace with specified character" third parameter), then maybe...?  I don't know... I can't think of a use, personally.

But like I said, either way is fine.  Something that does exactly the same thing as the filename cleaning function would be super-useful.  I know in some of the other threads kicking around where this was discussed, I wasn't the only one to bring it up.

[Matt]

Next build:
Changed: The Clean(...) expression in mode 3 does a standard filename clean and replaces unsupported characters with underscore.

Feedback appreciated.