Bug 145661

here's flac_tracks.cue 
REM GENRE Classical
REM DATE 2003
REM DISCID A4114A0B
REM COMMENT "ExactAudioCopy v0.95b4"
PERFORMER "Felix Weingartner, VPO, LPO"
TITLE "Ludwig van Beethoven - Symphonies No. 7 & 8, Excerpts from 'Egmont'"
FILE "01 - [op. 84] I. Overture.flac" WAVE
  TRACK 01 AUDIO
    TITLE "[op. 84] I. Overture"
    PERFORMER "Felix Weingartner, VPO, LPO"
    INDEX 01 00:00:00
FILE "02 - [op. 84] III. Entr'acte No. 2 (Larghetto).flac" WAVE
  TRACK 02 AUDIO
    TITLE "[op. 84] III. Entr'acte No. 2 (Larghetto)"
    PERFORMER "Felix Weingartner, VPO, LPO"
    INDEX 01 00:00:00
FILE "03 - [op. 84] VII. Claerchen's Tod.flac" WAVE
  TRACK 03 AUDIO
    TITLE "[op. 84] VII. Claerchen's Tod"
    PERFORMER "Felix Weingartner, VPO, LPO"
    INDEX 01 00:00:00
  TRACK 04 AUDIO
    TITLE "[op. 92] I. Poco sostenuto - Vivace"
    PERFORMER "Felix Weingartner, VPO, LPO"
    INDEX 00 02:49:02
FILE "04 - [op. 92] I. Poco sostenuto - Vivace.flac" WAVE
    INDEX 01 00:00:00
  TRACK 05 AUDIO
    TITLE "[op. 92] II. Allegretto"
    PERFORMER "Felix Weingartner, VPO, LPO"
    INDEX 00 11:53:15
FILE "05 - [op. 92] II. Allegretto.flac" WAVE
    INDEX 01 00:00:00
  TRACK 06 AUDIO
    TITLE "[op. 92] III. Presto"
    PERFORMER "Felix Weingartner, VPO, LPO"
    INDEX 00 08:10:25
FILE "06 - [op. 92] III. Presto.flac" WAVE
    INDEX 01 00:00:00
  TRACK 07 AUDIO
    TITLE "[op. 92] IV. Allegro con brio"
    PERFORMER "Felix Weingartner, VPO, LPO"
    INDEX 00 08:09:22
FILE "07 - [op. 92] IV. Allegro con brio.flac" WAVE
    INDEX 01 00:00:00
  TRACK 08 AUDIO
    TITLE "[op. 93] I.Allegro vivace e con brio"
    PERFORMER "Felix Weingartner, VPO, LPO"
    INDEX 00 06:47:25
FILE "08 - [op. 93] I.Allegro vivace e con brio.flac" WAVE
    INDEX 01 00:00:00
  TRACK 09 AUDIO
    TITLE "[op. 93] II. Allegretto scherzando"
    PERFORMER "Felix Weingartner, VPO, LPO"
    INDEX 00 07:18:38
FILE "09 - [op. 93] II. Allegretto scherzando.flac" WAVE
    INDEX 01 00:00:00
  TRACK 10 AUDIO
    TITLE "[op. 93] III. Tempo di Menuetto"
    PERFORMER "Felix Weingartner, VPO, LPO"
    INDEX 00 03:38:52
FILE "10 - [op. 93] III. Tempo di Menuetto.flac" WAVE
    INDEX 01 00:00:00
  TRACK 11 AUDIO
    TITLE "[op. 93] IV. Allegro vivace"
    PERFORMER "Felix Weingartner, VPO, LPO"
    INDEX 00 04:12:50
FILE "11 - [op. 93] IV. Allegro vivace.flac" WAVE
    INDEX 01 00:00:00


after each track is played the title changes to [op. 93] IV. Allegro vivace.flac wich is not in the tag of any of the files.the directory also has some other cue files (flac_image.cue wav_image.cue wav_tracks.cue)

