Summary: | Incorrect track order in playlist (drag & drop from collection) | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | michael.zugaro |
Component: | Playlist | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | bjoernv, teo |
Priority: | NOR | ||
Version: | 2.5.0 | ||
Target Milestone: | 2.6 | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
michael.zugaro
2012-08-13 14:10:53 UTC
You should have at least an artist or album artist tag, Amarok doesn't use the Conductor nor Performer tags. Moving to wishlist, duplicate of wish 141991 *** This bug has been marked as a duplicate of bug 141991 *** Sorry, I should have been clearer. Although you are right that implementing a general solution to Bug 141991 (with at least 4 sorting levels) would also solve this issue, the current Bug report is not a duplicate of Bug 141991. The current Bug report is much simpler (and hence, presumably much easier to implement). Let me try to rephrase the problem. Suppose I have the four following files: Brahms - Symphony No. 4 in E minor, Op. 98 - Kleiber, Wiener Philarmoniker - 1. Allegro non troppo.ogg Brahms - Symphony No. 4 in E minor, Op. 98 - Kleiber, Wiener Philarmoniker - 2. Andante moderato.ogg Brahms - Symphony No. 4 in E minor, Op. 98 - Kleiber, Wiener Philarmoniker - 3. Allegro giocoso.ogg Brahms - Symphony No. 4 in E minor, Op. 98 - Kleiber, Wiener Philarmoniker - 4. Allegro energico e passionato.ogg The following tags/sorting levels seem to work perfectly in Amarok: Level 1: Composer (ARTIST or COMPOSER tag): Brahms Level 2: Style (GENRE tag): Symphony Level 3: Title (TITLE tag): Symphony No. 4 in E minor, Op. 98 - Kleiber, Wiener Philarmoniker However, when I drag & drop them to the playlist, they are listed in a random order: Brahms - Symphony No. 4 in E minor, Op. 98 - ... - 3. Allegro giocoso.ogg Brahms - Symphony No. 4 in E minor, Op. 98 - ... - 1. Allegro non troppo.ogg Brahms - Symphony No. 4 in E minor, Op. 98 - ... - 4. Allegro energico e passionato.ogg Brahms - Symphony No. 4 in E minor, Op. 98 - ... - 2. Andante moderato.ogg What I am suggesting is simply to sort the tracks alphabetically when their sorting levels are all the same. In this way, the movements of the symphony would be sorted in the correct order. PS: I tried adding an ARTIST tag, but this made no difference. BTW, Amarok seems to use the COMPOSER tag, at least it works with my collection. Well, I use the Composer tag for the Composer and the Artist tag for the performer, and I have no problems displaying this correctly here, using Amarok 2.6. Are you sure the track number tag is set correctly? Thanks for the track number suggestion, I can definitely use this workaround until the 'bug' is fixed. As a side note: It is my understanding that the TRACKNUMBER tag refers to a track number on a CD, rather than to a division within a musical work, which is better described by the PART tag (see e.g. http://age.hobba.nl/audio/mirroredpages/ogg-tagging.html). In any case, the word 'TRACKNUMBER' certainly does not suit well a movement of a symphony ;o) But again, as far as the current issue is concerned, it is not necessary to change anything in the way Amarok handles levels and tags. It would suffice (and probably make sense in general) to simply sort files alphabetically when all three sorting levels are identical. Using the track number is not just a workaround, it is how the sorting should be done. Sorting it alphabetically would totally ruin the sorting for all other type of tracks which we will certainly not implement. And all movements of a symphony have numbers AFAIK, be this for Haydn or Mozart or Mahler or Bruckner. So definitely not a workaround, but the logical way to sort them. Ditto for Operas, btw, even the libretti has numbers for the various scenes. I don't know where you get your music from, but my classical tracks all come form the CDs I own, so using the track number is how it works. *** This bug has been marked as a duplicate of bug 141991 *** |