Out of curiosity, how did you handle the mobile web with this project? With my pet project, Streeme, I had non-stop issues with the music streaming stopping on lock screens. The root cause was javascript not triggering the next track unless you unlock the device. I also found that formats/codecs could be problematic between mobile devices and different software stacks (mobile firefox, chrome, safari). Is there some alternative interface for this nowadays that doesn't need javascript? Have they settled on a common codec yet? I got pretty fed up with iOS fundamentally changing Safari's HTML5 Audio behaviors with every OS overhaul as it was my main listening device on the bus and at work. Even though it still works on the desktop, mobile clients really killed my passion for trying to make a web based media player.
Great to see the author posting it here. I submitted it a few days ago but I guess my timing wasn't that great [0].
I'm pretty happy with Subsonic [1] at the moment but I'll definitely give it a shot later because Ampache isn't Java based, which is a huge win for me.
I also use subsonic - it's great. I have a third party app on my phone that handles caching really well too, so it's a very easy way to listen to a very large music library without any manual configuring.
> Ampache isn't Java based, which is a huge win for me.
Why? Do you not like having a JVM installation on your server? Generally curious.
Java itself isn't a pig, but apps written in it can be. As far as I can tell, Subsonic is pretty well done and takes very little resources on my $7/month VPS that I use for other misc. junk. Ampache is written in PHP which isn't the speediest either (though is installed by default on a lot more boxes).
Ampache now has a Subsonic back end, meaning you can use any Subsonic client with it. I use it and it works great. This is a huge improvement; while I always liked Ampache better than Subsonic, the latter had better clients, especially on mobile devices. So now you can have the best of both worlds.
The common hangup I have with these sorts of things though, is what's the most reasonable way to host the data? IANAL, but AFAICT I'm prohibited from running something like this from my residence because my ISP (Verizon) says I can't run servers or dedicated services from my home connection. So OK, I'll go ahead and run it on a DO or EC2 or Linode instance - well, provided I feel like massively overproisioning and thus paying inordinately for ample storage (what if I have terabytes of media?), or dealing with slow connections mounting/proxying to S3 (for example). On top of that, for anyone who has media they did not acquire legally, they are now breaking (more?) laws, hosting agreements, etc.
Just curious to see how anyone else manages it - because LAN XBMC/UMS/PS3 etc is always great, but if I want something more available, like this, or a private Roku channel, etc, it seems less of a real option the more that I consider it.
I'm a Comcast user, and while I know that I'm breaking the user agreement by hosting servers, I do it anyway and so far they haven't been bothered by it. My presumption is that clause is more of a CYA on their part that if you begin consuming terabytes of bandwidth hosting your own Youtube site or whatever, they don't need to invent much of a reason to turn you off. Frankly, I'm OK with ignoring it because it seems totally unreasonable in its current wording. What is a server? Sure, Apache is pretty cut and dry, but what about hosting a L4D2 game for three friends? What about that World of Warcraft patcher that acted as a Bittorrent client? How about those Javascript libraries that "crowd host" your website? As far as I'm concerned anything that sits on a port waiting for a connection is a "server" and its almost impossible to do much online these days without unknowingly running one.
If Verizon is more stringent on this, you do have a few options if you want to do it anyway. One of the easiest is by only running the server when you intend to use it. Set up a script that allows you to turn it on/off via email or tweet or something. Or setup a port knocker script that closes the port, only opening it for outside connections when you want to watch Archer or whatever. That will protect you from the usual port scans and such, and is likely all you need to evade Verizon's ire.
The increased bandwidth usage is a trickier problem that, depending on your location/ISP, paying for offiste hosting may be your only option if you intend to stream large amounts of media. This is likely only going to get worse as infrastructure continues to degrade and ISPs continue to sit on it, so I envision we'll all be looking for options here in the future.
Fair points. Now that you mention it, the CYA rationale makes a bit more sense. And yup - it's like you said, it's almost impossible to not be contributing to other Internet users in some regard most of the time, with peering really being the LCD of those situations. Hell, being the host in a Halo matchmaking game would be enough for them to nuke your service, by contract logic. Also, good idea on the tweet/etc - even a simpler option would be doing something like a text file on S3 that just flags it as on/off, and let the script poll that every so often. I think I'll do that.
Aside, but as an unreasonably paranoid person, I appreciate the candor WRT "screw it, I do it anyway" - this (personal media hosting/availability) specifically has been a pain point for a while, and with a decent pipe to the house and plenty of storage, it'd be a shame to let it all go to waste. ;)
As far as I'm concerned anything that sits on a port waiting for a connection is a "server" and its almost impossible to do much online these days without unknowingly running one.
Absolutely true. I'm on Comcast too, and technically both my Tivo and WiFi router are 'servers' because they accept incoming connections from the internet. I also run a regular server for a few things, and I've never had a problem, but it's all been for personal use and light-bandwidth. I think if I started streaming multimedia out of the house, I'd run the risk of setting off some bandwidth usage flags. But so long as your total in+out bandwidth is within their cap (250GB/month on my residential service) there's probably no problem.
I've never seen anyone getting in trouble for running a personal service on your home connection. It's all about the proportion, if you are running a service using up TB of bandwidth/month they'll probably make use of their terms of service but otherwise there's really no reason for them to cut you off.
And what's the difference between running a service like that or just having a public share on your router which a lot of routers come with these days? There really isn't one.
If you want to host it on a service just go with a dedicated server provider and not a "cloud" service which isn't really a cheap way to host a lot of data. You can get a dedicated server with 1TB of hdd, 4GB ram etc. from OVH for 10euro/month. And that's a lot of music.
Agreed, that does make more sense. As TheCraiggers said, CYA seems to be more likely the more that I think about it.
I mean, if you're streaming BluRay 24/7, I'd imagine that's one thing - but for a normal person with a few hours of personal streaming bandwidth consumption per day, I'd hope they wouldn't even bat an eye.
The difference between running a service locally and in the cloud has pretty distinct implications in either scenario, not the least of which is overall cost. AFAICT, OVH is certainly well in the minority in terms of offering significant storage at a reasonable price. "Unlimited" storage hosts, like Bluehost for example, require that your storage use be part of the "normal operation of your website" (which I assume they mean "public use"), etc.
Hi guys,
Thanks for your comments, really glad to see people are interested in the new version.
We're working hard to release the 3.7 version so keep in touch!
Have been running on the Raspberry Pi for the last year (on lighttpd), but that version was a little troublesome on the usability front. This looks like progress, however, with a HTML5 player being a great improvement.
EDIT: Just updated to the latest version (very simple - clone new 'site files' from Github and copy the previous config, installer does the rest) and can confirm the experience is much improved with the new web player.
