A year on my own cloud music service

About a year ago, I wrote down some thoughts about working with Blazor, the web assembly (WASM) bits that Microsoft created as a compliment to ASP.NET. I got there because I had a real thing that I desperately wanted to build, namely my own music locker service. As I've explained before, I'm at an age where I had CD's, and then a bunch of MP3's ripped from those, and so I'm not content to use subscription services. I still prefer to buy music, to own, even if I don't get the physical artifact anymore. Maybe more importantly, I don't want to keep recreating playlists over and over again. I started with Amazon, then they abandoned serving anything you didn't buy from them, then went to Google, who killed their service and migrated to YouTube Music (with ads between the music you already owned). I just got fed up with it.

Creating your own service, when I said it out loud the first time, seemed kind of silly. Like, that's not something normal people do. But when I started to really break down the problem, it was surprisingly uncomplicated. It's actually really simple, to the point that it makes my forum app seem complicated by comparison. The new bits for me to learn were Blazor, in lieu of one of the Javascript frameworks, and the mechanics of streaming music, which as it turns out are also fairly uncomplicated in a world where HTTP supports asking for, and serving up byte ranges. Also, the browser knows how to do that already for you, as do the backend bits.

Unbelievably, a year has passed since that exploration, and I really didn't do much to change or update MLocker since then. It has mostly worked as expected since then. I say "mostly" because it was not without a few hiccups. It won't work in iOS, because Safari (which also powers the web view in Chrome and Firefox, apparently) won't allow audio HTML elements to be played without human interaction, so basically I can play one song at a time. So no using the iPad and Bluetooth through the stereo. There was also a bad build of Chrome that was out for a month last summer that broke not just Blazor, but most WASM apps. The solution was to either use the beta of the next release or turn off some feature flags, which, you know, normal people don't know about. The server side of the app also spent some time on a less reliable host for awhile (I think, because cloud), where it was slow to respond to requests, so it seemed to die for long intervals between songs. Also, getting deployment right is challenging because, depending on the tooling, the hashes might not match the files as uploaded, causing errors, though I've narrowed this to deployment from my laptop (cloud based builds are on ephemeral instances with no crusty files).

Some of that sounds serious, but it's really not. The truth is that I've been using this almost daily from my phone and it works reliably. It looks like an "app" on my phone. I never have to recreate a playlist ever again (hopefully). In fact, now that I understand how to sort and catalog the music, it's an even bigger mystery why Amazon and Google used to mess up my files or fragment albums, especially Broadway cast recordings (hint: group on the "Album Artist" field first). Tesla can't get it right either in the car when you plug in a USB key.

Where can I go with it? I think the first thing is trying to really figure out the offline scenario. I'm probably not that far from it, but proper web apps running offline does have some challenges. I've solved some of the problems already. The album art is all cached on the device already. I don't fetch the song list or playlists on startup. It does hit the server on load, but transfers only 260 bytes (not kilobytes or larger). I have a hacky solution for caching song files that I'm not entirely sure I like. Right now it's all potentially subject to eviction by the browser, but I think I can solve that. It also calls the server to increment listen counts, which I'm sure I can queue. What I'm thinking about is the total offline scenario, like I'm on a cruise.

Of course, building a phone client app would make it easy to solve all of those things. Maybe that's not really as much work as I think it is, because the API's and the data models are all there and ready to go. I just think about how every single time I've started to go down that road, there are a bazillion SDK's that take up half of my hard drive, and something inevitably doesn't build right. It's not impossible though, and I've got an old MacBook Air that still works as a build agent (or at least, it did last year).

There's a small part of me that wonders if there's a market for this. There are some existing services, but they don't have a long shelf life. Also, the people owning their own music tend be audiophiles that like the gigantic un or barely compressed file formats, which turns the value proposition on its head. My cost is about $2 a month for the storage and bandwidth (it shares compute with CoasterBuzz), and I have around 8,000 songs. There would have to be some kind of tiered cost, and I'm sure $10 is already the limit for what people would consider.

In any case, as much as this is still a science project, I don't think I've enjoyed building anything as much as I did this.