This is the thread-safety issue I was talking about the other day. It seems a draw operation is being triggered from a thread other than GTK+'s main thread (which is the same default thread of the app). This happens after calling LibraryManager.update_media(), so we must check that no UI handler is fired from a separate thread.
// Playlist.update_library() will fire the playlists' media_added() and media_removed() signals, which
// trigger an update in PlaylistViewWrapper (this is the source of the redraw).
Threads.add (() => {
lock (_smart_playlists) { foreach (var p in smart_playlists ()) { lock (_media) { p.update_library (media ()); }
}
} Idle.add ((owned) callback);
});
yield;
}
We should use Idle.add instead of Threads.add, which is not equivalent, but we must not do this from other thread anyway.
This is the thread-safety issue I was talking about the other day. It seems a draw operation is being triggered from a thread other than GTK+'s main thread (which is the same default thread of the app). This happens after calling LibraryManager. update_ media() , so we must check that no UI handler is fired from a separate thread.
The code to blame is the following:
LINE 587 - LibraryManager. vala:
private async void update_ smart_playlists _async () { smart_playlists _async. callback;
SourceFunc callback = update_
// Playlist. update_ library( ) will fire the playlists' media_added() and media_removed() signals, which
foreach (var p in smart_playlists ()) {
lock (_media) {
p.update_ library (media ());
}
Idle. add ((owned) callback);
// trigger an update in PlaylistViewWrapper (this is the source of the redraw).
Threads.add (() => {
lock (_smart_playlists) {
}
}
});
yield;
}
We should use Idle.add instead of Threads.add, which is not equivalent, but we must not do this from other thread anyway.