GNOME Bugzilla – Bug 354241
playback stops suddenly when automatic playlist regenerates
Last modified: 2018-05-24 11:50:05 UTC
Please describe the problem: very funny bug: i set the "last added" playlist to "added in the last 4 weeks" now i sit here, listen to music and suddenly, the current song stops and the first song of the "last added" playlist starts. as it turns out, i added the song that stopped playing exactly 4 weeks ago the same minute of the day. so the song that i added (let's say) on august 1st, 10 a.m. will play when i start it on august 29th, 9:59 am but will stop one minute later because the song drops from the "last added" list. it should play the song to the end in my opinion... Steps to reproduce: 1. set the "last added" playlist to "added in the last 1 week" 2. add a song on monday 09:00 a.m. 3. play the song the next monday at 08:59 a.m. -> it will stop as soon as it turns 09:00 and the playlist refreshes Actual results: the song stops and the first song of the playlist starts. Expected results: the song should not stop. after it is finished, the playlist should stop or play the first (in this case, the newest song of the list) Does this happen every time? Other information:
This may have been fixed in CVS with this change, could you recheck with CVS to see if it's still there? 2006-07-18 Jonathan Matthew <jonathan@kaolin.wh9.net> * rhythmdb/rhythmdb-query-model.c: (rhythmdb_query_model_set_property), (rhythmdb_query_model_reapply_query_cb): Ignore old query == new query case. Fixes auto playlists with time-relative queries.
No, this is still an issue. A simpler way to reproduce it: create an automatic playlist with a 'rating = ***' criterion, play a track, then change its rating. It'll disappear from the playlist and we'll skip to the next track.
Created attachment 72486 [details] [review] possible fix This moves the playing-entry-removed handling from the query model's row-deleted signal to the db's entry-deleted signal, so it only triggers when the playing entry is completely removed from the database. It seems a bit weird when you remove the playing entry from a static playlist, but otherwise seems OK.
Seems to work fine for me. The G_OBJECT casts shouldn't be needed and just add noise.
Looks sane to me too. I seem to recall another bug about this, but I can't find it.
This appears to do slightly bad things to the random (and maybe shuffle) play orders.
*** Bug 508783 has been marked as a duplicate of this bug. ***
This has been biting me for a while. I have an autoplaylist for unrated songs, and when I rate a song it should of course be removed from the list, but I don't necessarily want it to stop playing. I tried this patch out and it's doing the trick for me. Given how long it's been around, can this be applied at some point?
*** Bug 589874 has been marked as a duplicate of this bug. ***
*** Bug 589876 has been marked as a duplicate of this bug. ***
*** Bug 603456 has been marked as a duplicate of this bug. ***
*** Bug 610466 has been marked as a duplicate of this bug. ***
*** Bug 627025 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/239.