Bug 237300

Holy shit, I can verify this. :/

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

regression? Did it work before?

I have just run into this problem upon upgrading from 2.3.0 to 2.3.1.

Bumped into this bug too in version 2.3.1!

I also verified this, its pretty annoying =P

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...

me too!

Looks like a duplicate to me.

*** This bug has been marked as a duplicate of bug 231324 ***

oops. I didn't mean to mark THIS as a dupe of THAT, but the other way around. sorry!

*** This bug has been marked as a duplicate of bug 223877 ***

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.

Indded, this is not a duplicate.

I just found that queue feature and it‘d be soo nice if it didn‘t lose filtered songs.

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.

I can confirm the bug still exists in 2.3.1.90

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

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.

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:
             /**

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.

Reopening based on comment #18

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.

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

Tried the latest git and it is working now.