Plex however relies on you either have 1) a good home connection (with no caps) or 2) a server "in the cloud(tm)". Dropbox provides the backend hosting, which makes providing the data files easier.
That currently is not possible, but wouldn't be very difficult to implement as I had it in mind from the beginning. Inspiration could be the Dropbox integration:
These comments make sense from end-users but I feel like they're out of place on HN. I mean, sure OneDrive & GoogleDrive support can obviously be implemented down the road, but especially when first showing the idea off - it's way easier to keep it simple and get feedback to improve the product and then later integrate with more services.
These comments remind me of the few apps I've put out that start with an iOS version so we can collect / data & feedback so we can make future versions (on both platforms) better, but that info almost always gets shouted down by chants of "why not an android version?" The obvious answer of "it costs 2x time and resources" to get the first version out, almost always gets completely ignored.
Let's give feedback on this version - help him improve it & then worry about the other service integrations later.
I don't think it's criticism, it's just not the most useful question they could be asking at this point in time. If he's showing off a new project - I think it's probably best to help improve what he currently has now and then worrying about the integrations later
Consider the perspective of someone who has never heard of a new piece of software before. They just want to know a bunch of things about it, so they can form a concept of it in their mind. This is one such question.
I don't disagree with what the author's focus should be, but I don't think that this question distracts from that.
I am a developer, I haven't dug into how he was processing the audio. I was simply asking a question. I don't use Dropbox so I was simply asking if it was on the roadmap so I could try it in the future.
When I was looking at Google Drive API some time ago, it didn't—unlike the Dropbox API—support byte serving (partial requests). That is needed for efficient indexing of MP3 files without having to download them first. It may have since changed though. Otherwise I think it would be pretty much analogous to the Dropbox integration.
It's not running anywhere right now, sorry about that. That is because the app is not really ready for public production use. As mentioned in the README, I've kinda stopped working on it some time ago. I think it could still be interesting/useful to people who want to run in even in this state by themselves. The codebase also hopefully has some interesting bits, so I've at least opened it up for now. Another thing is that the backend talks directly to the Musicbrainz API, which is throttled (their DB is open though, so one could make a web service on top of it).
Could this support playing music from S3 and storing/reading metadata as S3 headers? I currently store about 200GB of music in Amazon Cloudplayer, which has recently gone sideways with their push towards Music Prime. I'm currently ripping all my music out and putting it into S3.
Really cool. At first glance it seems to me like there might be two products/services here - one that is what you have here minus YouTube and other publicly available media sources, and another centralized web app that provides users access to all public media without having to run their own server. Maybe they could be integrated in a way where users can add their own media sources through the centralized web app to have it all in one place.
Really cool idea. Who hasn't thought of doing this before? Congrats on actually making it, and making it look beautiful. Already forked it, can't wait to start playing with it.
I don't see any mobile screenshots, how does it look on a phone screen? I can imagine that being a great use-case for this app.
I don't think he's the first to think of it, but definitely one of the few who actually built it, I started once a while back, but never got very far...LOL
Also I was just wondering if it has a mobile component, guess I hadn't thought of that....I could play music on my computer no problem, it's on my phone that is ideal :)
Thanks! I'm pretty sure though that I'm not the first one nor the last one to have ever thought of that :D
The design is fluid but not really responsive. What I've been playing with is remote control that worked great on mobile devices. You were able to control all of your active CloudTunes sessions from any connected browser. So you could for instance play music on your computer, and control it via your smartphone (just like the iOS Remote app from Apple can control iTunes, except this worked over the internet so you didn't need to be on the same network). It was a very crude prototype though so I didn't include it in the initial release.
I didn't see any mobile screenshots, or much code that seemed responsive, so I assumed it wasn't mobile friendly and wanted to try fixing that. And the comments below about it supporting Dropbox, but not music stored on the local server (and the tips from OP about how to implement it), is another goal I'd like to tackle. I don't know if I can implement these, but I'm certainly going to try, and I'll learn a lot in the process.
Also I've had this idea a million times before, but never committed to doing it, it's the kind of product I've always wanted. So seeing it on GitHub (and written in a language I'm good at) makes me really happy, and I'd love to tear into this thing.
Edit: Also it's very pretty, and I'm a sucker for anything with a pleasant UI like that.
Congrats on the design, but it's sad to see that once again, the wheel has been reinvented: there once was playdar [0], the content resolver that clearly separated the data that was of interest to the user (artist, song, ...) and the actual sources. Its biggest problem was, I believe, that it wasn't an actual music player.
Its gentle folks decided to restart from scratch with a music player in mind, and keep the idea of having different resolvers to target different sources, such as local disk, youtube, spotify, radioshark, ... Really, if you know javascript, you can write a resolver targetting the platform of your choice. The end result is Tomahawk [1] and if you're interested in that you should have a look.
Maybe it didn't spread because it's not a webapp ?
>Maybe it didn't spread because it's not a webapp ?
I think this is it. I remember checking out Tomahawk a while ago, about the time Songbird announced it was discontinuing development. I ended up just going back to iTunes because it did all I needed (even if it is bloated). If I can install Tomahawk on a computer, I can probably install my music library onto it as well, so I don't need the resolving features it has.
I actually just tried installing Tomahawk because of your comment, and it does work very well, and looks pretty while doing it. It was able to find several obscure artists with perfect accuracy. (Though it did grab most of them from Soundcloud at 128kb/s, when a few of them are on Spotify with higher bitrates). But unless I can access it anywhere, with a moment's notice, I don't really have a purpose for it being installed on a machine.
I rarely even listen to music on my computer anymore. I use my phone for Spotify on the go and even at work. It's nice to not have another program running while I'm working. But a lot of artists I like aren't on Spotify, and my phone doesn't have enough storage to fit my entire library.
That's why this interests me so much. I would love to set up a server where I can open the URL on my phone, laptop, friend's laptop, etc, be able to play most of my music through web services, and the artists that aren't on those services would play from my server directly, or my DropBox, or whatever, and hopefully it can all be a seamless experience.
YouTube now defaults to using the <video> element unless the video would show an advertisement. In those scenarios, it falls back to using the flash player.
I've always thought it might be interesting to have apps like this that run locally on web technologies. Is there hope for this model? One obviously shortcoming as exemplified here is the painful installation process. I suspect people are also going to be concerned with what's being installed where.
there is if we can agree on a base tech (node.js for example), an app store model, and the environment is sandboxed. this would let people produce apps that would work everywhere - from raspberry pis to pcs to macs.
also sadly, some sort of drm should probably exist.
I'd been planning on releasing it together with a Dockerfile so that people could easily run it locally in an isolated container. It turned out to be a bit more complex than I had anticipated so Docker support will come later. But I think that could be a viable model for locally-installable web apps in the future.
I definitely second this. As we move towards multiple devices with predominantly flash storage, the device should be responsible for serving the content rather than storing it. The more we can move towards these types of apps, the better.
I've tried to use subsonic and madsonic (a fork of subsonic) before. I didn't like either of them much nor did I like the phone apps to accompany them (many are paid apps as well). I'm gonna look at this project tomorrow and see if I want to undertake a server port. I think it would be viable.
Agreed, the mobile apps are mostly ugly or abandoned and the server software itself still uses a flash player. It's just something I put up with because there's no better alternative at the moment.
I'll see what I can do about it ;)
I just found this from some of the comments above http://ampache.org/. I'm gonna install that and see how it is, but I really think I'm going to move forward with trying to integrate this with a seedbox type of server. Since the client is done in JS as well it could be practical to port that to Android and iPhone also.
Nice work! I personally use ownCloud (which has Ampache support) for my streaming of my library, but this is a really nice job. I might see how hard it is to integrate into ownCloud :)
For the love of possible users, put some sort of scrolling indicator on the page. Firefox in OS X doesn't show scroll bar. I spend about a minute clicking on the slant phone and the name in the top right before accidentally causing the page to scroll down.
This is really nice. Would you mind chatting with me sometime? I'd love to pick your brain or even just converse with someone who has similar interests. I've spent the past two years developing Streamus, https://streamus.com/, an open-source music player which runs off of YouTube as a browser extension; it has 130,000 users currently.
Wow, really cool. Since you're already using brunch [1]. You should checkout chaplin [2]. It's a backbone framework built by the same guys who made brunch. It supports coffescript, pub/sub, dynamic url construction, plus a bunch of other features that make working with it a breeze.
Thanks for the tip. I actually did originally start with Chaplin. It helped me to start quickly, but later I replaced it with a very simple, custom Backbone-based MVC (Chaplin-inspired to some degree).
Interesting... you mind explaining the reason for switching? If it was missing functionality, I'm sure the team would appreciate pull requests. I'm often dismayed that angular is grabbing all the spotlight these days and not many new web apps use backbone in general or chaplin in particular.
There is a tradeoff between speed of development and degree of customizability when it comes to frameworks. With CloudTunes, I was going for a highly-customized and performant UI, and at some point it simply became easier to go back down by one layer of abstraction and build it just with Backbone instead.
93 comments
[ 4.3 ms ] story [ 184 ms ] threadI don't see myself doing this so i just simply ask. There's no need to downvote.
Plex, for instance, does this and much more provided you have a collection not in a cloud.
downvotes is a tool for marking irrelevant/obnoxious comments which don't help discussion. this question definitely helps discussion.
Client-side model:
https://github.com/jakubroztocil/cloudtunes/blob/master/clou...
API endpoint: for local files, it could simply serve the file:
https://github.com/jakubroztocil/cloudtunes/blob/master/clou...
Plus it would also need indexing, configuration, and to introduce a new media type across the app.
https://github.com/jakubroztocil/cloudtunes/tree/master/clou...
These comments remind me of the few apps I've put out that start with an iOS version so we can collect / data & feedback so we can make future versions (on both platforms) better, but that info almost always gets shouted down by chants of "why not an android version?" The obvious answer of "it costs 2x time and resources" to get the first version out, almost always gets completely ignored.
Let's give feedback on this version - help him improve it & then worry about the other service integrations later.
I don't disagree with what the author's focus should be, but I don't think that this question distracts from that.
[0]https://github.com/ampache/ampache
https://github.com/SirCmpwn/staccato
You might consider a jukebox mode where several listeners are synced up and can suggest songs.
https://github.com/superjamie/playlist-generator
It's just a PHP file lister and audiojs, but it works on pretty much every modern desktop and mobile platform.
I don't see any mobile screenshots, how does it look on a phone screen? I can imagine that being a great use-case for this app.
The design is fluid but not really responsive. What I've been playing with is remote control that worked great on mobile devices. You were able to control all of your active CloudTunes sessions from any connected browser. So you could for instance play music on your computer, and control it via your smartphone (just like the iOS Remote app from Apple can control iTunes, except this worked over the internet so you didn't need to be on the same network). It was a very crude prototype though so I didn't include it in the initial release.
Also I've had this idea a million times before, but never committed to doing it, it's the kind of product I've always wanted. So seeing it on GitHub (and written in a language I'm good at) makes me really happy, and I'd love to tear into this thing.
Edit: Also it's very pretty, and I'm a sucker for anything with a pleasant UI like that.
Its gentle folks decided to restart from scratch with a music player in mind, and keep the idea of having different resolvers to target different sources, such as local disk, youtube, spotify, radioshark, ... Really, if you know javascript, you can write a resolver targetting the platform of your choice. The end result is Tomahawk [1] and if you're interested in that you should have a look.
Maybe it didn't spread because it's not a webapp ?
[0] http://www.playdar.org/
[1] http://www.tomahawk-player.org/
I think this is it. I remember checking out Tomahawk a while ago, about the time Songbird announced it was discontinuing development. I ended up just going back to iTunes because it did all I needed (even if it is bloated). If I can install Tomahawk on a computer, I can probably install my music library onto it as well, so I don't need the resolving features it has.
I actually just tried installing Tomahawk because of your comment, and it does work very well, and looks pretty while doing it. It was able to find several obscure artists with perfect accuracy. (Though it did grab most of them from Soundcloud at 128kb/s, when a few of them are on Spotify with higher bitrates). But unless I can access it anywhere, with a moment's notice, I don't really have a purpose for it being installed on a machine.
I rarely even listen to music on my computer anymore. I use my phone for Spotify on the go and even at work. It's nice to not have another program running while I'm working. But a lot of artists I like aren't on Spotify, and my phone doesn't have enough storage to fit my entire library.
That's why this interests me so much. I would love to set up a server where I can open the URL on my phone, laptop, friend's laptop, etc, be able to play most of my music through web services, and the artists that aren't on those services would play from my server directly, or my DropBox, or whatever, and hopefully it can all be a seamless experience.
Also, an Android app for Tomahawk is in the works!
Then there is also Youtify: http://youtify.com – open source as well https://github.com/youtify/youtify but stale for some time.
I look forward to checking this out. Going to take me quite a while to finish uploading my music though.
Some of my Dead could maybe cause a problem (though it was all once freely available on archive.org).
They could theoretically do this in a way that doesn't really invade privacy (by using only hashes), but the controversy would probably kill Dropbox.
Of course I now pay for it, only for the packrat feature though.
also sadly, some sort of drm should probably exist.
https://github.com/jakubroztocil/cloudtunes/issues/2
https://github.com/jakubroztocil/cloudtunes#with-docker
http://cloudplay.fm/
[0] http://www.subsonic.org/
I've been off and on working on a python version of the Subsonic API. Try it out, you might like it.
Currently trying to port it to windows.
Also as mentioned elsewhere in these comments, DSub is a very nice subsonic android app.
This is really nice. Would you mind chatting with me sometime? I'd love to pick your brain or even just converse with someone who has similar interests. I've spent the past two years developing Streamus, https://streamus.com/, an open-source music player which runs off of YouTube as a browser extension; it has 130,000 users currently.
Hit me up if you want to chat! admin@streamus.com and if you'd like to browse the repo, https://github.com/MeoMix/StreamusChromeExtension
[1] http://brunch.io/ [2] http://chaplinjs.org/