[Feature Request] Server-Side Library Storage

[seekermarcel]

Add a persistent server-side library where users can save tracks for instant local playback, bypassing external streaming sources.

Probably related to #11 and #7

Problem

Currently, every play request fetches audio from external sources (Tidal, Deezer, Dab). This means:

• Repeated plays of the same track waste bandwidth
• Playback depends on external service availability
• No way to build a permanent collection on the server

Solution

Introduce a Server Library - a permanent storage area separate from the TTL-based cache:

Storage	Purpose	Lifetime
Cache	Temporary streaming buffer	24h TTL, 500MB limit
Library	User's saved collection	Permanent, no auto-cleanup

Features

• Save to Server: New button in download modal saves tracks to server library
• Local Playback: Streaming endpoint checks library first, serves local files instantly
• Library View: Browse and manage saved tracks via header button
• Visual Indicator: "LOCAL" + "FLAC" badges show when playing from library
• Artist/Song Structure: Files organized as /library/tracks/Artist/Song.flac
• Docker Volume: Library persists across container restarts

Playback Flow

Play request → Check Library → Check Cache → Fetch External
                    ↓
              Found locally?
                    ↓
           Yes: Serve with X-Source: library

[topearebi]

Hi there! I’m really interested in the library feature you're building.

I was wondering if it might be possible to decouple the library index from the physical audio files for users with limited server storage?

Maybe a super lightweight database or JSON that stores the library metadata. Playlist IDs, Artist, Album, Source URL, etc but with no requirement for the actual audio file?
On startup, the app could populate the user's library view from the metadata instead of just scanning for downloaded files

This would workaround the google drive dependency for syncing library, playlists and queues for everyone whether they download locally or to their server.

I could also potentially do a mass import of an existing library if you can create the file with the right structure.

Do you think this would be feasible with your current implementation?

[seekermarcel]

@topearebi I don't understand exactly what you mean. Do you just want to split the metadata from the actual local files?

could you give me an example based on an actual song. How you imagine the workflow and why?

[topearebi]

@seekermarcel
Let me see if I can explain this

Currently
Freedify builds a temporary cache for playback. However, because the user state (Playlists, Queue, Library) is local to the browser, when you switch devices, you have to manually Push and Pull from Google Drive to transfer that state.

Your Implementation as I understand it

• You are adding a persistent library volume to save files.
• When I switch browsers, I can see the songs I have physically downloaded to the server.

But this still leaves out any Playlists, Queues and library songs that I haven't downloaded.
To see those, I would still have to do the manual Google Drive push/pull.

My Suggestion
Add a lightweight metadata file (or DB) in the library volume that tracks the entire user state, not just the files.

Example Structure: Song Title, Artist, Source URL, Playlist IDs, Downloaded: True/False, Quality: hi-res, 16 bit, flac etc, in queue, cached etc

When freedify loads, it reads this index. The user sees their complete library and playlists.

It still maintains your original workflow of
If Downloaded: True -> Play from local file.
If Downloaded: False -> Stream on-demand (just like the cache).

It kind of starts to work like cloud sync and even if you need to offload music for storage, your library remembers it no matter where you open it up
An example is how calibre stores a metadata.db file in the library folder to maintain integrity no matter where you move your library to. Even if you lose the file, the structure remains visible

Of course I could also have completely misunderstood what you're trying to do here and this should go somewhere else

[BioHapHazard]

I appreciate the work you did with this. I know this is a feature that others may want.