Move database transactions from the GUI thread to a separate thread

Can you guys confirm that it's some how related to the 'play count' of a track ?
Every time I hit play/stop on a track, some time later ~2/3 sec I got the stalling issue (including the first one).
And I see play count increase of one ... if the same track is loaded several times in different decks count go crazy like +5 every time I hit play/stop.

Note: creating thread is not always the good way to manage that ... do not forget that sqlite can lock disk access and indirectly blocks other thread/processes.

The play-count increasing is a bug caused by the new setlog code ...
probably not related to this.

On Mon, Apr 30, 2012 at 1:03 PM, Thomas Vincent
<email address hidden>wrote:

> Note: creating thread is not always the good way to manage that ... do
> not forget that sqlite can lock disk access and indirectly blocks other
> thread/processes.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/991717
>
> Title:
> Move database actions form the GUI thread into a seperate one
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/991717/+subscriptions
>

Uwe, did you want to fix this for 2.2?

Thanks for taking up this difficult task that has been waiting for years!

Uwe, before you get too far into this, let's think through how it should work with the library redesign and nested crates branches to save unnecessary work to merge them in the end. I think it might be a good idea to get the nested crates branch merged to the library redesign branch first, then you can begin your refactoring work from the library redesign branch. If I remember correctly, the only critical issue blocking the nested crates branch from being merged to library redesign branch is ensuring that the database schema updates work starting from a fresh database.

I no longer consider this a reachable goal for 2.2.

Isolating the database interactions into separate threads would only be the first step. Further down the road we need to integrate external providers like streaming services which are completely separate remote services. So why not define a portable IPC/RPC API right from the start and and implement that API for both a local service provider using an SQLite database and optionally for external providers?

Of course, an evolutionary approach for migrating the current design towards the final goal would be preferable. Unfortunately I suppose that is not worth the effort since we don't have enough resources for that. Exhausted and burnt from preceding and very painful refactorings I decided that I will not perform this task as originally intended.

The tightly integrated, inflexible, and inextensible library management in Mixxx is IMHO already beyond repair. Migrating a fat desktop application with a simplified Excel/Access-style UI towards a modern, modular, extensible, cloud-aware, multi-device, multi-frontend family of apps(!) will require a substantial redesign.

Though not all hope is lost. As an exercise I started working on something new. In Rust. It is too early for disclosing and publishing any detailed information about this private project.

What I have is an initial domain model for collections of tracks:
- allows identification of tracks across multiple collections
- prepared for synchronization of external metadata resources. e.g. file tags or cloud databases
- supports multiple values for selected attributes
- provides both pre-defined and custom tagging schemes (not to be confused with file tags)
- has built-in serialization for various formats (JSON, BSON, CBOR, Bincode, MessagePack, ...)

I have defined a corresponding hybrid SQL schema to be used by a local service that considers fast access, scalability, consistency, and powerful querying capabilities as substantial requirements. Right now this is just a disconnected schema. No code has been written for mapping the in-memory domain model, yet.

The to-be-defined polyglot IPC/RPC/REST API should support asynchronous communication patterns and must be versatile enough to integrate both external providers like streaming services in addition to a local/remote service instance.

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/6384