Implement Subsonic getNowPlaying API endpoint

[langelgjm]

This is a proof of concept implementation of the getNowPlaying API endpoint (see #510 ). The response NowPlayingEntry only provides the minimal fields required by the OpenSubsonic spec, plus "artist" and "album". The IsDir and and PlayerId fields are hardcoded to false / 0.

I implemented this so I could use Homepage's Navidrome widget (which is just a generic Subsonic widget that hits the getNowPlaying endpoint and looks for Username, Title, Album, and Artist) as discussed in #533 .

Originally I had created a now_playing table in the database and would insert a row during ServeStream, but that seemed too heavy and invasive, so instead this code relies on an in-memory cache that simply stores the latest track streamed by each user.

Caveats:

• Since the cache is keyed by user, if the same user is streaming to multiple devices, we only see their most recent stream. Lots of ways to change this behavior, but I wanted to get feedback first.
• There's no cache eviction/expiration, but since it is keyed by user it can only grow as large as the number of users.
• Data is not persisted, which seems fine.
• I have not tested this with anything other than regular music tracks (no podcasts, internet radio, etc.)

Questions / Clarifications

• How do we feel about this implementation (cache vs. database table vs. some other method)?
• As far as I could tell, there's no way to get the data needed for getNowPlaying from the database; the plays table only provides album play counts.
• Should we aim to support as many of the optional fields of NowPlayingEntry as possible? Or keep it simple?
• Since getNowPlaying's NowPlayingEntry has a "minutesAgo" field, presumably the endpoint should return entries for recent plays even after the track has ended. Here, I limit returned entries to those within the last 60 minutes.

Full disclosure, I never used Go before this week and this is mostly Copilot code, but I have reviewed it, and I'm running this version of the code on my personal network right now.

[sentriz]

oh nice, thank you @langelgjm

but i think we do in fact want to store track level plays in the database. that will be required for #459

i'm not sure about the structure though. maybe extending the plays table, maybe a new table, should it be polymorhic so we can track podcast plays, internet radio plays, etc

also, if we have the concept of track level plays, we could delete the concept of album level plays, since the info is already there