what file types? if mp3, make sure you check id3v1 and id3v2 tags.
what prog was used to create/view the tags?

(In reply to comment #1)
> what file types? if mp3, make sure you check id3v1 and id3v2 tags.
> what prog was used to create/view the tags?

All files are mp3.  Tags were created and edited with Dr.Tag http://www.drtag.de/en/.  Everything has worked fine with 6.2.1 and previous versions for many months.

yes, I understand.  New release, however, and some things change.  Please, double check both id3v1 and id3v2.  6.2.1 had a problem determining precedence when both versions existed.

(In reply to comment #3)
> yes, I understand.  New release, however, and some things change.  Please,
> double check both id3v1 and id3v2.  6.2.1 had a problem determining precedence
> when both versions existed.

Yes my library contains both id3v1 and id3v2 tags. Both Dr.Tag and Internet Explorer display the tags correctly.  Slimserver 6.2.2, on some files, displays (for example) 'Rock' when it should be 'Jazz'.  6.2.1 does not appear to have a problem with a mixture of v1 and v2 tags.  What are you suggesting I should check?

(In reply to comment #4)
> (In reply to comment #3)
> > yes, I understand.  New release, however, and some things change.  Please,
> > double check both id3v1 and id3v2.  6.2.1 had a problem determining precedence
> > when both versions existed.
> Yes my library contains both id3v1 and id3v2 tags. Both Dr.Tag and Internet
> Explorer display the tags correctly.  Slimserver 6.2.2, on some files, displays
> (for example) 'Rock' when it should be 'Jazz'.  6.2.1 does not appear to have a
> problem with a mixture of v1 and v2 tags.  What are you suggesting I should
> check?

Sorry I meant Windows Explorer not Internet Explorer

I'd suggest checking that the files in question have both versions populated, vs just one or the other.
perhaps try to attach one of the files that exhibits the problem (I trust they stay mixed up in the same way despite a clear library and rescan) to this report so that someone can use it for debugging.
thanks.

(In reply to comment #6)
> I'd suggest checking that the files in question have both versions populated,
> vs just one or the other.
> perhaps try to attach one of the files that exhibits the problem (I trust they
> stay mixed up in the same way despite a clear library and rescan) to this
> report so that someone can use it for debugging.
> thanks.

A file is attached as requested for you to examine.  This is an example of an mp3 file with the 'genre' tag set to 'Jazz'.  It works normally with Slimserver 6.2.1 but shows 'no genre' when used with 6.2.2.  The tags are all id3v2.

I will keep using 6.2.1 for the time being as it works perfectly in my system

(In reply to comment #7)
> (In reply to comment #6)
> > I'd suggest checking that the files in question have both versions populated,
> > vs just one or the other.
> > perhaps try to attach one of the files that exhibits the problem (I trust they
> > stay mixed up in the same way despite a clear library and rescan) to this
> > report so that someone can use it for debugging.
> > thanks.
> A file is attached as requested for you to examine.  This is an example of an
> mp3 file with the 'genre' tag set to 'Jazz'.  It works normally with Slimserver
> 6.2.1 but shows 'no genre' when used with 6.2.2.  The tags are all id3v2.
> I will keep using 6.2.1 for the time being as it works perfectly in my system

Why are you suggesting that both v1 and v2 tags should be populated? this has never been necessary before. I have over 8000 music tracks in my music library, some with v1 and some with v2, also maybe some mixed. They have all worked properly on versions of Slimserver prior to 6.2.2.

becuase I am TRYING to diagnose the cause of the problem you are seeing.  I don't care that it worked before, as what matter is what it is doing now. As I have said, the logic around tags has changed.  Where 6.2.1 may have just let things slide, 6.2.2 does a lot more. Please attach your file using the "create a new attachment" link.  a smallish mp3 should be within the size limit.  That way, someone can then look at this and diagnose the problem without having to bother you with questions.  thanks.

(In reply to comment #9)
> becuase I am TRYING to diagnose the cause of the problem you are seeing.  I
> don't care that it worked before, as what matter is what it is doing now. As I
> have said, the logic around tags has changed.  Where 6.2.1 may have just let
> things slide, 6.2.2 does a lot more. Please attach your file using the "create
> a new attachment" link.  a smallish mp3 should be within the size limit.  That
> way, someone can then look at this and diagnose the problem without having to
> bother you with questions.  thanks.

Thank you for your responses. I have now discovered that I can eliminate the problem by deleting the tags in the offending files and then re-inserting them. It would appear that there was something (invisible) in the tags which did not cause any problem with 6.2.1 but does cause problems in 6.2.2.  I will therefore modify all the offending files by deleting and then re-inserting all the tags.

I'm sorry if I have wasted your time but maybe we have both learnt something!  

Please may I congratulate you and your colleagues associated with Slimserver and the Squeezebox for producing an excellent product which has given me many hours of pleasure.  Thank you again.

If you leave a file for reference, we can still look at it to make sure it doesn't cause confusion in the future for others. Thank you.

Created attachment 1215 [details]
Music mp3 file which displays incorrect 'genre' in 6.2.2

As requested this is a music mp3 file for investigation. It shows correct 'genre' tag with 6.2.1 but incorrect with 6.2.2.

thanks. I'll reopen so that we can have a look at this case.  

Malcom - I've just fixed this bug - iTunes inserted a bogus frame in the ID3 header, and it was breaking the parsing.

I've commited change 7266 which fixes the reading of ID3v2.3 tags with a ID3v2.2 frame in the header.

I'll move this change to 6.3.x as well, so it will be in the nightly builds.

Thanks

(In reply to comment #14)
> Malcom - I've just fixed this bug - iTunes inserted a bogus frame in the ID3
> header, and it was breaking the parsing.
> I've commited change 7266 which fixes the reading of ID3v2.3 tags with a
> ID3v2.2 frame in the header.
> I'll move this change to 6.3.x as well, so it will be in the nightly builds.
> Thanks

Thanks for the info Dan, good work!

Verified fixed in SlimServer Version: 6.3.0 - 7895 - Windows XP - EN - cp1252

This bug fix is now part of a released version, and so has been marked closed. If you are still experiencing this problem, please reopen the bug.