lucas42/lucos_media_metadata_api

An API for managing media metadata.

lucos_media_metadata_api

An API for managing media metadata.

Dependencies

• docker
• docker-compose

Build-time Dependencies

• Golang
• github.com/mattn/go-sqlite3
• github.com/jmoiron/sqlx

Running

nice -19 docker-compose up -d --no-build

Building

The build is configured to run in Dockerhub when a commit is pushed to the master branch in github.

Running locally

• Install the build-time dependencies (see above)
• Run go install
• Run lucos_media_metadata_api

(The install command should add this to your $GOBIN. Make sure you've added this to your $PATH correctly to find the command)

Accepts the following environment variables:

• PORT The tcp port to listen on. Defaults to 8080

Testing

Run go test ./src

For code coverage, run tests with: go test ./src -coverprofile=coverage.out Then, to view coverage report in browser, run: go tool cover -html=coverage.out

Backing Up

Copy the file from the docker host at /var/lib/docker/volumes/lucos_media_metadata_api_db/_data/media.sqlite For example: cp /var/lib/docker/volumes/lucos_media_metadata_api_db/_data/media.sqlite manual-backups/media-date +%F.sqlite

lucos_media_metadata_api's Issues

Pagination for tracks in collection

Christmas collection is a bit too big to handle gracefully. Pagination would help.

Expose list of globals at /globals

It's hard to remember the exact keys sometimes. It'd be nice if /globals just listed them.

Add some logging

Currently there's only logs when starting up, returning internal server errors or hitting a deprecated endpoint.
This means there's not much to go on when things aren't hitting a hard error (eg performance issues / timeouts etc)
Add some more logs covering normal operation.

Don't send updated event to loganne if nothing has changed.

At the moment, every Sunday when the lucos_media_import runs, loganne gets absolutely spammed with an event for every single track. This is unnecessary when nothing has actually changed.
Should check whether anything has changed before firing the event (perhaps even before doing a DB write if that'd be more performant?)

Race condition when updating weighting of track in collection

Hard to reproduce, but it seems possible to get into a state where the max cum_weighting of a particular collection doesn't match the sum of the weightings of all tracks in that collection.

Why does track 2035 get played so often?

It's only got a weighting of 8, yet seems to get completely disproportionate play time. At one point I noticed it appearing 4 or 5 times in a single playlist (out of 20 or so tracks).
I know human psychology means we tend to spot patterns even in truly random data. But this one feels way beyond that level of frequency.

Delete track

Currently can't delete a track.

Probably clearest to respond to the DELETE http method for this.

Bulk Update

Create method for updating multiple tracks at once.

Include track URLs in search

Currently only tags are searched. But sometimes there's something in the url which hasn't been tagged up correctly - would be good to include that.

Tracks with missing fields

Currently if a PUT to /track/* misses a field like URL or fingerprint, the value is set to an empty string.

This should either error hard (with no modifications to the database), or succeed leaving the original value in situ.

Worth thinking about whether to treat any falsely value in the same way.

Shuffle tracks in collection

An equivalent to /v2/tracks/random for collections.

500 error when unique key conflicts

Updating a track with a URL or fingerprint which clashes with an existing one bails with a 500 and DB error.
Should handle this more gracefully.

Deleting track which is in a collection breaks stuff

Need to remove track from collection as part of delete.

Otherwise get a lot of these errors: Internal Server Error: sql: Scan error on column index 0, name "id": converting NULL to int is unsupported

(Can database be stricter around foreign keys too?)