Just wish Jellyfin would support S3 compatible targets for media storage :/ point at bucket(s), scan/index/enrich, serve to clients
Just wish Jellyfin would support S3 compatible targets for media storage :/ point at bucket(s), scan/index/enrich, serve to clients
I've been working on a custom media server that does streaming, block-based storage on top of S3, with the local disk being used as a cache.
I implemented an override of Stream in C# that can be passed directly to an HttpContext file response. This gives me range-based response support on top of cached S3 media blocks for free. The front-end uses ffmpeg to do a quick transcode on uploads to guarantee fast start of mp4 content in my html video elements.
The cool thing with having a reasonable sized cache is that you can switch to glacier infrequent access tier (i.e., the one intended for quarterly reporting) and save a lot of money on storage. The other fun bit is that it is shared across all clients on the LAN, so if someone watches a show before you, you'll just read it from local during your run through.
For me, I don't need a lot of fancy bullshit in a media solution. An un-styled web player that just works on my MacBook is pretty much the only client support I care about. My media library currently shows up as a monolithic <table> without any pagination. Time to first frame on an uncached video click is well under a second on a 1gbps fiber connection using 32 megabyte block size to US-EAST-1 from Texas.
What are egress expenses though. I really want to go this way, but worried about the costs during egress data transfer
Egress isn't that bad. It would be like paying for 1~2 streaming subscriptions if you watched several gigabytes of fresh content per day every day (i.e., zero cache hits).
"block-based storage on top of S3"
What does this buy you? It seems like an object storage system would provide everything you need on its own.
Encryption is the reason I don't use the provider's range based support. The server encrypts each block using a local key before it is stored in S3.
Is that wise though? I mean I understand the desire to use cheap off-site storage, but S3 clouds can be expensive when requesting files a lot, streaming data, lots of read/write operations.
https://www.cloudflare.com/bandwidth-alliance/
https://www.backblaze.com/cloud-storage/pricing
(Disclaimer: this relates to the commercial project I run, but it is directly answering the parent)
It's not self hosted, more a middle-ground between rented Spotify and self hosted data sovereignty, but this is what we do at https://asti.ga . You store your music in some Internet-accessible storage, such as any S3 compatible endpoint, and Astiga connects and streams your library (and provides offline etc etc). AMA.
Very relevant to my interest, thank you for posting, I wouldn't have found you otherwise.
Could you run a user space s3 filesystem that jellyfin thinks is a regular disk filesystem.
You can, it’s just suboptimal in my experience and incurs troubleshooting time. I’ve been meaning to put a bounty on S3 compatible support via a fork (maintainers are not interested and believe posix file system is preferable), just haven’t had the time. Hopefully soon!
Desired pipeline is “Ingest->MusicBrainz->Object Storage (music bucket, write once read many)->Serve to various clients from middleware server (Jellyfin).”
You can do this via rclone with Jellyfin.