Comment 1 Andre Klapper 2009-11-26 15:34:27 UTC

Thanks for reporting this.

Note to myself: Might be fixed after the 1.2009.42-11 release by int-135368.
Waiting for internal verification...

Incorrect behaviour still present in 2.2009.51.1...

*** This bug has been confirmed by popular vote. ***

Comment 4 Andre Klapper 2010-02-12 17:33:15 UTC

*** Bug 8143 has been marked as a duplicate of this bug. ***

Bug still there after latest update (2010.02-8)!

Come on guys! Yes, it's a "low priority" bug, but for people with many such
albums it's really annoying, and it's been THREE MONTHS now with zero publicly
available progress!
Is it really that hard to add another 10 lines of code?

P.S.: tried to change the version field, but bugzilla won't let me...

Comment 6 Andre Klapper 2010-02-23 11:21:52 UTC

(In reply to comment #5)
> Bug still there after latest update (2010.02-8)!

Of course, as it is in NEW state instead of RESOLVED.
No need to create bugmail by adding a comment.

(In reply to comment #6)
> (In reply to comment #5)

> Of course, as it is in NEW state instead of RESOLVED.
> No need to create bugmail by adding a comment.
> 

Well, you yourself suggested in comment #1 three months ago that a fix MIGHT
come after the 42.11 update and that you waited for some internal verification,
but even the most recent firmware upgrade did not include a fix, and there were
no further comments regarding the progress on this matter.

As an ordinary user one could get the idea that this bug was just considered
irrelevant, abandoned and forgotten about, so please consider this further
bugmail a sort of followup.

Has there been any progress on resolving this behaviour in the past 3 months?

What is still needed to release a fix?

Is there any half-reliable estimate on when (if at all) we can expect to see a
fix?

Is there anything we can do to help?

Comment 8 Andre Klapper 2010-02-24 17:48:21 UTC

(In reply to comment #7)
> Well, you yourself suggested in comment #1 three months ago that a fix MIGHT
> come after the 42.11 update

Sorry, seems my comment was unclear and created misunderstandings.
I did not say "fix might come" here. I said "Might be fixed after 1.2009.42-11
by some-internal-bug-report". Unfortunately that bug report in the end was
unrelated to this one here.

> Has there been any progress on resolving this behaviour in the past 3 months?

No. There currently is no progress internally on this issue.

> What is still needed to release a fix?

Investigation, a patch, its inclusion, internal verification, public release.

> Is there any half-reliable estimate on when (if at all) we can expect to see a
> fix?

No.

> Is there anything we can do to help?

Patches welcome I'd say.

Comment 9 Andre Klapper 2010-05-17 17:22:01 UTC

*** Bug 10188 has been marked as a duplicate of this bug. ***

(In reply to comment #8)
> Patches welcome I'd say.
> 
The media player is closed source, so I guess we have to look into the tracker?
Where exactly is the link between media player and tracker done? Is it
something available to us?

Comment 11 Andre Klapper 2010-05-18 13:07:49 UTC

The link between Multimedia Framework and Tracker should be
mafw-tracker-source.

(In reply to comment #11)
> The link between Multimedia Framework and Tracker should be
> mafw-tracker-source.
> 

Looking at
http://mxr.maemo.org/fremantle/source/mafw-tracker-source/libmafw-tracker-source/definitions.h?force=1#28
there is no key in tracker for the discnumber tag, so it won't be available to
MAFW.

Should the key be available, my guess is that we should add a
MAFW_METADATA_KEY_DISCNUMBER (or so) to the sort_fields in
http://mxr.maemo.org/fremantle/source/mafw-tracker-source/libmafw-tracker-source/tracker-iface.c#665

It's just random thoughts, but at least I'm documenting what I found.

> Should the key be available, my guess is that we should add a
> MAFW_METADATA_KEY_DISCNUMBER (or so) to the sort_fields in
> http://mxr.maemo.org/fremantle/source/mafw-tracker-source/libmafw-tracker-source/tracker-iface.c#665

The official Name for the information in question is "PARTINSET" or "Part of
Set" for ID3v2.
It was not part of the original ID3 Version 1 specification, but was adopted in
v2 as "TPA" and later changed to "TPOS" frame.
For vorbistag (ogg, flac etc) there is no officially standardized name, but
from my experience, "DISCNUMBER" is a widely used implementation.

While I understand that the media player itself only supports mp3 and a few
proprietary formats it would be nice if the implementation of this feature
could be done in a way so that it is also available to the plugins for other
formats floating around, so the software's functionality does not depend on
file format where ever possible.


references:
http://age.hobba.nl/audio/mirroredpages/ID3_comparison.html
http://xiph.org/vorbis/doc/v-comment.html

(In reply to comment #13)
> > Should the key be available, my guess is that we should add a
> > MAFW_METADATA_KEY_DISCNUMBER (or so) to the sort_fields in
> > http://mxr.maemo.org/fremantle/source/mafw-tracker-source/libmafw-tracker-source/tracker-iface.c#665
> 
> The official Name for the information in question is "PARTINSET" or "Part of
> Set" for ID3v2.
> It was not part of the original ID3 Version 1 specification, but was adopted in
> v2 as "TPA" and later changed to "TPOS" frame.
> For vorbistag (ogg, flac etc) there is no officially standardized name, but
> from my experience, "DISCNUMBER" is a widely used implementation.
> 
> While I understand that the media player itself only supports mp3 and a few
> proprietary formats it would be nice if the implementation of this feature
> could be done in a way so that it is also available to the plugins for other
> formats floating around, so the software's functionality does not depend on
> file format where ever possible.

Afaiui, MAFW doesn't care about the tag itself, but relies on tracker to use
them, and the key didn't exist in tracker 0.6. It seems that it tracker 0.8 has
it, but I guess it's a bit late to include it in PR1.2 (</kidding>)

Another solution suggested on #tracker would be to tune the track number, for
example using track = 1000 * discnum + tracknum

As I don't think the tracknumber is displayed anywhere, and since we don't
touch the metadata themselves, it should be safe.

That way, only tracker-extract-{mp3,vorbis,...}.c would have to be modified.

normally if you rip two disks wouldn't each album be named "Album XXXX (disk1)"
and "Album XXXX (disk2)" or something like that?  
then each disk would be separate and play in order.
Did you combine the disks manually?

If you combine the disks, under one album name, you'll have to edit the id3
tags for the Track number.
otherwise they'll play as stated, because the first song from each disk will be
labeled with an id3 track tag of "01" the second song from each disk with "02"
etc etc.

you'd have to manually change all of disk 2 track numbers to follow disk 1.

If the ripper automatically combined the disks into one album, I would suggest
that the ripper software might have a problem, and maybe there is no issue with
the media player for the N900.

Sorry totally missed the part about disk 1 and disk 2 id3 tags until I read the
post a second time.

But what I wrote could be a temporary solution :P

(In reply to comment #15)
> Another solution suggested on #tracker would be to tune the track number, for
> example using track = 1000 * discnum + tracknum
> 
> As I don't think the tracknumber is displayed anywhere, and since we don't
> touch the metadata themselves, it should be safe.
> 
> That way, only tracker-extract-{mp3,vorbis,...}.c would have to be modified.

Is there any new development on the subject? The bug has been open for a while
and from what I can tell it still exists.

It's not incredibly complicated to work around it in day-to-day usage, but
still it's annoying because one cannot simply copy files over to the device and
be done with it.

Comment 19 Andre Klapper 2011-01-10 13:08:37 UTC

(In reply to comment #18)
> Is there any new development on the subject?

No.