GSOC 2026 : Playlists sorting and organization

Thanks for clarifying . This is what I think now,

The reason a separate /collection/$UUID page makes sense is that MB collection data doesn’t live in LB’s database — so the existing playlist routes can’t be reused since they depend on LB’s own playlist.playlist table.

And now we want same pattern as listenbrainz.org/artist/$UUID which reads directly from the MB database without storing anything in LB as you mentioned

Here’s the flow I have in mind:

  1. from LB they click Import → select MusicBrainz → see a list of their MB recording collections → click one → land on /collection/$UUID

  2. The page displays the collection as a read-only track list fetched directly from MB database , The user can listen right there.

  3. If user want an editable personal copy as a playlist, they click “Save as Playlist” — only then does anything get written to LB’s database via the existing POST /1/playlist/create endpoint.

On the backend with two endpoints needed since the frontend can’t directly query MB’s database ,one to list the user’s MB recording collections, and one to fetch tracks for a selected collection. Both will use mb_engine with raw SQL since no existing helpers cover collections.A helper like fetch_collection_tracks(collection_mbid) running sql against MB database via mb_engine can be created .

Does this match what you had in mind?

1 Like

Hi @mr_monkey
Just wanted a quick confirmation on whether the approach I mentioned for collection part in previous reply matches what you had in mind, so I can finalize the proposal before submission deadline.