Database Access: endjine (Rust)

Just playing around on a rainy Sunday:

The GitHub repo includes a runnable example.

A starting point, no further plans yet. Contributions are welcome.

3 Likes

This is like some electronic version of Charades - what does it do?

Could you tell me what this does? Post a video or at least say something? I don’t understand!

Access to the SQLite database of Engine DJ using Rust. The library offers 3 functions that are used by the CLI example:

As a result the size of a database with ~5000 tracks and ~3500 album art images shrinks from over 350 MB to less than 90 MB.

!!! Experimental and only for developers !!!

2 Likes

It’s pretty cool to see this written in Rust :slight_smile:

One issue I plan to resolve for myself: Automated creation and sync of Smartlists derived from a custom config.

Example: Parse semicolon-separated multi-genre tags from the track genre field and maintain Smartlists for each existing, individual genre. The built-in genre browser is useless for me.

The internal rules are stored as JSON in a single column, independent of the database schema. Rules cannot be nested and you could only use either ANY or ALL in a single Smartlist. This is a major restriction for a tag based organization system.

As a workaround I created many different Smartlists manually. It’s a tedious task to keep this zoo of Smartlists and the folder structure up-to-date.

Hopefully, in the future Engine DJ supports more advanced rules: https://community.enginedj.com/t/and-or-not-etc-operators-in-smartlists/54094

So cool.

To be clear, Engine DJ desktop and Engine OS (players) don’t choke on having the images as JPG? Do either convert them back to PNG either in toto or when a track is loaded for edits?

Or, is this just a proof of concept and thus the feature request?

Engine will always use PNG when a song is entered into the DB.

Let’s say you add 5 songs to the DB that all have the same image. Engine will add one PNG to the database and then all of those same songs will have track records that reference a single entry in the albumArt table. This saves space.

Next, you convert all of the images within albumArt to JPG.

Then, you add a 6th song that has the same image as the first five. Engine will calculate the hash from the 6th song’s album art using it’s own proprietary process and should find that hash within albumArt and reference that 6th song’s JPG.

When you add additional song records that do not have the same album art hash, engine will add PNGs to albumArt.

Engine won’t change the albumArt table upon other data changes like Cues, Loops, etc..

Here is a typical log output of the example application:

No fancy UI, only diagnostic messages.

1 Like

My favorite. :smiley:

If I reset the albumArtId column of Track to NULL (which is reasonable and permitted by the database schema) Engine DJ chokes up and displays completely empty track rows :person_shrugging:

The log contains an error code without further information:

[W] [0x13b9b288] Job Failed 'd044010ac57b3cde' (Aborted)                                                                 [2025-05-29T19:52:34.912Z] [air.planck.jobcontroller]
[W] std::runtime_error executing "Updating track list" EErrorCode: 29                                                    [2025-05-29T19:52:35.511Z] [air.planck.jobcontroller]
[W] Unexpected error:29                                                                                                  [2025-05-29T19:52:35.512Z] [air.planck.jobcontroller]

Very brittle.