On Thu, 2012-12-27 at 04:12 +0100, berenger.morel@neutralite.org wrote: [...] > > So, the actual solution you are using is using a www website which > distributes m3u files, and the user just use that m3u which point to a > web address, it the user's music software is just playing the stream? Basically, yes, the stream originates from the same website as where the m3u is created (on the user's request). > > I know that mpd is able to read/create m3u files, and is able to > directly stream music data. > One problem I can see immediately is that it is only able to play (and > so, to stream) one song at a time, you will need to start one instance > for each user... that might have a big cost... That would also mean different tcp ports for each instance, which is cumbersome with regards to the firewall and possibly proxy servers the client needs to pass (I'm thinking corporate proxy server here). > On the other hand, I remember to have played with www streaming > feature, and it was working well. IIRC, it was also possible to use only > the webbrowser. > On the other hand, it was not possible to control the mpd with that > interface (of course, this is the mpd's spirit to not implement > interfaces) I had a look at this yesterday, you can combine the mpd package with the fookebox package, that last one is a web interface for mpd. by default it runs on Apache, and I think I could make apache proxy the audiostream as well, so everything is accessible on the same TCP port. I had a working web interface and http streaming set up in a virtual machine. > [...] > > The two problems I am seeing with that procedure is that so many > instances of mpd could take some resources. Also, the user will have to > authenticate, and it might not be so easy to do (but you said you manage > headless servers at job, so I guess you'll be able to do that quickly. > Maybe you already have such system...). It seems a bit clunky and error prone to replace the function a bunch of php files... > [...] > > The bigger problem I would have seen is that mpd is only able to play > one song at a time, so there would be a need to start a different mpd > for each client... Yes, and therefore I don't think it is a good solution for my particular use case. > I have never really used m3u so, I have no idea about what they > contains. Basically they contain a link to the file that is to be played (as simple as /home/user/file.ogg or an http stream link), and start with "#EXTM3U" (minus the double quotes). I maintain one especially for VLC so so I can shutdown the machine automatically when the end of the playlist is reached (vlc has some special urls like vlc://quit). Goes like "vlc playlist.m3u; sudo poweroff". > > > > > [...] > > > > At this point I'm considering a fork of the obsidianmusic project > > where > > I try to fix the shortcomings and bugs that I encounter. > > Have fun. If it is a good tool, contributing is never useless. It just > take times :) > > Another user from this list (replied off list) hinted at subsonic, which seems to fit the bill very nicely. Debian/Ubuntu package is available from the website, but not the Debian repositories. I'll have a look at that as well. At first sight it seems to be implemented in Java and comes with its own webserver built-in (probably embedded tomcat). Again, thanks for letting me meet mpd. Regards, Steven
Attachment:
signature.asc
Description: This is a digitally signed message part