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 331732 - playlist entries do not always get removed
playlist entries do not always get removed
Status: RESOLVED FIXED
Product: rhythmbox
Classification: Other
Component: playback
HEAD
Other All
: Urgent major
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-19 01:51 UTC by Christian Kirbach
Modified: 2006-03-11 04:01 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
delay rhythmdb entry-deleted signal until commit (1.44 KB, patch)
2006-03-10 14:45 UTC, Jonathan Matthew 		committed Details | Review

Description Christian Kirbach 2006-02-19 01:51:19 UTC 
1. purge playlist. add two files
2. play the first entry.
3. right-lick it and select "eleminate"

playback skips to the next song but the entry is not visibly removed.
this leads to a crash when the first entry is played again and attempted to eleminate.
Comment 1 Alex Lancaster 2006-02-19 03:16:32 UTC 
Can't duplicate this with HEAD as of today.  I suspect this is a duplicate of bug #131150 which just got fixed today.  Marking as such.  Re-open if this still isn't fixed.

*** This bug has been marked as a duplicate of 131150 ***
Comment 2 Christian Kirbach 2006-02-19 15:00:13 UTC 
Hmm I still can reproduce it
Comment 3 Alex Lancaster 2006-02-19 16:40:26 UTC 
With CVS HEAD?  What do you mean by eliminate, you mean Remove or Move to Trash?  I can't duplicate this.
Comment 4 Christian Kirbach 2006-03-06 15:49:05 UTC 
yes with CVS head. still there with cvs build from today.

I mean "remove from playlist" (the minus symbol)
Comment 5 Jonathan Matthew 2006-03-10 14:45:46 UTC 
Created attachment 61038 [details] [review]
delay rhythmdb entry-deleted signal until commit

This was happening because the entry was being deleted while it still had outstanding changes.  The deletion signal was emitted immediately (removing the entry from all sources), then the changes were emitted on the next rhythmdb_commit, which re-added the entry to any sources it had been in.  This patch delays the entry deleted signal until the next rhythmdb_commit, like all other changes.

All rhythmdb_entry_delete calls except one already had rhythmdb_commit calls immediately afterwards.  This patch adds the missing commit.
Comment 6 James "Doc" Livingston 2006-03-11 00:35:15 UTC 
Looks good to me.
Comment 7 Jonathan Matthew 2006-03-11 04:01:32 UTC 
Committed, with some small changes to add a reference on entries in the deleted-entries list, and free the list in rhythmdb_commit_internal.