rsekman / ddb_ows Goto Github PK

Steps to reproduce

1. Open the ddb_ows window
2. Open the playlist search window
3. Enter a search string
4. segfault

Probably this has to do with the search results internally forming a playlist?

There also seems to be a reference leak related to searches. Maybe same cause.

The following warnings are issued on exit

** (deadbeef:1151074): CRITICAL **: 23:07:42.142: static void Glib::DispatchNotifier::unreference_instance(Glib::DispatchNotifier*, const Glib::Dispatcher*):
assertion 'instance == notifier' failed

** (deadbeef:1151074): CRITICAL **: 23:07:42.142: static void Glib::DispatchNotifier::unreference_instance(Glib::DispatchNotifier*, const Glib::Dispatcher*):
assertion 'instance == notifier' failed

Seems to be an issue with Dispatcher lifetimes.

On loading the .ui file the warning

(deadbeef:1566955): GLib-GObject-WARNING **: 22:31:31.897: unable to set property 'text' of type 'gchararray' from value of type 'glong'

is issued. This seems to be related to one of the ListStore models, but I don't know the exact cause.

• Root
• Filename formats
• Cover art
• Delete unreferenced
• Playlists to sync -- requires way to persistently reference from ddb.
• Conversion options
• • Filetypes
• • Preset
• • DSP
• • Extension
• • Worker threads

This is because queue_jobs() runs in the Gtk main thread, so it blocks the main loop. Thus Gtk can't consume the pulse() messages at the same time. The solution is to dispatch execute in a separate thread. For thread safety these lines

The following warning is issued when opening the UI window

(deadbeef:2801592): Gtk-CRITICAL **: 14:20:53.876: IA__gtk_widget_map: assertion 'gtk_widget_get_visible (widget)' failed

Possibly related to the log expander. Does not seem to impact behaviour.

• Playlists
• Decoder plugins
• Encoder presets
• File name formatting
  • Preview
  • Validity indicator

Use inheritance to support

• CopyJob
• MoveJob
• ConvertJob
• DeleteJob? -- for removing files no longer present in ddb

When a previously synced source file has its metadata changed, a CopyJob will be selected, rather than a MoveJob, as the old destination is older than the source. This is correct, but the old destination should be cleaned up.

The program crashes when queueing many jobs quickly. As far as I can tell the crashes occur in TextBufferLogger accessing the GtkTextBuffer. There is a GTK warning about an invalid iterator. This should not happen because it is guarded by a mutex. I think it may be an issue with writing too much to the buffer too quickly, as it does not happen for small job sets.