Re: [Musicpd-dev-team] server to server connection
Sorry, but this is closing eyes with such an answer, I dont have upload for that, my DSL connection has 256kbit uplink. Pulseaudio throughtput will be at leas 1387 Kbits. Thats 5 times more than I could afford. metyl On Sun, Oct 25, 2009 at 11:10 PM, Avuton Olrich avu...@gmail.com wrote: On Sun, Oct 25, 2009 at 11:20 AM, Metyl Methylius the.me...@gmail.com wrote: Hi *, I have the same problem about mpd. I need a transparent access to my setuped instance of mpd anywhere on the network (i like to listen music from my collection from work. No decoding and encoding only transparent data transfer. Only then the quality of the record stays same as was in the other mpd instance on the network. This would require implementing new TCP or UDP port or a upgrade in protocol interface. Or another example of use - You connect to your home wifi and wanna play newly captured files from your notebook to your homeaudio (wireless router with mpd and USB card). pulseaudio -- avuton -- All opinions stated above are mine and do not necessarily reflect those of the US secret service. -- This mess was sent using 100% recycled electrons. If you want to get rid of this mess just turn off your computer, -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
On 2009/10/24 13:58, Steffen 'stefreak' Neubauer stefr...@stefreak.de wrote: I had that idea yesterday for a server to server connection - if an mpd server could connect to another you could distribute your music on different computers - if you have your notebook and your pc for example and you have music on your notebook which isn't on the pc you could hear the music on your pc when the MPDs are connected. [...] Hi Steffen, I've been offline for a few days, so here's my late response. First, I agree with Avuton: this is not exactly what MPD is made for. It is not a file sharing protocol. We should not invent a new networked file protocol. Second: I disagree slightly with Avuton about the bloat thing. If bloat is compile-time optional, everybody can decide to switch it off, and will not suffer from the overhead. I have thought about connecting two MPDs with each others a few months ago. This would be useful for sharing the music database: let's say you have a NFS file server, and three MPD servers mounting the music via NFS. Each one would have to do the database update, which is expensive over NFS. Imagine running MPD on the NFS server, too (although it doesn't have a sound card). Now the three real MPD servers could forward all database requests (lsinfo, find, ...) to the NFS server, and would not need a database at all. Your idea goes further: you want to include the file transfer in the equation. Indeed, it would simplify a lot for users if MPD could auto-detect the file server. But again, we should not invent a new protocol. There are too many already. Could you investigate other solutions? Maybe there's a library we could use, which implements a file server? Is there a small NFS daemon library? What about UPnP? Any other ideas? Next stop: synchronous playback for distributed MPD instances, for multi-room setups. A lot of interesting problems to solve here! P.S. don't you have an irc channel? Yes, #mpd-dev on freenode. Max -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
On Sun, Oct 25, 2009 at 11:41 PM, Metyl Methylius the.me...@gmail.com wrote: Sorry, but this is closing eyes with such an answer, I dont have upload for that, my DSL connection has 256kbit uplink. Pulseaudio throughtput will be at leas 1387 Kbits. Thats 5 times more than I could afford. Then you're looking for the httpd/icecast output. -- avuton -- All opinions stated above are mine and do not necessarily reflect those of the US secret service. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
On 2009/10/26 14:47, Avuton Olrich avu...@gmail.com wrote: On Sun, Oct 25, 2009 at 11:41 PM, Metyl Methylius the.me...@gmail.com wrote: Sorry, but this is closing eyes with such an answer, I dont have upload for that, my DSL connection has 256kbit uplink. Pulseaudio throughtput will be at leas 1387 Kbits. Thats 5 times more than I could afford. Then you're looking for the httpd/icecast output. All of these are valid solutions for some problems, but the advantage of Steffen's idea is that every MPD can play different music at a time. Max -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
Yes, you're right the httpd will do that, but its also transcoding the data which is unnecessary and damages the quality. I'm looking to implement a way of streaming without reducing quality of record. metyl On Mon, Oct 26, 2009 at 2:47 PM, Avuton Olrich avu...@gmail.com wrote: On Sun, Oct 25, 2009 at 11:41 PM, Metyl Methylius the.me...@gmail.com wrote: Sorry, but this is closing eyes with such an answer, I dont have upload for that, my DSL connection has 256kbit uplink. Pulseaudio throughtput will be at leas 1387 Kbits. Thats 5 times more than I could afford. Then you're looking for the httpd/icecast output. -- avuton -- All opinions stated above are mine and do not necessarily reflect those of the US secret service. -- This mess was sent using 100% recycled electrons. If you want to get rid of this mess just turn off your computer, -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
Hello :) I thought a bit further now and I think i'll design a very simple protocol (like music exchange protocol or smth. like this) which is for exchanging the music database and the raw music files (mp3, ogg, etc.). After designing the protocol a simple c library should be made to make it easy to use the protocol. Then plugins for every player could be made (from itunes to mpd to mpd clients). And yeah, i know that i am reinventing the wheel with a new protocol. Yeeah, i know there is ftp, upnp, nfs, smb, several streaming techniques, pulseaudio and many many many more for doing that. But i think all those have too much overhead for what i want to do - i only want to share the music database and chunks of single music files. And some other reasons (like the one stated by Max) too. If anyone is interested in helping a bit and sharing ideas feel free to contact me or posting them here :) Greetings, Steffen signature.asc Description: PGP signature -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
On Mon, 26 Oct 2009 16:15:07 +0100 Max Kellermann m...@duempel.org wrote: The standard MPD protocol is good enough for providing read-only access to the database. If it is not, extend it. Yes that's correct, the MPD protocol would be very good for doing that. This was my initial idea. If it appears that MPD (the devs of the mpd project) accepts it this would be the best way. But if MPD will not accept a change to it's protocol and/or it's source i think a fork is not the best way. Then i would design an own protocol. Please explain that overhead thing, and why your new protocol has less overhead than all other protocols, and why this is a problem which justifies a new protocol. - most protocols are Client/Server architecture based. (mpd too, but a p2p mode could easily be integrated.) - most protocols do more than i want - like listing files and folders or user+password authentication and writing to the file system (ftp, nfs, smb). - streaming protocols (that i know) and pulseaudio are not suitable for this (and the sound is being recoded into another format which costs cpu time and reduces quality or puts more load on the network) i don't know how upnp works but i think it gives something like file system access too, doesn't it? I think an integration into the mpd protocol would be the best - but this will not happen an own protocol would be best i think. I'm not interested in helping with a new protocol, and neither am I interested in merging a new protocol, unless there are really good reasons for that. I have yet to hear the first one. I understand that. I hope you understand me too :) Greetings, Steffen signature.asc Description: PGP signature -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
On 2009/10/26 16:35, Steffen 'stefreak' Neubauer stefr...@stefreak.de wrote: But if MPD will not accept a change to it's protocol and/or it's source i think a fork is not the best way. Then i would design an own protocol. You're free to do so. Good luck with your fork. - most protocols are Client/Server architecture based. (mpd too, but a p2p mode could easily be integrated.) What is the disadvantage of a client/server architecture? Why does that contradict with p2p mode? - most protocols do more than i want - like listing files and folders or user+password authentication and writing to the file system (ftp, nfs, smb). Don't implement what you don't need. All of the protocols you mentioned allow anonymous access. NFS doesn't have authentication (at least v3; NFSv4 has extensions for authentication). However NFSv4 with file listings and tags in virtual file attributes sounds like a clever solution... there might be more clever solutions involving HTTP or WebDAV. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
On Mon, 26 Oct 2009 15:37:46 + Matt Wheeler m...@funkyhat.org wrote: There is already daap, and there are standalone daap servers, perhaps mpd could act as a daap client rather than inventing a new protocol. daap is proprietary and i think we don't want to get issues with apple because of it's licensing (http://en.wikipedia.org/wiki/Digital_Audio_Access_Protocol#Description). Further we had to look at itunes regularly if the protocol has changed or such.. i don't think daap is an alternative. iTunes is already a daap client and server, for example (however iTunes will not speak to non-iTunes clients, but will speak to non-iTunes servers). That's not good enough imo :/ and it's client/server again, isn't it? No need to reinvent the wheel when what you want is already there :-) Hmm it must be validated if it really is already there... Thanks Thanks too :) didn't know daap before... Steffen signature.asc Description: PGP signature -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
2009/10/26 Steffen 'stefreak' Neubauer stefr...@stefreak.de: snip daap is proprietary and i think we don't want to get issues with apple because of it's licensing (http://en.wikipedia.org/wiki/Digital_Audio_Access_Protocol#Description). Further we had to look at itunes regularly if the protocol has changed or such.. i don't think daap is an alternative. I don't think there would be a need to keep up to date with iTunes' implementation, only with other open source implementations. Don't know how others would feel about this though, and I'm not clear on the licensing issues either. I do know that Tangerine, Banshee, Rhythmbox and amaroK (and others I think) support daap at the moment. That's not good enough imo :/ and it's client/server again, isn't it? Yes the client and server parts can be implemented separately, although I think mpd acting as a daap server could be very straightforward. Effectively p2p is just a client and a server at both ends, there is no real difference. I don't have time to attempt to implement this at the moment though, and I don't know if anyone else would be interested in doing so. Hmm it must be validated if it really is already there... Yes, I'm not certain this is the best solution at all, just thought it was worth mentioning as a possibility. -- Matt Wheeler m...@funkyhat.org -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
On Mon, 26 Oct 2009 16:09:48 + Matt Wheeler m...@funkyhat.org wrote: Yes, I'm not certain this is the best solution at all, just thought it was worth mentioning as a possibility. Yes, thank you, it is interesting. I am not certain either because i have not looked at it enough :) Greetings, Steffen signature.asc Description: PGP signature -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
I think Steffan's proposal is interesting. At first I couldn't figure out what he was proposing but its clearer now. However it may be more complex and have some hidden issues that need to be well understood. Avuton's points are also very valid, there are many ways to do most of what Steffan has proposed. Although I think setting up an nfs link is a little harder than he claims (I would not let my wife try to do it, the support would overwhelm me. . . ). I also would like to see MPD kept as simple as possible, the best way to keep software reliable. I also like Max's idea for a client-server way to have MPD instances find each other automatically and connect to content stores. I'm currently doing this with Avahi (Bonjour-Zeroconfig) and NFS. It works pretty well (but sometimes spontaneously breaks and some routers seem allergic to it). It also requires a lot of infrastructure setup on each machine its on. Steffan proposal is closer to a peer to peer version of the same thing. I would advocate for using existing protocols whereever possible when dealing with networking or file systems. The potential traps for something new are enormous. The issues to be addressed I think are: 1) Security. If this isn't really well thought through MPD could very quickly become persona-non-grata everywhere. 2) Since this is about sharing the database and the content some other issues around the database (extended tags and cover art for example) must be planned for or it will be a complete reset for all the work that would be done in the future. 3) Sharing. Is this a way to share libraries with others? That is loaded as well. No one needs an RIAA lawsuit. 4) Moving content out of the local network runs into bandwidth issues real fast. Most of the content I'm concerned with is FLAC and some starts as very high bit rate files. That won't work over an external network very easily. And there are still the security issues going to the outside world. MPoD on the iPod however does have a feature for using the MPD protocols to push your content to your iPhone wherever you are. 5) Syncronizing multiple clients in the same house is critical. If the clients are more than a few milliseconds out of sync it becomes very annoying. Be careful that this doesn't turn into a Slimserver (squeezecenter, squeezeboxserver this month) clone. They have already solved many of these problems (benefits of have a major corporate sponser to fund). But its gotten pretty complex and the Logitech marketing guys are driving it (who have no clue who the users are or why they would buy a Squeezebox). The point being to get really clear about what problems you intend to address how to most simply address those problems and minimize the unintended consequences. To that end I would like to see something like Max's proposal, that automatically connects an authorized MPD client instance to an MPD Host (MPD instance with connected library of content, clear names will really help here) and make the content available. If the two can be syncronized in playback (like squeezeboxes) that would be very helpful. If extended databases can be created and shared that's even better. Important is to not break existing implementations unless there is a clear migration path or there will be a lot of unhappy users. If two instances of MPD are sharing with each other there are issues of duplication of content and issues of looping endlessly as local vs. remote get blurred. Demian Martin Product Design Service -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
That's the point though. Why introduce this complexity when it's unnecessary? Let's state a much simpler way without complicating how things currently work. I agree that the underlying functionality is already provided in enough ways. But maybe MPD could provide a bit of help here and there to make it easier to setup such a thing with a minimum of extra configuration. E.g. if you want to access the filesystem currently you end up having to read MPD's config file (which may be pretty tricky to find: list processes running, guess which one is the mpd you care about, extract the config file name from the command line). Here MPD could help by providing this config info via a command. That would also help clients which want to access the song-database to find album covers. Stefan -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
On Sun, Oct 25, 2009 at 8:41 AM, Stefan Monnier monn...@iro.umontreal.ca wrote: That's the point though. Why introduce this complexity when it's unnecessary? Let's state a much simpler way without complicating how things currently work. I agree that the underlying functionality is already provided in enough ways. But maybe MPD could provide a bit of help here and there to make it easier to setup such a thing with a minimum of extra configuration. Autodiscovery and use of upnp/dlna/daap would be about as easy as it gets, and for media access and streaming; it's not a rejection of the technology, if it was done well, I'm sure it would be accepted. Can't expect devs to scratch your itches if it's not their own (though sometimes they do anyhow). E.g. if you want to access the filesystem currently you end up having to read MPD's config file (which may be pretty tricky to find: list processes running, guess which one is the mpd you care about, extract the config file name from the command line). Here MPD could help by providing this config info via a command. That would also help clients which want to access the song-database to find album covers. Because that's a hack at best; I'm not saying covers should or should not be part of the protocol, but hacks really shouldn't be part of the protocol and coverart support appears to be great enough without local filesystem access with the various coverart downloaders and cachers. A non hack would be the client asking the user where the music root is (if they even have access to it) so the client doesn't assume that the user wants the client to access his filesystem. -- avuton -- All opinions stated above are mine and do not necessarily reflect those of the US secret service. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
On Sun, Oct 25, 2009 at 9:58 AM, Steffen 'stefreak' Neubauer stefr...@stefreak.de wrote: On Sat, 24 Oct 2009 06:12:17 -0700 Avuton Olrich avu...@gmail.com wrote: Point is MPD can /easily/ do what you're looking for without reworking a wheel. No that's not true. You can _not_ do it easily, that's my point. All ways you posted are complex and static. And all those things are not what i wanted. I don't want to only share the music on the network - there are ways to do that and i know it (like NFS). But how complicated is it to set up and maintain an NFS server compared to setting up and maintaining MPD? And how static is that setup? It isn't easy. It is easier for the developer, of course, but not for the user. This thread is bordering on trolling but I'm going to briefly take the bait and never read it again. There is nothing complex about setting up NFS, it takes less than 3 minutes of googling and setup on any easy-to-use distribution; maybe 10 minutes if the user has never used a computer before as long as the user knows how google works and can follow instructions. Secondly, option #4 is what you're talking about, but if the user isn't experienced enough, nor willing to take the time to put into setting up NFS, then they wouldn't setup for MPD, much less dlna/upnp/daap. And this is before all the crazy security risks and precautions that would then have to be built into MPD to take advantage of your cunning plan. -- avuton -- Math is hard, let's go shopping! -- Barbie -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
Hi *, I have the same problem about mpd. I need a transparent access to my setuped instance of mpd anywhere on the network (i like to listen music from my collection from work. No decoding and encoding only transparent data transfer. Only then the quality of the record stays same as was in the other mpd instance on the network. This would require implementing new TCP or UDP port or a upgrade in protocol interface. Or another example of use - You connect to your home wifi and wanna play newly captured files from your notebook to your homeaudio (wireless router with mpd and USB card). That's It. Then you can P2P, would that be easy for you ? :) metyl On Sun, Oct 25, 2009 at 5:58 PM, Steffen 'stefreak' Neubauer stefr...@stefreak.de wrote: On Sat, 24 Oct 2009 06:12:17 -0700 Avuton Olrich avu...@gmail.com wrote: That's the point though. Why introduce this complexity when it's unnecessary? Let's state a much simpler way without complicating how things currently work. [..] Now, why did I say that's the point? MPD was (initially) created to be simple. A few different projects had the same idea but tried to do it with too much complexity. They tried to do too much all at once when it was better to keep things simple and most of them have been abandoned due to being unable to reach any kind of goal. I understand that. Point is MPD can /easily/ do what you're looking for without reworking a wheel. No that's not true. You can _not_ do it easily, that's my point. All ways you posted are complex and static. And all those things are not what i wanted. I don't want to only share the music on the network - there are ways to do that and i know it (like NFS). But how complicated is it to set up and maintain an NFS server compared to setting up and maintaining MPD? And how static is that setup? It isn't easy. It is easier for the developer, of course, but not for the user. I thought of something different - the MPDs would connect P2P to each other and tell what songs they have in their database and then could stream those to each other. Most of this functionality is already implemented, a client is already able to list all songs in the database etc. Only the ability to connect to other servers, streaming functionality, the ability to merge those song databases and the ability to play songs from this stream would have to be implemented - some other stuff too, of course but these are the main things that change i think. I don't see too much complexity in this - it would make some things simpler and would offer many new use-cases for MPD. I understand your concerns about the complexity of MPD too - but i don't see too much complexity in this. The only really critical about it is that the protocol would change imho. But it can be done backward compatible for the clients. Also see: http://mpd.wikia.com/wiki/What_MPD_Is_and_Is_Not I've seen it. http://lmgtfy.com/?q=where+is+music+player+daemon+irc%3F Ok, only looked at the Developement page, didn't want technical support ;) http://mpd.wikia.com/wiki/Special:WhatLinksHere/IRC Greetings, Steffen -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team -- This mess was sent using 100% recycled electrons. If you want to get rid of this mess just turn off your computer, -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] server to server connection
On Sun, Oct 25, 2009 at 11:20 AM, Metyl Methylius the.me...@gmail.com wrote: Hi *, I have the same problem about mpd. I need a transparent access to my setuped instance of mpd anywhere on the network (i like to listen music from my collection from work. No decoding and encoding only transparent data transfer. Only then the quality of the record stays same as was in the other mpd instance on the network. This would require implementing new TCP or UDP port or a upgrade in protocol interface. Or another example of use - You connect to your home wifi and wanna play newly captured files from your notebook to your homeaudio (wireless router with mpd and USB card). pulseaudio -- avuton -- All opinions stated above are mine and do not necessarily reflect those of the US secret service. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
