I made a similar server a while ago, but it is more minimal and command-line-oriented [1]. The only client so far is a fairly minimal browser client, but it is functional. It supports any container/codec that libav supports, and allows either MP3 or Ogg Opus as streaming formats. Songs are dynamically transcoded to the streaming format when they are requested. This means you can have a library of heterogeneous, potentially streaming-unfriendly formats, and not have to worry about the streaming codec du jour or transcode your entire library when you want to use a new codec.
I want to do more work on the server, but I've been busy working on an audio format library in Rust to support the transcoding. Right now, the best option is to either exec() the ffmpeg command line tool, which is easy but has overhead and makes distribution more difficult, or use the libav* C libraries, which are quite complex and in my experience poorly documented. I've decided the best option is to make a cleaner, more minimal audio library that wraps reference encoder/decoder libraries.
mStream doesn't do any transcoding. Instead I've focused on support for all common file formats. The webapp includes a fallback to Aurora JS if the the browser doesn't support the filetype. Typically this is only needed for FLAC but recently Firefox and Chrome have added FLAC streaming
Thanks for the info. The main reason I transcode the streams before transmitting is for size, not compatibility. There are a lot of situations where you really, really don't want to stream a 20 MB FLAC file. Lossy codecs like Opus at 128-192 kbps or MP3 V3/V4 can achieve transparency at a much smaller size, which is vital if you have a slower or metered connection.
That's a good use case. People typically ask me about trans coding as a why to stream unsupported file codecs. When I have the time I'll take another look into transcoding
It's easier to setup and manage than other music streaming servers. The latest version of mStream Express doesn't have an dependencies. You can get your server running in 30 seconds since nothing else has to be installed or configured. It also works for Windows, which most servers don't support.
Can't you do something similar with plex? I don't remember doing much other than using their installer. Good work though, although I don't listen to much non-streaming (spotify) music lately.
Plex kind of works, but if their central server thinks it's offline for some reason (which happens a LOT), you can't use it, even if you connect directly to it over LAN.
Hmm weird. I'd be connecting directly to it, as in 192.168.1.10:32400/web and all it would do is redirect to plex.com and then complain that the server is offline. Refreshing a few times would sometimes fix it, but usually not.
I've used Plex for more than five years and that happened like… three or four times. That sounds like a problem in your network setup. You can also always connect directly to it and skip the central server completely. A PMS does not need an internet connection at all.
That's interesting. I have been using Plex for a few years now as my primary media source which means several hours of streaming use daily both at home and travelling and have never had any issue related to the Plex central server being down.
Instead the webapp falls back to using aurora JS for codecs the browser doesn't support. This was mto support flac, but now browsers are starting to add flac support so it's not really that useful anymore
I still love Subsonic. Native clients on mobile devices, web client for browsers. Supports DLNA, videos and playlists. Pretty much ticks all of my personal requirements.
The audio streaming service is a pretty crowded market though. You could ask 10 different people to list their preferred solution and get 10 different answers.
This is different from what Icecast does. Icecast is for the use case where you have a stream of same content for a large amount of listeners, not a different, user-controllable stream for each listener.
Great alternative to ampache etc, very slick interface.
The hardest part is keeping music and especially playlists synced between devices, something that can be solved with syncthing or similar software. Playlists are very hard though with offline desktop clients (Musicbee)
How well does it handle larger libraries? My collection is around 1.4TB and I've found web apps that use a lot of js tend to lag up in the browser etc....?
It handles my 250 GB library just fine. I imagine 1.4 TB shouldn't be a problem. The frontend JS was written to be as light as possible so it would scale up easily. If you run into any problems post a bug on the github page and I'll look into it
It will take a while to scan the whole thing for metadata, but mStream handles scanning on a separate thread so you can stream it while that's being done.
Doesn't seem so huge to me. I have about the same size, mixed FLAC & mp3 (I prefer FLAC, but it isn't always available), pretty much all of it I've listened and it even lacks some considerable number of artists/albums I like. This does not include podcasts & audiobooks, I have more of them and I did not listen to all of them yet (I tend to delete audiobooks/podcasts I've listened more often than music, as probability of repeated listening is usually lower).
At 176K per second of uncompressed (CD-quality, anyhow) music, 1.4TB comes to just over 100 days. Several times that figure, with compression. That's a lot of music. More unique audio data than total amount that I've listened to on repeat for...probably about the last 5 years added together.
It really depends on how much variety you have. I had more than that in 2005, discographies and high bitrate files but it amounted to roughly 1.5 TB. If that HDD hadn't died around the time Spotify and similar streaming services came out I'd like have a larger library today
Well, right, the amount of data depends on variety. In my opinion, having enough audio to listen to something different all day, every day, for an amount of time measured in years, is a large collection.
That's not saying that there aren't larger ones, that the collector would consider themselves unusual, that any value judgement should be implied, etc. Just that more than a couple months worth of unique audio data seems like "a lot" to me.
I'm not familiar with the library, but if you're running on a system with an SSD, it should be more than okay... even then, it shouldn't be too big of a DB for sqlite, unless you are servicing thousands of users.
I have been using Audio Streamer (https://audiostreamer.org/) for this purpose for a few years. It also works on Windows/Linux (and probably Mac, although it's not listed).
This looks a bit snazzier, though. I may have to give it a try.
That is my current solution, but that only allows for one-way sync from the OSX device to either iPhone or Linux, it could be cool if I could add songs from my Linux device, or the devices could share playlists.
Just a thought - What if we create a radio hub (something like Shoutcast) pointing to streaming servers like mstream hosted by indie artists and others. Those who want their collection to be heard by the public can register at the hub. User management, analytics etc can be handled at the hub.
Curious: how does this handle NAT (for example, being installed behind multiple routers)? I have my home server connected to a Linksys router that connects to the cable modem: if I installed it on that server how would I connect to it from my phone when I'm not at home?
You'll have to setup port forwarding. This can be done by logging into your router.
If you don't have access to your router, you can try mStream's auto port forwarding feature. It will use uPNP to try to automatically configure port forwarding
Just throwing this in, as I thought it was pretty cool.. If you use google domains, you can update via dyndns request. I haven't tried it yet, but there doesn't seem to be a charge, and would probably be easy enough to setup a cron job.
I'm looking into writing plugins for youtube, spotify, and maybe soundcloud. I've found a bunch of open source projects that do it already so I may fork one of those or see if the author is interested in collaborating.
The server hosts your files and has JSON based API to search through music. The server comes with SQLite built in and a webapp to stream on any device with a browser
I want to do more work on the server, but I've been busy working on an audio format library in Rust to support the transcoding. Right now, the best option is to either exec() the ffmpeg command line tool, which is easy but has overhead and makes distribution more difficult, or use the libav* C libraries, which are quite complex and in my experience poorly documented. I've decided the best option is to make a cleaner, more minimal audio library that wraps reference encoder/decoder libraries.
How does mStream handle transcoding, if at all?
[1] https://github.com/wwalexander/river