Bug 223877

Summary: Queued tracks don't play if filtered out of the playlist
Product: [Applications] amarok Reporter: Scott <wshambaugh>
Component: PlaylistAssignee: Amarok Developers <amarok-bugs-dist>
Status: RESOLVED INTENTIONAL    
Severity: normal CC: alan.ezust, bugzilla, carsten.schlipf, grosser.meister.morti, kfunk, langstr, nhn, rlongland, teo
Priority: NOR    
Version: 2.2.2   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Scott 2010-01-23 02:49:03 UTC
Version:           2.2.2 (using KDE 4.3.4)
OS:                Linux
Installed from:    Archlinux Packages

If I queue several tracks, and filter my playlist to search for more songs, the next queued track will not play if it is filtered out. This is annoying, especially if I am queuing a large number of tracks and this happens several times while I am looking. Queued tracks should be independent of a playlist's filter - the manual action needed to mark them should indicate their high priority.
Comment 1 Kevin Funk 2010-01-28 14:53:38 UTC
In my opinion it would be really better to have something like a search window instead of filtering the active playlist. Scenario:
1. Press some short cut, e.g. "J" for jump
2. New view pops up (current playlist as entries)
3. Enter search terms in that view
4. View gets filtered according to the terms
5. Click on the song you wish -> View closes -> Active playlist starts selected song

-> The current playlist isnt modified at all, this solves many problems. Filtering causes many problems, not only wrt queue management-
Comment 2 Sven Krohlas 2010-03-19 17:26:45 UTC
*** Bug 231324 has been marked as a duplicate of this bug. ***
Comment 3 Sven Krohlas 2010-03-19 17:31:20 UTC
I'm unable to reproduce it in git master.

There have been a lot of changes to the track progression code. Reporter and dupe-reporter: could you please retest?
Comment 4 Carsten Schlipf 2010-03-19 17:38:37 UTC
Will this be part of Amarok 2.3.1? I will retest it then.
Comment 5 Sven Krohlas 2010-03-19 17:44:30 UTC
Yes, if nothing goes wrong.
Comment 6 Scott 2010-03-23 14:33:08 UTC
I can reproduce this bug in 2.3.0 - will try again when 2.3.1 comes out.
Comment 7 langstr 2010-05-05 11:59:55 UTC
Discussion on the mailing list:

  http://mail.kde.org/pipermail/amarok-devel/2010-May/007079.html
  http://mail.kde.org/pipermail/amarok-devel/2010-May/007084.html

I personally feel that this bug report is a reasonable request, but consensus was to keep current behaviour.
Comment 8 Mathias Panzenböck 2010-05-05 13:54:30 UTC
Then I recommend to change the text from "Search playlist" to "Filter playlist" after the string freeze is over.
Comment 9 Carsten Schlipf 2010-05-06 06:43:57 UTC
"Consensus" from who? I can't see any comment that votes for keeping the current behavior. Personally I don't see any sense why the track filter should override the play queue.

I have the feeling that Amarok develops into the wrong direction since a while but this is finally my personal proof. :-(
Comment 10 langstr 2010-05-06 11:07:27 UTC
Consensus quotes:
 - "I'm not convinced that it needs to be changed"
 - "The current behaviour is at least consistent"
 - "Agreed."

That seems abundantly clear to me?

I already got slapped on the wrist earlier for pleasing someone's innocent-seeming request without explicit approval on the mailing list. If you want it done, argue with them there and change their mind.

--
W.r.t. Amarok direction: I don't disagree, but there's only one constructive way to react to that: become a contributor & push for the things you personally find important. That's what I did.

I too tried to stay on Amarok 1 as long as I could. However, that became untenable, and Amarok 2 got more usable with every release. So I downloaded the source code and fixed the problems in Amarok 2 that annoyed me personally. It won't get better if you don't put some work in it.

You may know the quote: "Criticizing an Open Source project for their level of progress is akin to criticizing someone else for not giving enough to charity, while giving none yourself." (Ian Clarke)
Comment 11 Richard Longland 2010-05-26 20:41:32 UTC
So will "search playlist" be changed to "filter playlist"? This "search" that is actually a filter confused me right up until I read this bug report!
Comment 12 Alan Ezust 2010-08-29 18:23:23 UTC
If the "filter" filtered out everything BUT queued tracks, and showed them even if they did not match the filter string, this would make everyone happy, and we could use amarok the way we want (search in a big list, queue, search for something else, queue, etc). 

Why would anyone NOT want to see something they just queued after filtering ?
Comment 13 Alan Ezust 2010-08-29 18:33:57 UTC
*** Bug 237300 has been marked as a duplicate of this bug. ***
Comment 14 Alan Ezust 2010-08-29 18:36:12 UTC
In my opinion, the filter behavior is fine, but we just need to add an exception to show the queued tracks ALSO.

I guess there is at least ONE person here who would NOT want to see/hear recently queued tracks while filtering for something else. But my vote is in the exact opposite direction.
Comment 15 Janet 2010-08-30 04:02:54 UTC
I use the filter to search the playlist for songs to queue. So losing the queue after the filter is off again makes it useless. The playlist needs something to search in it for adding songs from it to the queue. And that is the filter. So the queue needs to be kept while the playlist is filtered temporarily. Especially as you cannot filter the playlist for more than one artist aynmore using the queue plus filter is a kind of workaround for that. But that workaround does only work when the queue is kept while the playlist is temporarily filtered and expanded again. E.g. first I filter for artist A, queue all those songs, filter for artists B, queue all those songs, switch filter off to hear all songs from artist A and B in the playlist - but queue is gone... Cannot be...

BTW after filtering the tracks are still in the queue somehow, they are just not shown as queue and are not usable as queue, but you cannot add them to queue, you have to remove them before. Very confusing. Cannot be the intended behaviour. See Bug 237300.