Print

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

[steveklein]

the blah - i am running windows xp sp 3 MC 12 build 530

anyways, i still seem to encounter problems where Media Center is attempting to write tag data and/or library field data automatically when i don't want it to. it will occassionally change years, genres, etc. when i have painstakingly gone through each of my albums to do it all manually. it's not a huge number of files that are being edited, but a spattering here and there is enough to wreck (maybe this is a strong term) my database.

i thought i had all the automaticness of media center turned off, but perhaps not.

in tools/options/general i do have the update tags when file info changes box checked. and this is fine. i think. when i go in MC and change the year of an album from say 2005 to 1977 (to reflect the original release as opposed to the remastered release), i want that to be updated to the tag. however, i don't know when the file info would be changing except when i am manually changing it... however it is obvious in many cases it is?

in the online metadata section, i am not submitting ratings or allowing cd lookup/submission. i am submitting cover art changes, though this shouldn't be automatically grabbing cover art without my approval.

in the library/folders tab, i am running auto-import in the background, but not analyzing audio/getting cover art/building thumbnails during import. i am updating for external changes, but i don't use any other program to manage my library or tags other than media center. the Yes (protect network files) is selected when it comes to fixing broken links.

what option(s) should i change or other option(s) should i be looking at to keep media center from doing its own thing when it comes to writing/changing library fields and my precious tags?

[JimH]

I can't see how MC will write a library field if you don't ask it to.

Maybe another application?

[Matt]

it will occassionally change years, genres, etc.

No automatic tools in Media Center should do this.

Auto-import will detect changes made by other programs and re-read tags, but you say there are no other programs.

Do you have any way to reproduce the issue?

[ADDiCT]

This problem has been mentioned before, but i can't remember when or where it was. I've also seen this behaviour in MC, but it's very, very hard to identify when it happens - no-one can keep track of each and every file in a collection, in order to identify any possible, unintentional tag changes.

The effect is what i call "tag shifting". Sometime, certain tags will get changed by MC. Sometimes, tags get swapped (like, for example, year and comment), or sometimes they disappear completely. I've also seen tags "shift", which means that all tags are still in the file, but at the wrong location. An example would be a "Mood" tag that's suddenly a "Situation" tag, and the "Situation" tag is something else. Most of the time, the changes seem to affect single tracks, not whole albums. I've seen this happening very often in MC11, but not as much in MC12. For quite some time with MC11, i was thinking this was an issue with special characters in the database. To get rid of the problem in MC11, i deleted a lot of custom fields (for example, i had a user field with full-text AMG reviews), and rebuilt the database from scratch. After that, the problem was (more or less) gone. From time to time (in MC12), i stumble across a track where the tags have been changed (and i'm pretty certain it wasn't an intentional change), and i just shrug and correct the error. I know all this sounds a bit esoteric, but i'm pretty sure there is some kind of problem, sometimes, with some files. But i have not the slightest idea as to what might cause the problem.

EDIT: ah, i've just discovered one such file. It has a "Situation" tag with the value "Zuhören". The value is duplicated in the "Comment" field, and i'm sure i didn't do that. The tag is still there after "update libarary from tags". Even after deleting the "Comment" tag, or filling it with a different value, the "Zuhören" value will still be there after "update library from tags". And now it gets really strange: i open the file with Mp3tag, and the only tag i see with a value of "Zuhören" is a "Musicmatch Situation" tag. I delete that tag in Mp3tag (and clear the "Sitation" tag in MC), and again do a "update library from tags" in MC. The entry is still in MC! A quick check in Mp3tag reveals that there is not a single tag with the value "Zuhören" in the file. To get rid of the tag, i have to delete _both_ tags in MC - the "Comment" tag, and the "Situation" tag. After that, as soon as i change the "Situation" tag to "Zuhören" again, the "Comment" tag is set to the same value, too. Looks like a bug to me. If i use a "Situation" value without an umlaut, the "Comment" tags stays empty.