I have this same problem.  This has been an issue for quite some time, as was explained here nearly a year ago:
http://amarok.kde.org/forum/index.php/topic,13794.0.html

I don't know why amaroK insists on setting the details for the currently playing track to the last track found in any cuesheet that happens to be in the same directory, but needless to say it's very annoying.  In order to tell what song is actually playing, I need to right-click on the song, click Edit Track Information, and look at the Location field (which, hopefully, is not truncated due to length).

Can anyone explain why amaroK behaves this way with CUE files?  Perhaps it was coded for album image files (eg., single FLAC containing all tracks on an album) and just doesn't take into account split file albums w/ CUE sheets?

Regardless, though, has anyone looked into fixing this?  This is one of just two major issues with amaroK that's preventing it from being the perfect media player.

(The other, obviously less-important issue was brought up here: http://amarok.kde.org/forum/index.php/topic,11194.0.html.  Though this is a relatively minor issue, it does have the effect of completely preventing me from using amaroK to edit any metadata in my music.)

Created attachment 23409 [details]
contextbrowser patch

I did some digging through the source code and sort-of figured out what's happening,  In contextbrowser.cpp, at line 698 (in version 1.4.8), amarok searches for and begins looping through all *.cue files found in the currently playing file's firectory.  For each file, it then loops through each line, search for a FILE line that matches the filename of the playing file.  If that's found, it then calls CueFile::load() in cuefile.cpp (line 66).

So far so good.  However, the CueFile::load() function appears to be where things go south.  If I understand this correctly (my C++ is VERY rusty), the function loops through every entry in the CUE file and "inserts" the data using the insert() function (eg., line 132).  I don't know exactly what insert() does, but it appears to have the effect of updating the file info in the context browser.  Since this loop cycles through ALL tracks listed in the CUE file, this info is repeatedly updated until it hits the last track, at which point it does a final update and then it's finished.  The result is that, as has been previously reported, the info about currently playing track is reset to the info about the last track listed in the CUE file.

I can think of two ways to fix this:

1) Don't change the track information of a currently playing song
2) If you're going to change the track information, change it to the CORRECT information

Option 1 makes the most sense to me, as if the metadata has already been loaded from the actual song file then there's absolutely no need to update it with the more limited information found in the CUE file.  On the other hand, I'm sure this functionality wouldn't have been added to begin with if there wasn't some situation where this behavior is useful, possibly making 2 the more "correct" option; it just conflicts with other usage.

While a proper solution would need to be implemented by someone who's actually competent with C++, I hacked together a simple solution that makes it work for me.  I attached the diff output containing the one line change.

Basically, my thinking here is that if the Artist, Album, and Title information of the given track is all empty, then obviously this information isn't contained in the track metadata (VORBISCOMMENT, ID3, etc.).  In this case, it makes sense to go ahead and query the CUE file.  On the other hand, if any of those attributes ARE present, then the proper metadata is already available and we should NOT query the CUE file.

Thoughts?  Is this something that can be added to the next version?

One other note about the code:  I'm using  '== ""' instead of '.isNull()' because the isNull() approach didn't work for the title tag.  Even if there was no title, isNull() returned false for .title().  The attached code works fine for all three test cases.

Amarok 1.4.x is in bugfix-only mode as development is focused on Amarok 2. Unfortunately your bug is unlikely to be fixed in Amarok 1, as Amarok developers do not have the resources for it and risk of regression would be too high. I am therefore moving your request to Amarok 2. Thank you for your report.

Closing, because this no longer applies to Amarok 2. The playlist works too differently.

So is this actually fixed in version 2?  or are you stating that the playlist functionality differs to the point that this specific patch is no longer applicable?

If the problem has been fixed, then I agree that this bug should be closed.  However, if the issue remains but my suggested patch is no longer applicable, then this bug should not be closed as the problem would still remain.

1) Patch no longer applies.
2) Cue support is not implemented at all at this point.
3) Amarok 2 is _totally_ different in that regard.