Bug 237300 - queue is lost after playlist was filtered
Summary: queue is lost after playlist was filtered
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: Playlist (show other bugs)
Version: 2.4-GIT
Platform: unspecified Linux
: NOR normal with 120 votes (vote)
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords: regression, release_blocker
: 258671 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-05-11 22:29 UTC by Janet
Modified: 2011-04-21 04:25 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.4.1


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Janet 2010-05-11 22:29:23 UTC
Version:           2.3.0.90 (using 4.4.3 (KDE 4.4.3), Debian packages)
Compiler:          cc
OS:                Linux (i686) release 2.6.33-3.slh.7-sidux-686

When I put some tracks into the playing queue and then temporarily filter my playlist to search for a specific song or artist the whole queue is lost after I switch back to full playlist view.
Comment 1 Sven Krohlas 2010-05-13 10:18:01 UTC
Holy shit, I can verify this. :/

The "show only matches" option has to be enabled.

regression? Did it work before?
Comment 2 James Dent 2010-06-01 08:04:45 UTC
I have just run into this problem upon upgrading from 2.3.0 to 2.3.1.
Comment 3 Balazs Fodor 2010-07-22 19:37:29 UTC
Bumped into this bug too in version 2.3.1!
Comment 4 Micah 2010-08-14 23:25:28 UTC
I also verified this, its pretty annoying =P
Comment 5 Janet 2010-08-16 01:40:56 UTC
Even more strange: the queue doesn't get lost completely. The songs are not marked anymore with that green circle, the playing order is as if there is nothing in the queue - but when you rightclick on a track that previously was in the queue the context menu stil offers to *remove* the track from queue and you have to first remove the track before you can re-add it...
Comment 6 Alan Ezust 2010-08-29 18:15:58 UTC
me too!
Comment 7 Alan Ezust 2010-08-29 18:24:51 UTC
Looks like a duplicate to me.

*** This bug has been marked as a duplicate of bug 231324 ***
Comment 8 Alan Ezust 2010-08-29 18:32:26 UTC
oops. I didn't mean to mark THIS as a dupe of THAT, but the other way around. sorry!
Comment 9 Alan Ezust 2010-08-29 18:33:57 UTC

*** This bug has been marked as a duplicate of bug 223877 ***
Comment 10 Janet 2010-08-30 03:47:12 UTC
Is it really a duplicate? IMHO not. IMHO Bug 223877 is about playing the queue *while* the playlist is filtered, this one is about a loss of the queue *after* the playlist was filtered temporarily for searching for songs to add to the queue. It is keeping the queue and getting it back when the filter is off again. And about a very inconsistent behaviour #5 with a lost queue for playing but songs still pretend to be in it.
Comment 11 Myriam Schweingruber 2010-08-30 10:09:35 UTC
Indded, this is not a duplicate.
Comment 12 Kai Uwe Broulik 2010-09-09 00:53:43 UTC
I just found that queue feature and it‘d be soo nice if it didn‘t lose filtered songs.
Comment 13 Kai Uwe Broulik 2010-09-09 01:00:57 UTC
Addition: it just loses songs that are not displayed because of the filter. If I add “example” to queue and filter the playlist for “exa” it is still in queue, if I accidently type “exs” the selection is gone, although it offers you to remove it from queue. But neither that green bulb is displayed nor is the song played next. It just picks the next song from playlist.
Comment 14 Shane O'Donnell 2010-09-21 22:01:44 UTC
I can confirm the bug still exists in 2.3.1.90
Comment 15 Myriam Schweingruber 2010-12-13 10:14:35 UTC
*** Bug 258671 has been marked as a duplicate of this bug. ***
Comment 16 Matt 2010-12-16 22:47:40 UTC
Amarok 2.4beta1 still has this bug.  When using the playlist to search for items to add to the queue, it clears the previous queue.  However, items that were marked as queued are no longer marked, so it appears that half of the bug is fixed.
Comment 17 Andreas Hartmetz 2010-12-26 09:49:53 UTC
commit 9aba000de6bfa1ba5852aaa81391b833ae1af269
branch master
Author: Andreas Hartmetz <ahartmetz@gmail.com>
Date:   Sun Dec 26 09:45:11 2010 +0100

    Don't dequeue tracks hidden from view while searching.
    There was code doing this entirely on purpose. Removing it might break
    some scenario where tracks are actually supposed to be dequeued,
    altghough I can't think of one.
    
    BUG: 237300

