All concurrency from other threads should pass through the viewContext's
performBlock or performBlockAndWait functions, and no other way. So now,
all access to Core Data is either happening on the main thread, or by
using these code blocks, all of which will wait for their access to
proceed.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
This should fix up potential locking issues with maintaining a copy of
the results set while certain other background actions may happen, such
as the player updating play counts while playing.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Apparently we need this to prevent Core Data from stomping on itself
when another thread accesses it.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
It was previously crashing horribly on adding search results. This makes
it actually functional, and renders it using a view-based table instead.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Refine the global variable usage, eliminating double underscore prefixes
and trusting that static global variables will exist in the object where
the class was created. Got rid of that nasty NSApplication extension
hack that was previously in use.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Fixed the implementation to work correctly with the new Core Data
storage system. Tracks will be garbage collected later.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Completely rewrite the playlist storage once again, this time with a
much faster Core Data implementation. It still uses a little magic for
Album Artwork consolidation, but string consolidation doesn't seem to be
needed to reduce the disk storage size. Works much faster than my silly
implementation, too.
Old implementations are still kept for backwards compatibility with
existing playlists.
Signed-off-by: Christopher Snowhill <kode54@gmail.com>
Christopher Snowhill