On Tue, Apr 14, 2009 at 3:05 PM, Max Kellermann <m...@duempel.org> wrote:
> On 2009/04/14 15:38, Sébastien Houzé <sebastien.ho...@gmail.com> wrote:
> > Ok, but I run many mpd processes, this implies running many mpdscribble
> > too... is a playlog_file option in mpd.conf better ?
> > Think about some analogy with Apache accesslog and errorlog. Logging can
> be
> > optionnal this way, and why not loggin format configurable (data, IP,
> song)
> > like in Apache.
>
> Hmm, I'm not comfortable with that idea, because this is a very
> specific feature request which can be solved with a client. Might be
> more difficult for you because you're running multiple MPD instances,
> but you can use the same init script for starting one mpdscribble per
> MPD instance.
>
> Any other opinions on the mailing list?
My very late two cents. If I'm way off about something, just correct me -
these are just thoughts.
I'm not really sure whether it's best for this feature to end up in a client
or in MPD. Good to keep MPD slim, but also good to not have to make sure a
client is running to get your statistics. (I realize there's a wiki page
that states that MPD is not a statistics server.) In any case, it seems
like the most basic thing we'd be looking for out of this is play counts,
and maybe a "last played" and "skip count" sort of thing. Note that none of
these require full logging anyway - just some incrementing and such. They
also wouldn't require a huge amount of code to implement, so it's not
entirely unreasonable to think about putting them into MPD. Either way,
assume that we're going to get some statistics generated. But how are they
stored and accessed? This seems like a great use for the sticker database
to me. There are already suggestions in the documentation to store ratings;
why not these basic statistics? This makes them easily available to
multiple clients (important! don't want to add mpdscribble-client
communication), and also makes them easier to backup/transfer.
If we go the client route, I don't see a huge problem with requiring one
instance of mpdscribble per instance of mpd, though of course it's less
convenient. In any case, avoiding the logging method seems good - it's
overkill, and only available locally. Besides, the idle commands give a
great way to get just the information you need. (Incidentally, I've been
wondering about suppressing status commands from clients in the logfile -
I'd like to run in verbose all the time just in case a bug crops up, but the
vast majority of the content is just ncmpc asking for status. I know I can
kludge it locally, and also that idle commands will decrease command volume,
but that's not trivial.)
As long as we're talking about improving the sticker database functionality,
and clients are beginning to use it, I think there's one thing that needs to
be considered: how do you preserve stickers when moving/renaming files? I
know we don't want mpd to actually manage the files, but maybe there should
be some way to let it know about a rename? Or do clients have to do a
"sticker list" for the original then several "sticker set"s for the new?
The world would of course be a better place if tagging were standardized and
this information could just go along with the file, but we've got to make do
somehow.
Jeffrey
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
