ironsmile / euterpe

Self-hosted music streaming server 🎶 with RESTful API and Web interface. Think of it as your very own Spotify! ☁️🎧
https://listen-to-euterpe.eu
GNU General Public License v3.0
522 stars 42 forks source link

Caching proxy #45

Open gedw99 opened 2 years ago

gedw99 commented 2 years ago

Cool project . Really great to see desktop and mobile supported too. I would like to help with those .

I was wondering if a proxy that supports also caching the audio files efficiently is envisaged ?

maybe if it’s outside the scope of the project you have sone suggestions.

My use case is that I host everything on tiny Linux server in my house and expose it over a proxy .

So it would ease the load on my home server if I could run a simple proxy in the cloud , that of course Proxies my home server .

I saw a old golang proxy called “nedomi” and was wondering if this would be a good match to my use case of a simple proxy. It looked really cool in that it chunked the files into smaller parts and so match user habits of jumping forward in a stream .

thanks again for this awesome project !!

Don’t know if anyone remembers google music when it allowed you to upload your music btw . I was one of these users that got stung by google shutting it down.

ironsmile commented 2 years ago

Hello and thanks for interest!

It is true that initially I was aiming to make Euterpe be capable of supporting different ways of accessing the stored music. This was the reasoning behind the Library interface. But with time time going by I only needed it to work for local files and I fear this has eroded the separation of concerns. And realizing the initial vision will require some refactoring. So one could add "HTTP library". In that case using a caching HTTP server as nedomi as the source will probably do exactly what you ask for.

As for easing the load on the home server, I'm leaning for another solution - client cache. Euterpe clients could actively cache the popular files and users could proactively select which songs to keep forever on their devices. This was even implemented in an earlier version of the mobile client but I had to remove it due to technical reasons related to the Android media player. I am looking forward to introducing it back in all clients, though. My main concern here is reducing network bandwidth and therefore costs but I think it does achieve your objective too.

gedw99 commented 2 years ago

Client cache is a good idea. https://github.com/hack-pad/hackpadfs is a good one that i use. It allows you to build the GUI using golang. You have a full FS that actually stores the file inside indexdb. For Mobile and Desktop, you use the normal FS from golang

You might still want to consider a Server cache running as a proxy of the home server. If you run it using google cloud run it costs you nothing if your not using it. It can use S3 as its file File System. hackpadfs has a s3 driver btw :) https://github.com/ironsmile/nedomi/tree/master/storage can easily be extended with the s3 driver.

Because HackFS client also has a s3 driver, it would mean that the client can load directly from s3, bypassing the proxy. The proxy is simply there for Security if you want it.

THese are only suggestions. I think the Server proxy is not that useful, but i just wanted to outline how it COULD work if required.