Add support for filtering e.g. directories, by artist, only specific crates etc etc

Currently, all playlists and crates are copied even if there are no tracks in them (which can happen e.g. when filtering only a certain directory). We should simply skip these playlists and crates.

E.g. only download/upload differences between the tracklists

Mixync is tested on schema version 39, we may want to check that the user's version is recent enough too though.

To make it easier to evolve the portable database, we should consider integrating a migration framework such as alembic.

Add a store that talks to a remote Bassment server.

...and update the models, including e.g. PlaylistType accordingly.

For example:

• Back up the user's mixxxdb automatically
• Warn when about to override files in a dest music directory

• This direction requires caution, since we have to be careful to not overwrite any data by the
• Perhaps create a backup of the user's mixxxdb before doing anything via this tool to a mixxxdb.sqlite3.backup file in the same folder (Mixxx's config directory)?
• Only copy music to folders explicitly managed by this tool (i.e. mixync should not touch any Music directories previously configured by the user in Mixxx and instead create its own)
• Add ability to add a musiclib's folders only by reference?

Progress:

• Add --dest-root-dir
• Implement directory mapping (i.e. absolutize_directory)
• Implement track mapping (i.e. absolutize_track)
• Implement metadata (track, playlist, crate, ...) updating in MixxxStore
• #16
• Test it in a isolated environment

Ideally, we'd like to have uniqueness constraints in our portable DB and use upsert operations to insert rows (also we have to be careful since we use different ids in the portable DB compared to the local one)

A well-tested progress bar library like tqdm might produce prettier output and have less overhead than our own solution.

This issue tracks support for the mixxxdb's tables:

• library
• directories
• track_locations
• Playlists
• PlaylistTracks
• crates
• crate_tracks
• cues
• settings (primarily for the schema version)

Out of scope for now:

• LibraryHashes (shouldn't be necessary, but might be nice to have to ensure data integrity?)
• track_analysis (contains only waveform analysis, which usually can be generated on-the-fly pretty quickly, beatsgrids and keysgrids are stored under library.beats and library.keys, respectively)

Third-party libraries are also out of scope:

• itunes_library, itunes_playlist_tracks, itunes_playlists
• rhythmbox_library, rhythmbox_playlist_tracks, rhythmbox_playlists
• traktor_library, traktor_playlist_tracks, traktor_playlists

Once ready, there are a number of neat things we could do with such a portable archive:

• Provide ways to inspect/browse a mixxxlib generated by this tool
  • Perhaps via a CLI tool?
  • Or perhaps add a small app for HTTP/WebDAV-hosting a mixxxlib along with a web interface, letting the user create playlists/crates directly from the browser?

We should test the library on Windows, especially to make sure that the conversions behave correctly in the presence of non-slash file path separators etc. (the portable db should always use POSIX-style slashes, but during absolutization they should get converted back to platform-specific absolute paths and vice versa)

This could be useful to limit the sync to tracks that are already "organized" into a system of crates.

This could e.g. be useful to eliminate duplicates (merging the best quality version?), merge folders, regroup tracks by a predefined path scheme e.g. ${artist}/${album} etc.

Perhaps we could do this by writing mixync [source] [source], i.e. allowing the source as destination, and perhaps sugaring that to mixync [source] or mixync --inplace [source] (though we'd want to be careful to not perform any destructive operations, so perhaps making a backup would be a good idea?)

It would be cool if mixync could automatically write tags such as title/artist or even beatgrids etc. as Serato tags into the output files (though not by default, perhaps behind a flag?).

It would be cool if we could persist the id mappings locally to skip matching if we already matched the track in the past.

I.e. a "--by-reference" (or "--link") flag or similar

Mostly to avoid confusion if we introduce other local databases (e.g. a hypothetical local Bassment database) in the future.

• Set up project
• Set up basic CLI (mixync [source] [dest])
• Automatically locate the user's mixxxdb (cross-platform: Windows/macOS/Linux)
• Support mixync @local portable.musiclib
• #12
• Add dry run option