on device smart shuffle/smart playback idea

[docmeth02]

So the idea behind #119 and and to make use of the already implemented listening history (artist, album, timestamp) every time you play a song past 50% the app logs the playback and with #119 now knows which songs you've starred.

To use that data i would propose to add smart playback algo that scores every song in your library based on how often you listen to that artist, whether you've liked the song, how recently you've played similar music, and genre affinity — all computed on-device with no server needed (for full offline functionality we would need to cache the library as well). A small random factor keeps things fresh. When the queue ends, we add a settings toggle for continous playback, it then auto-generates more songs instead of stopping playback.

A "Play Something" button on the home screen lets you instantly start a personalized mix no need to pick something specific, it already knows what you like to listen to.

For new users with little history, we can optionally fall back to Navidrome's getSimilarSongs2 API to seed recommendations until enough on-device data has been collected.

Would love to hear everyones opinion about such a feature :)

[docmeth02]

Just as a example how this could work. I do have this algo implemented on my apple watch standalone branch and it works quite well for me so far:

Score every song in library against these signals:

• Artist frequency (30%) — how often this artist appears in your listening history
• Starred (25%) — liked songs get a flat boost
• Recency (20%) — artists/albums you played in the last 14 days score higher
• Genre match (15%) — songs matching your top 5 most-played genres
• Random (10%) — variety factor so it doesn't become predictable

Add top candidates randomized to playback queue, make sure to blacklist smart playback for each actually played back song for the next X minutes.

[faultables]

this is pretty interesting, if we implement it on device, unfortunately we can’t have it on any other devices. syncing it via iCloud may helps but adding cloudkit is somewhat complex since we need permissions this and that

how about making it as a native navidrome plugin? what do you think?

[docmeth02]

hey, thanks for the feedback! i actually looked into the icloud sync thing and its way less complex than expected for our use case.

since HistoryEntity is super simple (just flat optional attributes, no relationships, no unique constraints) its already CloudKit-compatible as-is. the approach would be to split the Core Data store into two configurations — a local one for queue/cache/playlists/songs and a CloudKit-backed one just for listening history. the nice thing is this is completely transparent to the rest of the codebase, NSPersistentCloudKitContainer routes entity operations to the correct store based on the model configuration so none of the existing code that reads or writes history needs to change at all. realistically we are talking about ~100-150 lines in CoreDataManager.swift plus a one-time migration of existing history rows, nothing else.

the only thing i cant do from my side is the entitlements — the app would need iCloud with CloudKit enabled and Background Modes for remote notifications in the provisioning, plus a CloudKit container set up and the schema deployed to production before any testflight build. if you are willing to set that up id be happy to implement and test the whole thing.

on the navidrome plugin idea, i think theres value in keeping this on-device regardless — it works offline, puts zero load on the server, and the data stays private on the users iCloud. a server-side plugin would still need client code changes in flo to talk to whatever API it exposes so youd be touching two codebases instead of one. nothing stops us from adding a server-side source later if navidrome gets a recommendation API, the scoring logic is already isolated in its own service so swapping data sources would be straightforward. but for now on-device + iCloud sync gives us cross-device recommendations with minimal complexity.

[faultables]

ah that sounds great! can we have the excalidraw/tldraw diagram so we can have a bigger picture of any moving parts?

and maybe employing Core ML will be fun to experiment with