After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 547213 - Unespected resume after Play Queue ends
Unespected resume after Play Queue ends
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: Other Extensions
git master
Other Linux
: Normal normal
: 1.4
Assigned To: Banshee Maintainers
Banshee Maintainers
: 548391 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-08-10 23:22 UTC by Dionisio E Alonso
Modified: 2009-03-30 14:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dionisio E Alonso 2008-08-10 23:22:30 UTC
When the queue of playing songs reaches its end, the return of the reproduction is in the first item of the last filtered view.

This is a wried behavior for a playing queue. It would be more accurate to return to the following song in the last filtered view, that was going to be reproduced as next before the jump to the Play Queue instead, so not repeating the entire filtered view, but continuing with the reproduction. This is the most common way of treating playing queues.

Example of the current behavior:

I have the following filtered list:
1. song 1
2. song 2
3. song 3

While listening "song 2" I en-queue "song A" so after the reproduction of "song 2" I hear it, but, when "song A" finishes the reproductions returns to "song 1" while I would really expect to be "song 3" instead.
Comment 1 Michael Martin-Smucker 2008-09-24 22:49:00 UTC
I think I can confirm this (at least I think the bug that I was about to report would have been a dupe of this).  If you start listening to the Play Queue anywhere other than the first song, it jumps to the first song as soon as the song you're listening to finishes instead of continuing down the list.  Strange.
Comment 2 Michael Martin-Smucker 2008-09-24 23:00:22 UTC
Nevermind, I think my observation was a separate issue.  I do think that Bug 548391 may be a dupe of this, though.
Comment 3 Andrew Conkling 2008-09-25 17:59:50 UTC
*** Bug 548391 has been marked as a duplicate of this bug. ***
Comment 4 Andrew Conkling 2008-09-25 18:00:48 UTC
Good catch Michael.

(From bug 548391)
> An additional case: I am playing from another source (e.g. Music Library, a
> playlist).
> 1. I add something to the play queue.
> 2. When that song is done, the play queue starts.
> 3. When the Play Queue is finished, playback should return to my previous
> source (and pick up at the right song).
> 
> In general, the play queue should remember what was happening when it started
> and return there when finished.
Comment 5 Gabriel Burt 2008-10-09 19:41:24 UTC
I committed part of the fix to this problem - if you weren't playing from the prior playback source, then when the queue is empty, it will set it as the playback source but it _won't_ play from it.
Comment 6 Gabriel Burt 2008-10-09 20:14:15 UTC
And committed the fix to return playback to the song after the one we left off from.
Comment 7 Andrew Conkling 2008-10-09 20:16:40 UTC
Fantastic; thanks!
Comment 8 Andrew Conkling 2009-03-30 14:44:39 UTC
(In reply to comment #6)
> And committed the fix to return playback to the song after the one we left off
> from.

For posterity, this is what Banshee will do in these two cases.
Case 1: Banshee stopped, items added to the Queue:
1. When you press Play, Banshee will play items from the Queue.
2. When the Queue is empty, playback will stop.

Case 2: Playback from a source (e.g. Music Library, a playlist), items added to the queue:
1. When the current song finishes, playback switches to the Queue.
2. When the Queue is empty, playback will return to the previous source.

To stop playback when using the Queue, the only way I know to do that is to make sure Banshee is stopped before starting the Queue, which (for me) has meant restarting Banshee. Pausing will not work, because the playback source is still marked "active" when the Queue takes over.