On 04/04/2009 07:58 AM, Christ Schlacta wrote: > I'll express the same dissenting opinion I have on the bug tracker: > > I think this is a really bad idea, and if it's implemented at all it > should be implemented carefully. When you have a large amount of > music to add to the database (imagine you just found your long-lost CD > album at the bottom of your closet..) you will generate a new > database update every 5-10 minutes, if not several in a row every 5-10 > minutes. (10 new files = 10 folder modification notifications, 10 > songs per album, 1 minute per song to rip and encode, 100 CDs in my cd > case right now.. all averages.) that will end up causing the mpd > database to be re-written each time there's an update, which will > cause the file system to reallocate the space for the database right > then and there each time. this will probably lead to a high amount of > database fragmentation on a fairly moderately full file system. > > Not to mention that updating the MPD database causes stuttering during > playback on every system I have. >
I never noticed that and I have ran mpd on many different systems. (Mac Mini ppc, intel, eee-box, beagle board, via epia, etc). Beside that, mpd is already capable of rescanning sub-parts of its database. To test do mpc update <path>. I once, a long time ago, wrote a crappy database watcher based on inotify. (http://git.musicpd.org/cgit/unmaintained/mpd-updater.git don't shoot me for the crappy code). No idea if this still works. ------------------------------------------------------------------------------ _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