diff --git a/src/playlist/navigators/TrackNavigator.cpp b/src/playlist/navigators/TrackNavigator.cpp
index b27cf8f..1b071f8 100644
--- a/src/playlist/navigators/TrackNavigator.cpp
+++ b/src/playlist/navigators/TrackNavigator.cpp
@@ -38,8 +38,6 @@ Playlist::TrackNavigator::TrackNavigator()
     //   Ignore SIGNAL layoutChanged: we don't need to know when rows are moved around.
     connect( m_model->qaim(), SIGNAL( modelReset() ), this, SLOT( slotModelReset() ) );
     //   Ignore SIGNAL rowsInserted.
-    connect( m_model->qaim(), SIGNAL( rowsAboutToBeRemoved( const QModelIndex&, int, int ) ),
-             this, SLOT( slotRowsAboutToBeRemoved( const QModelIndex&, int, int ) ) );
 }
 
 void
@@ -108,17 +106,6 @@ Playlist::TrackNavigator::slotModelReset()
     m_queue.clear();    // We should check 'm_model's new contents, but this is unlikely to bother anyone.
 }
 
-// This function can get called thousands of times during a single FilterProxy change.
-// Be very efficient here! (e.g. no DEBUG_BLOCK)
-void
-Playlist::TrackNavigator::slotRowsAboutToBeRemoved( const QModelIndex& parent, int startRow, int endRow )
-{
-    Q_UNUSED( parent );
-
-    for (int row = startRow; row <= endRow; row++)
-        dequeueId( m_model->idAt( row ) );
-}
-
 quint64
 Playlist::TrackNavigator::bestFallbackItem()
 {
diff --git a/src/playlist/navigators/TrackNavigator.h b/src/playlist/navigators/TrackNavigator.h
index b8b09a1..4456164 100644
--- a/src/playlist/navigators/TrackNavigator.h
+++ b/src/playlist/navigators/TrackNavigator.h
@@ -112,7 +112,6 @@ namespace Playlist
 
         private slots:
             void slotModelReset();
-            void slotRowsAboutToBeRemoved( const QModelIndex& parent, int start, int end );
 
         protected:
             /**
Comment 18 Kai Uwe Broulik 2011-03-23 17:30:04 UTC
Yep, in 2.4.1 Beta 1 again shows this behavior, tracks queued are lost after you filtered the view. This is just soo annoying again, so I will revert to 2.4. At least 2.4.1 doesn‘t crash every 2 minutes.
Comment 19 Myriam Schweingruber 2011-03-24 00:04:29 UTC
Reopening based on comment #18
Comment 20 Kai Uwe Broulik 2011-03-25 16:00:01 UTC
Maybe it has something to do with the fact that now (or in 2.4 already?) the playlist filter does not match 1:1 now but if you enter “example song” it will find „The Example” by „The Song Makers” for example.
Comment 21 Andreas Hartmetz 2011-03-25 22:09:27 UTC
Git commit 81fd6990a4684202571baebc92415ccfbda62651 by Andreas Hartmetz.
Committed on 25/03/2011 at 22:03.
Pushed by ahartmetz into branch 'master'.

Don't dequeue tracks hidden from view while searching, second try.

This time while keeping bug 263308 closed.
We remove a track from the queue when it is removed from the *bottom*
model in the model stack, i.e. permanently.

BUG: 237300
CCBUG: 263308

M  +4    -2    src/playlist/navigators/TrackNavigator.cpp     

http://commits.kde.org/amarok/81fd6990a4684202571baebc92415ccfbda62651
Comment 22 Alan Ezust 2011-04-21 04:25:18 UTC
Tried the latest git and it is working now.