EDIT2: for testing, i've searched for other tracks with a "Zuhören" value in the "Situation" field, and an empty "Comment" field. After "update library from tags", both fields show the "Zuhören" value. This is definitely a bug.

steveklein, do you have umlauts or other special characters in your tags?

EDIT3: even more strange effects. Two tracks with a "Chill" value in the "Situation" tag suddenly have the same value in the "Comment" tag. No umlauts whatsoever with these two.

EDIT4: and more of the same... 22 tracks with the value "Deutschland;Nürnberg" in a user defined field suddenly have the same value in the "Comment" field.

[Matt]

Updating the library from tags will not replace data with an empty value, even if you removed it from the tag with another program.

[ADDiCT]

Ah, i see. I think this is not very logical, though. The function is called "update library from tags", so i would assume it does exactly that - update the library with the current info from the tags. Nothing more, nothing less. Some time ago, i've reported a problem where tags that have been cleared in MC wouldn't get deleted from the file (that problem was never fixed, according to the changelogs). It's quite possible this problem is connected to MC's behaviour of keeping tags that are not in the file. Is there a particular reason why MC doesn't clear tags that are not in the files?

Anyway, i did some tagging today, and have seen the problem i've described several times. Tags with umlauts are definitely a problem, but files without umlauts in the tags are affected as well. I'm still trying to see a pattern, or identify any problematic tag characters.

[Alex B]

ADDicT,

Do you use Mp3tag from http://www.mp3tag.de ?

By default it saves ID3v2 tags in v2.3 UTF-16 format.

Its UTF-16 format may not be fully compatible with MC. Possibly the problems with incorrectly read  multiple comment frames are caused by the UTF-16 character encoding.

I'd recommend using the v2.3 ISO-8859-1 format unless you really need UTF. In that case you could try v2.4 UTF-8. UTF encoding is not needed for umlauts or other special characters in european languages that use the latin alphabet.

[ADDiCT]

Alex, yes, that's the program i'm using. Mp3tag is setup to write ISO-8859-1, as suggested in another thread on Interact.

I've seen more tagging strangeness. This time, a few albums have two "Year" tags (i've seen tracks with identical values for both tags, and with different values), which are visible in Mp3tag, but not in MC.

Another strange thing is that MC doesn't delete the "Bios" tag, even if it has been cleared in MC. I have a few tracks where this field is in the tags, though it seems MC12 is configured to not write this field to file tags, by default. But no matter whether the field is set to store data in tags or not, MC won't clear the field. Again, i had to delete the field with Mp3tag to get rid of the data.

EDIT: another strange effect. I've imported an album that had a "Disc" tag with the value "1/1". I've deleted that tag in MC, and Mp3tag still shows the "/1" part of the tag, which obviously has been left behind by MC.

[Alex B]

Was the Bios tag displayed as "COMMENT MusicMatch_Bio" inside Mp3tag? MC writes the Bios field values to that ID3v2 frame.

MC does not have a "total number of discs field". In my opinion it is good that it does not delete the value if some other program has written it. Actually, the total number of tracks and discs fields would be good additions to MC's tagging features. For example, iTunes supports them.

I am afraid that the developers will be unable to fix the actual problems you may be experiencing like tags written to a wrong field or existing twice in the files (if they are caused by MC) unless you can provide step-by-step instructions for reproducing them.

Personally, I have not seen anything unexpected happening to my tags. In addition, I would be very upset if MC would delete foreign fields from the files or clear library data when a tag is not included in the file. In my opinion the current behavior is correct.

[ADDiCT]

Alex, i think the problematic tags were saved as "Musicmatch Bios" or something, without the "Comment" part. This may be a leftover from MC11 or an older version of MC12, as i've definitely never tagged Bios info outside of MC. I've noticed a few other "Musicmatch ..." tags in several files, too (i think "Mood" and "Situation").

I don't know if there's a dedicated tag for "number of discs", or "number of tracks" - from what i've seen so far, a disc or track number is simply tagged in "x/x" format, and the player interprets that information.

