rhythmdb_entry_delete_by_type () is out of sync with other rhythmdb operations
Please refer to the following podcast search results screenshots:
1. Entries in episode view even after search is cleared.
2. Duplicate entries in episode view.
This issue is reproducible when selecting search results in quick succession. Mouse Up + Mouse Down arrow on BBC
search results. The issue appears to be that all rhythmdb update operations ( other than rhythmdb_entry_delete_by_type ()
) follow a streamlined mechanism:
RhythmDB processing order:
db->priv->changed_entries
db->priv->added_entries
db->priv->deleted_entries
g_signal_emit (G_OBJECT (db), rhythmdb_signals[ENTRY_CHANGED], 0, entry, emit_changes);
g_signal_emit (G_OBJECT (db), rhythmdb_signals[ENTRY_ADDED], 0, entry);
g_signal_emit (G_OBJECT (db), rhythmdb_signals[ENTRY_DELETED], 0, entry);
rhythmdb_entry_delete_by_type ()
does a plain remove entry, ignoring the above ordering. This causes incorrect ordering of events triggering delete to be called on rhythmdb entries, prior to actual addition. This causes the query-model of the podcast search post results to be populated with entries after a no-op rhythmdb_entry_delete_by_type ()
. Successive rhythmdb_entry_delete_by_type ()
calls even when executed in the correct order, causes the corresponding entries to be deleted from rhythmdb and the podcast query-model, but the stale entries which were inserted previously as described still remain in the podcast query-model forever, until a rhythmbox restart.