Print

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

[MrC]

Currently there is no way for an external application to force clear the value from a tag in MCWS or via MPL import.  This means it is impossible to accurately set tag values in certain cases when existing tag values are bogus (e.g. a Disk # contains a 1 for a single disc album, but should be empty, or a field like AMG Track Pick should be a 1 only for track picks, and empty otherwise).

The syntax for MPL seems easy to fix.  A Field element when an empty value should be cleared:

    <Field Name="Disc #"></Field>

However, this may trip up other apps that don't take care to not output Field elements with no values.  If this is the case, then perhaps an additional atttribute Clear="1" could be implemented for safety:

    <Field Name="Disc #" Clear="1"></Field>

For MCWS, there are two cases to consider for SetInfo: 1) the single value write and 2) the CSV list write.

1. For single value writes, maybe it would be clearer to avoid trying to handle a null Value, but instead supported replacing the Value attribute with a keyword Clear:

     http://...SetInfo?...&Field=Disc #&Clear=1

2. For list values (the following are not HTML encoded for easier reading), writing a 1 to Disc # looks like:

    http://...SetInfo?...&List=CSV&Field=Name,Disc #,Artist&Value=Mother,1,Pink Floyd

and for clearing the value, it seems safe to have an empty value as a CSV entry (note the lack of a value in position 2 of the Values list):

    http://...SetInfo?...&List=CSV&Field=Name,Disc #,Artist&Value=Mother,,Pink Floyd

Possible?

[Hendrik]

I don't really like the explicit "Clear". If a MPL import contains a field with an empty value, wouldn't I expect this empty value to be imported into the database as well?

[MrC]

I think Matt had concerns (long ago) that values should not be overwritten erroneously.  Again, think of apps not properly omitting field elements when nothing should be written.  For example, a spreadsheet-to-MPL converter that doesn't remove empty fields (i.e. users typically want update-only, but never clear existing values).

So that's why I suggested an alternate Forced approach.  So long as it can be done, I'm OK with whatever you think is best.

[glynor]

MrC and I had an interesting discussion on this over in chrisjj's thread about a similar issue.

For the record, I think this is worth fixing.

chrisjj's thread is a perfect example.  The problem is, essentially, you can't "blank" existing fields that contain metadata at all via MCWS with an MPL, which makes it very difficult (if not impossible) to solve this problem via MCWS.  But, as I noted, you can solve this easily via COM.

So, if for no other reason than that I know if Matt was paying attention it would get right under his skin that the newfangled, cross-platform MCWS is "lesser than" the old crusty COM API, it is worth fixing.

But, also, as discussed in that thread, as long as it is limited to manually importing a single MPL file, I can't see the harm.  The user has expressed explicit intent by importing a specific MPL, and you can't be blamed for doing what it says to do.  You should trust explicit user instructions whenever not crazy.

To be clear, as discussed in the thread, I do not think you can do this:

* Automatically when importing anything (playlists or files) in a batch of any kind, because it would be far too easy to accidentally select a big group of files, some good and some borked, and hose your data.

* When it comes to in-file Tags themselves.  We're only talking about MPLs here.  The file tagging stuff, I think, does it correctly now, and doesn't trust suddenly blanked or removed tags.

But for MPLs, you can.

Or, at the very least, you could do something like:

If a field in an MPL contains a value that is not "null" (no characters) but only whitespace, then you blank it, and "optimize away" fields that contain only whitespace.  That would be totally safe (no broken tool is going to write " " accidentally), and would accomplish the same task cleanly and without adding a weird special case.

[glynor]

If a field in an MPL contains a value that is not "null" (no characters) but only whitespace, then you blank it, and "optimize away" fields that contain only whitespace.  That would be totally safe (no broken tool is going to write " " accidentally), and would accomplish the same task cleanly and without adding a weird special case.

In fact, MrC... Did you try this?

I haven't, but it might be that it does work this way.  If you explicitly write a " " value to a field in an MPL, it might "overwrite" the value (because this is not a null value, there's a character there).  That would stink if it littered the fields with whitespace, but it might then automatically do a Clean() type pass on the values, removing leading and trailing spaces and whitespace and whatnot.

I suppose it would depend on if it does the Clean() before or after it does the overwrite pass.  Dunno.  Might be worth trying?

[MrC]

I had tried the whitespace-only value a long time ago, and it doesn't work.  MC ignores an all-whitespace value.

[glynor]

I had tried the whitespace-only value a long time ago, and it doesn't work.  MC ignores an all-whitespace value.

Doh.  It was a worthy try though.  Thought they maybe thunk of that, but then forgot.

[MrC]

A little bump on this.

I could really use a way to clear values via MCWS (and less priority via MPL import).