Alex, you say you haven't seen anything unexpected happening to your tags. Are you really sure? Were you _looking_ for unexpected things, outside MC?

Umlauts are definitely a problem, but there's more.

Oh, and steveklein: sorry for capturing this thread! I'm not sure if your original problem is connected to the problems i've described, but i guess it is.

EDIT: tags starting with "COMMENT MUSICMATCH" are not correctly updated when clearing them in MC.  After clearing the field, saving tags, and updating the library from tags, the values for these tags reappear in MC. When changing the values, they are saved correctly to the tags.

[rjm]

I am pretty certain that MC does not randomly change tags. I do many regular integrity checks on my library to satisfy myself of this assertion.

I have noticed however that at least one tag (Copyright) does not behave as expected. If you clear the tag it is not updated in the file, even though the tag is configured to do so. This means that it appears cleared until the next time that you update library from tags when it magically reappears, which could lead you to the conclusion that MC is randomly changing the tag. Perhaps this same odd behavior exists for other tags in addition to Copyright?

[Alex B]

Alex, you say you haven't seen anything unexpected happening to your tags. Are you really sure about that? Were you _looking_ for unexpected things, outside MC?

Yes and yes.

Actually, I often open audio files with a hexeditor for checking the tag contents.

However, you may use tags differently and experience problems that never occur to me. For instance, I have not noticed the "Musicmatch tag removal" problem because once I have tagged a field like Bios I don't normally remove it completely.

EDIT: it seems that all tags starting with "COMMENT MUSICMATCH" are not correctly updated when clearing them in MC. After clearing the field, saving tags, and updating the library from tags, the values for these tags reappear in MC. When changing the values, they are saved correctly to the tags.

Now you have captured the first bug that can be reproduced.

MC removes the "Comment Media Jukebox" frames correctly, but not the otherwise supported "Comment Musicmatch" frames when the corresponding library fields are emptied.

Could this be related to the recent change when ID3v2 tagging was fixed to preserve unsupported Comment frames on tag changes? Before the fix MC cleared and rewrote all comment frames on a tag change and for example the frames iTunes uses internally were lost.

[ADDiCT]

Now you have captured the first bug that can be reproduced.

The "tags with umlauts" problem can also be easily reproduced.

[Alex B]

The "tags with umlauts" problem can also be easily reproduced.

I too should have added the word "easily". I meant to say that in a positive way - you found something that may help in solving the problem .

The Situation / Comment tag problem is apparently related to these new Musicmatch tag problems and as you said, tagging the ü letter in the library fields that are associated with the Musicmatch comment frames can make the comment tagging system go nuts.

To easily reproduce one of the ü/Musicmatch problems:

1. start with an untagged MP3 file
2. tag the Situation field with ü
3. Update library from tags and see how the Comment fields gets populated with the value ü

[ADDiCT]

Alex, thanks for the additional work and information!

So now we have two bugs identified. Could you also test/confirm the "disc x/x" problem?

[JimH]

I've cleaned this thread to remove some of the opinion but leave the facts.

It makes it easier to see if there is a problem.

[Alex B]

Could you also test/confirm the "disc x/x" problem?

I think I already did that. MC removes the "Total #" values from the track numbers, but not from the disc numbers.

I would suggest to add both "Total #" fields. They would be useful. In addition the complete album logic could be extended to check these fields too. For instance, it could then notice a missing last track, which is not possible now. I can post a list of the commonly assiciated tag frames in the other tag formats.

In general, the old comment frame system could be dumped. MC could write all fields that are not standard IDv2 frames to individual TXXX frames. It would be a more straightforward system and would extend MC to support importing user tags from other programs that use the TXXX system.

For example, if you would like to import data from TXXX MY SPECIAL TAG you would just need to create a "MY SPECIAL TAG" library field and update tags from the file.

It would be enough if MC would only support reading the old comment frames and on the next tag update write TXXX frames.