Max Kellermann <[EMAIL PROTECTED]> wrote: > On 2008/10/09 10:52, Qball Cow <[EMAIL PROTECTED]> wrote: > > Hi people, > > > > Just a quick fix for an api-breakage in git. > > With commit 6dcd7fea (if I am not mistaken) the error returned when you > > try to save to an existing playlist is wrong. > > Instead of MPD_ACK_ERROR_EXIST, MPD_ACK_ERROR_NO_EXIST is returned. This > > is obviously wrong and breaks gmpc. > > > > Appended is a small patch to fix this. > > Oops, my fault. Thanks for the patch, I have applied it to mpd-mk.
Thanks, applied here, too. > Maybe time for a MPD test suite..? That would be an excellent idea. I've wanted one for a while but never found the proper time/motivation to do it. > > Furthermore I would like to request, once again, a way for the client to > > see if the/a playlist(s) have changed. > > Now there is no way for me to detect if another client modfied, added or > > removed a playlist. > > I know the listener protocol will probably solve this, but given that it > > could take a while before that is implement and I have rewritten gmpc to > > support it I could use a workaround now. A simple counter that updates > > on a change is sufficient for me, to have it atleast consistent between > > clients. > > There is already the playlist version. He means the playlists stored on the filesystem. I'd rather not have a one-off change and just do a proper listener protocol implementation. > > 3rd thing, is there a roadmap? I want to make one for gmpc, but > > without one for mpd.... Last one I posted was here, I'll try to update it over the weekend http://thread.gmane.org/gmane.comp.audio.musicpd.devel/176 > I have no roadmap yet. I have a lot of ideas, and I'm trying to get > stuff done, instead of writing a roadmap... yes it would be useful, > but I think we'll talk about new features which require client support > when time comes. Right now, I'm stuck with cleaning up the code base, > and only after this is finished I'll be able to implement protocol > extensions. > > > 4th thing, what is going to happen with normalperson and cirrus mpd > > version. As client developer I am getting nervous seeing two > > separate branches I have to support. Because there are different > > plans as of features to implement in mpd this will be a problem for > > me in the future. > > I know, and I feel sorry for that. I have no choice but continue my > own branch (except quitting MPD development). I want stuff in MPD > which isn't possible in the master branch. Max: Exactly what do you want that's not possible in the master branch? The listener protocol can be implemented entirely with one printf(3)-like function: int client_broadcast(const char *fmt, ...) Absolutely no need to expose struct client everywhere like you're doing in your branch. And the thing with mpd playing multiple audio tracks/playlists just duplicates functionality provided by multitasking/multiuser operating systems for a corner case. Things like PulseAudio already take care of mixing audio to multiple devices, too. It's not like users don't have 30K other TCP ports to bind to or UNIX socket paths (thanks for that, btw). The only real issue with this is sharing the DB cache file, but we just need to flock/fcntl/rename the file to prevent concurrent reads on updates since we already handle SIGHUP to reread the DB. (The "update" command is most efficiently called on the same machine mpd runs on anyways because something based on inotify can call it, so access to send a SIGHUP shouldn't be a problem). > > 7th. What is the state of the 30% cpu usage, alsa output bug? I kind > > of lost track of it. But the reports people still make, it is still > > an issue. > > I'll work on that, but unfortunately, I've been busy with too much > other stuff. It will be solved, and I am aware that it is important. We both agree 100% on this :) -- Eric Wong ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
