0.14.0's database and external apps

[RustyNova016]

I've started a little personal project that is essentially a listen database with LB's api, and activity pub support. But now that multiscrobbler has its own database, I kinda want to directly use multiscrobbler's database instead of reinventing the wheel.

But for that, I got a few questions regarding it:

• Is the database intended to be accessed by external programs? Read only? Read/Write?
  • If so, is there any way to identify the database's version? Is it semver compliant?
• Is there plans for [client]-like api to access the listen history? Delete listens?
• Any support for private listens?

That would be nice to know before I go too deep into it

[FoxxMD]

Hi! The database is not really intended for external access at this time. The current design is meant for ephemeral play/scrobble only because I (currently) don't want MS being a full-fat scrobble server/storage location. Due to this there are many design decisions that are not beneficial for long-term storage such as tracks/artists/albums not being normalized into separate tables.

As for access to play/scrobble data for a "recent" window (within whatever you have set for the retention policy), I am in the middle of a redesign of the ui that will introduce more stable/powerful api endpoints that I plan on documenting. With those in mind:

Is there plans for [client]-like api to access the listen history?

Yes, you will be able to access discovered plays, scrobbles, and now-playing data for each component. Using an API endpoint that returns JSON. With parameters for filtering by properties as well as a time range.

Delete listens? private listens?

MS will have concepts for discarding listens using a transform stage in a future release. Additionally, the should scrobble behavior will be soon be implemented for all sources/clients so that you can "mute" a component for some period so it does not either discover listens, or record a scrobble.

However I don't have plans for directly deleting listens/scrobbles. Or allowing that kind of behavior to propagate downstream (IE delete a scrobble in MS -> deletes the scrobble in Koito)

---

The TL;DR

MS's design, and the database, are still focused on being the "glue" between your listening sources and other, separate scrobble storage services. You will soon be able to access your recent (like 7 days, maybe a month) of listens via an API but MS is not a good choice for permanent scrobble data.

[RustyNova016]

I see. Guess I'll have to do it myself then. Although MS's design makes it easy to sandwich a storage layer so no big deal. Private listens can be handled in my DB as well.

But I do thing it's sad to not being able to pass through delete requests. I only really use Listenbrainz, so I delete my wrong listens there, and my other clients (Rocksky and last fm) just get bad data. While it would be hard to check if a listen has been deleted on an LB source, I do think if a endpointLB source sends a delete request, it could be propagated to the clients.