Re: [Musicpd-dev-team] Database backend
Thanks for the suggestions all. Rasmus: A full database update on my setup seems to take forever (literally: I've left it running for 3 or 4 days before). J. Alexander Treuman: Yes I've thought in the past of doing something like your suggestion, using symlinks. I also have an 'unsorted' directory solely for the purpose of, well, unsorted files. However, because of my laziness this directory is massive (probably a good 40-50% the size of the entire collection). My view is, though, that the MPD database should really allow to perform these basic operations on it without me having to resort to scripts, symlinks, manually playing with modification times/dates, etc. My original thinking was that it would be nice to use something like SQL so that it's easier to integrate MPD with other music systems/setups that also use SQL. Whether it would actually make a great difference in practice, I don't know... Jeffrey: I had no idea the database was in a plain-text format! Interesting :) -- Jonny Tyers -- ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Database backend
hmm.. i am not sure what you are doing wrong then... an UPDATE should only apply CHANGES to the database. this measn if you have removed 2 folders, only 2 folders will be removed, the rest stays as it is. 30k songs here, but NFS mounted, which is almost certainly the reason. Plus there are a lot of WMA/WAV/RealPlayer/etc files in there that MPD won't like, I'd guess - it may be scanning all of those every time I update because those files will never make it into the database (because it doesn't recognise them). (Note, I'm not actually sure if MPD can't read WAVs, WMAs, etc but I use those as an example - there are all sorts of filetypes in there, some of which I'm sure MPD can't read!) i was NOT talking about the create-db option of mpd. You should never have to use that anyway, since its automatically run on 1st start of mpd. afterwards only use the update function which should always be finished in a few seonds (I have 20.000 songs and it takes not longer then 5 seconds, depending on how much has changed) I'll install mpd on the box with the music on it and see how it performs. If it really only takes a few seconds to update (after first update, of course) then I'm an idiot for not trying it before :) -- Jonny Tyers -- ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] Database backend
Max once thought about using SQLite as backend. He even was clear that, if done right, there shouldnt be ANY regression in speed. Not sure what the plans are for now. I guess there are more important things :) Fair enough. :) In the meantime, is there any way of selectively removing songs/albums/etc from the MPD database? Or is the best way to delete the database files or make MPD recreate it via --createdb and repopulate from scratch? -- Jonny Tyers -- ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
[Musicpd-dev-team] Database backend
I know that people have asked why MPD doesn't use an SQL database in the past, and I know also that the reason has been performance. I'm not disputing this, and I don't want to start any kind of flame war, but aside from performance the use of SQL does allow for more features (or for making such features much easier to implement): 1 - Smart / dynamic playlists via complex SQL queries 2 - Easy maintenance of the database by external utilities using standard SQL 3 - Housing database on different machine from MPD (likely to cause a performance hit, I know) 4 - MPD clustering (an unlikely use case for most of MPDs users, I admit) For me personally, the second option is actually a biggie - currently one cannot manage the MPD database at any kind of granular level. Asking mpd to do an 'update' on its music directory has never completed for me - on an NFS-mounted 100GB+ music library. When I add things to the database I add things by name (e.g. mpc update Artist), but if I move files around or want to remove music from MPD's library, there doesn't seem to be any command to do that. I can only do 'update' on parts of the library and hope that MPD picks up that files are deleted / changed. I notice that MPD will also only rescan files if their modification date has changed; there seems to be no way to force MPD to re-scan a file/directory regardless of its modification time (which is useful in some situations). If these commands/features were added, I'd probably have less of a need for SQL personally, although the first idea above would be nice. I should also emphasise that in my view this doesn't have to be an all-or-nothing decision. Why not use a database plugin, and default to the internal MPD database, but allow the option of using SQLite/MySQL/etc? Wouldn't this satisfy both those who don't care/need the performance and those who want the flexibility of SQL? Kind regards, Jonny -- ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
