New install, new issues I wasn't having before...

[crimzind]

I just did a fresh install of Win10.
I installed the latest v. of MusicBee, and imported my previous settings.
On the old installation, when I'd add content to my library, it would automatically detect the Artist and Title from the Filename and break things up and assign them to those fields.
Files were named <Artist> - <Title>. It's not auto-detecting the Artist, and just applying the filename as the full title. I'm not sure how to fix that...

More frustrating, is that suddenly MusicBee won't accept comments with text longer than ~255 characters. I wasn't having any character limit issues prior. Older files that have more than 255 characters show fine. It just won't write/save that to new files anymore, and if I edit any of the fields on an older file with over 255, it now drops the text off past the 255th character.

Any recommendations on how to solve these issues to get the prior/preferable behaviors would be appreciated.

[phred]

More frustrating, is that suddenly MusicBee won't accept comments with text longer than ~255 characters. I wasn't having any character limit issues prior. Older files that have more than 255 characters show fine. It just won't write/save that to new files anymore, and if I edit any of the fields on an older file with over 255, it now drops the text off past the 255th character.

You can set the maximum number of characters for the <comments> tag. First you need to make sure either (or both) Track Information  or Track Information (2) panels are showing. Then right-click on the header (Details or Details (2) and select customize panel. Add the <comments> tag by clicking on the three dot selector to the right of the field and in the last column set the number of characters to display.


As for your first issue, there's an option to "infer and update tags from filename" but I don't know if it can be automatically applied as I never use it. You can manually do this by selecting the file(s) > right-click > Auto-Tag by Track > infer and update tags from filename. Someone who uses it should be able to tell you if there's a way to have that applied automatically.

[Zak]

You can set the maximum number of characters for the <comments> tag.

That's only for the number of comment rows displayed in the information panel, not what's actually stored in the file.

What format are your files? There is a 256 character limit for fields in .m4a files, with the exception of lyrics.
-edit-
To clarify - that's iTunes' fault, not MusicBee's.

[crimzind]

As for your first issue, there's an option to "infer and update tags from filename"...

I have made use of that infer tool before, and I can use that going forward if I have too, it'd just be nice to have it doing that automatically again.
Appreciate the information.

What format are your files? There is a 256 character limit for fields in .m4a files...

99.9% of the library is .m4a, but they're the same files/format before I moved over to a fresh windows install. The comments I was filling out on the old installation regularly exceeded 256 characters, and they're all .m4a. At least they were showing that way in MB...
Uggh. I'm poking through some stuff in Windows now, and I'm not seeing any that exceed 255...

Is it possible that MB was using it's own database information for comment data, but not actually writing the full field to file, and just displaying the MB database info? Hmm. I've got tracks with comments that are 300+ characters showing in MB, but if I check their properties in Windows, they are truncated. Uggh. Okaaay. That's fine. Any idea on how I could get MB to continue to save the full comment to it's own database again, and display that instead of the "real" field?

[Zak]

As for your first issue, there's an option to "infer and update tags from filename"...

I have made use of that infer tool before, and I can use that going forward if I have too, it'd just be nice to have it doing that automatically again.

It's possible for MusicBee to automatically rename and move new files based on their tag values.
I  don't think it's ever been possible to automatically set tags apart from artwork and lyrics.
(And god knows how many complaint threads there would be from people using it incorrectly if it were).
Maybe you were using a plugin for this before?

The comments I was filling out on the old installation regularly exceeded 256 characters, and they're all .m4a. At least they were showing that way in MB...
Uggh. I'm poking through some stuff in Windows now, and I'm not seeing any that exceed 255...

When I tested it before it looked like MusicBee was saving longer comments, but then when I edited some other tags they sometimes got cut off.
I couldn't work out if there is any consistent and predictable rule being applied.

Is it possible that MB was using it's own database information for comment data, but not actually writing the full field to file, and just displaying the MB database info?

It's possible to set custom tags to be stored in the database only, but I'm not aware of any way to do that with a standard field like a Comment, or if it would help.

Hmm. I've got tracks with comments that are 300+ characters showing in MB, but if I check their properties in Windows, they are truncated. Uggh. Okaaay. That's fine. Any idea on how I could get MB to continue to save the full comment to it's own database again, and display that instead of the "real" field?

If Steven reads this he might be able to shed more light on what's actually happening.

I think it is technically possible to store longer comments in an .m4a container as long as you don't mind potentially breaking compatibility with other programs, so it might be a viable wishlist forum request to add support for it.

[phred]

You can set the maximum number of characters for the <comments> tag.

That's only for the number of comment rows displayed in the information panel, not what's actually stored in the file.

I politely disagree. The comments (of any number of characters (or rows) up to the maximum specified) are definitely embedded in the <comment> (COMM) tag as shown here in MB's Tag Inspector...

[Mayibongwe]

I politely disagree. The comments (of any number of characters (or rows) up to the maximum specified) are definitely embedded in the <comment> (COMM) tag as shown here in MB's Tag Inspector...

I believe what Zak's saying is that the setting pointed out only affects the number of display rows allocated for the comment field.
When the comment is longer than the number of rows allocated, the 'extra content' gets truncated with an ellipsis.

Increasing the number of rows only ensures that the field does not get truncated and the 'extra info' is wrapped over the next row.
The tag itself never gets modified, and the OP seems to have reported that recent MB versions aren't allowing them to edit/save/store comments > 255 characters.

[phred]

I believe what Zak's saying is that the setting pointed out only affects the number of display rows allocated for the comment field.
When the comment is longer than the number of rows allocated, the 'extra content' gets truncated with an ellipsis.

Hmmm ... I was under the impression that Zak was saying the comment was -not- stored in the file. Re-reading his reply, I see otherwise.

[Zak]

That's correct.

This is my Track Information panel for a track with a long comment and max row span set to 10:


This is the same track with max row span set to 3:


The value only affects what is displayed and is unrelated to how comments are stored within the file or elsewhere.
I guess it exists for people that want the Information panel to be displayed in a consistent location, regardless of comment length (otherwise it shifts up to fix the text).

[crimzind]

...as shown here in MB's Tag Inspector...

If you check that file's information outside of MusicBee (Windows file properties, MP3Tag, etc.) does is still show all that comment text?
~~
Edit:
So, I was poking around at things, found out I had an older version's installer (3.4) still hanging around. I uninstalled MB 3.5, reinstalled 3.4, reloaded my saved-settings, and now things are working exactly as they were, on both issues. (MB is displaying comments over 255, but it is not writing them to file. That's okay, as long as those details stay in the MB database/library, I'll live with it.)

Don't know what changed between the versions, but if anyone else comes across a similar issue/needs, while it's not ideal, that seems to be the fix. :|