Re: [Musicpd-dev-team] mpd patch | mpd discussion about stickers
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 sets 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 #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;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
Re: [Musicpd-dev-team] mpd patch | mpd discussion about stickers
On 2009/04/14 06:05, Sébastien Houzé sebastien.ho...@gmail.com wrote: I have some time to spare on mpd in coming weeks and have opened my first mantis issue with a little patch : http://musicpd.org/mantis/view.php?id=2255 I don't think the log file should be used for anything but error analysis. We simply cannot give any guarantees on the text format. If you want to have statistics, run a client like mpdscribble. We could add statistics support to mpdscribble. NOW, ABOUT STICKERS Stickers is an interesting feature, but when you have many mpd instances sharing the same db sqlite doesn't fits well (too much concurrency). Please provide benchmark results to back that thesis. Right now, I cannot imagine this is even measurable. So I have searched for an elegant solution to be free to choose any database system as a sticker storage backend. I've found very few libraries in C with database abstraction capabilities, except libgda : http://www.gnome-db.org/CodeExampleGdaSelect With libgda stickers can be stored in MySQL, sqlite or PgSQL to name a few. This implies, mainly : How much faster will MPD be when using MySQL or PostgreSQL? - Renaming in mpd.conf sticker_file into sticker_dsn (values can be e.g. *sqlite:///somepath/somefile.db* or *mysql://user:p...@host:port/db*) - Updating configure.ac : --enable-sqlite becomes --enable-sticker (or --enable-gda ?) - Refactoring sticker.c,h files to use libgda Please tell me what do you think about it. We could make the sticker storage pluggable, so you can write a libgda backend. I'm quite happy with native sqlite support right now, and I had initially considered using BerkeleyDB instead of sqlite. When sticker storage is pluggable, we can extend that interface to store the whole MPD music database. Max -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] mpd patch | mpd discussion about stickers
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?
I don't have benchmarked at the moment. Basically I was thinking that sqlite
had poor performance (big file lock) if many mpd processes were running
concurrent SELECT against it. It seems not, according to sqlite
website.
sqlite is quite fast, in some use cases even faster than traditional
database servers. Even if it's slower for us, I don't think it's too
important. MPD isn't pushing a lot of pressure on the database.
sqlite is great because it doesn't require any special setup,
PostgreSQL or MySQL would be too much work for most MPD users.
I even found some interesting feature :
http://www.sqlite.org/sharedcache.html
What do you think of using sqlite3_enable_shared_cache() in mpd ?
This doesn't make multiple mpd processes perform better, but a single one
yes.
No, not at all, because MPD doesn't open the sticker database more
than once at a time.
We could make the sticker storage pluggable, so you can write a libgda
backend. I'm quite happy with native sqlite support right now, and I
had initially considered using BerkeleyDB instead of sqlite.
When sticker storage is pluggable,
You think about storage plugins like, e.g. : flat file, sqlite, bdb, xml ?
If so, I think some dsn syntax sould be used in mpd.conf.
For example
sticker_file /somepath/somesqlitedb.db
should be instead
sticker sqlite:///somepath/somesqlitedb.db
More like:
sticker {
plugin gda
uri sqlite:///.
}
Or:
sticker {
plugin sqlite
file /var/lib/mpd/stickers.sqlite
}
we can extend that interface to
store the whole MPD music database.
You mean ID3 tag cache too ?
Yes.
Max
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
