The first time I removed some files before running the updater and there the missing files were not removed. I then tried a second time while tue updater was running and that time I noticed the old entries were removed and the new ones added as expected. The broadcast also worked in the second test so I guess I simply had bad timing Regarding the move of the files I'll open a request since I am not able to propose any patch. I would also like to request the possibility to physically remove a file from the disc when the entry is removed, of course with some different command or a parameter to choose, but I believe sometimes when you remove something from the medialib you also want to delete it from the disc. It is also much faster find something in the medialib then having to search it in the filesystem (where you cannot search by artist or some specific attribute). but I will try the devel before just to be sure is not yet there
2016-11-26 19:45 GMT+01:00 Erik Massop <e...@ixsop.nl>: > On Fri, 25 Nov 2016 13:08:32 +0100 > Michele Spelta <aspelt...@gmail.com> wrote: > >> forgot to add the list >> >> 2016-11-23 23:10 GMT+01:00 Michele Spelta <aspelt...@gmail.com>: >> > Hi Erik, >> > the link was exactly that. > > Removed. > >> > I tried the stuff included into the >> > source tree and it works but not as I would expect. >> > to be more precise what I did was essentially sanitizing some of my >> > files which means they got moved and their ID3 tags changed a little, >> > now the updater found all of the new files as expected and this is >> > good, it also did not figured out they were moved so I lost the >> > statistics... (not good but expected and acceptable since it is not >> > supposed to read into my mind). > > Seeing the lack of the word "move" in medialib-updater/main.c [1], it > seems that moves will indeed be delete+add. It seems that the used > filesystem monitoring API does have a hook to detect moves [2], but > that is not being used (nor is it guaranteed to work for all > 'backends'). > > Could you file a feature request at https://bugs.xmms2.org/, or > (better) send a patch? > > [1] > https://git.xmms2.org/xmms2/xmms2-devel/tree/src/clients/medialib-updater/main.c > [2] https://developer.gnome.org/gio//2.42/GFile.html#GFileMonitorFlags > > < big negative point is that it does not >> > remove the no longer existing old entries only thing I notice is that >> > the new entries have a status equals to 1 while the old ones have it >> > set to 3. >> > now I did not managed to figure out what these numbers means, can you >> > or anyone point me to were this is described? > > As nano noted, the numbers are enum entries [3], with 1 meaning "OK" > and 3 meaning "NOT_AVAILABLE". > > [3] https://git.xmms2.org/xmms2/xmms2-devel/tree/src/ipc.xml#n81 > >> > anyway if the number three means broken then I can easily search for >> > them and remove them > > Yup, 3 means not available, so that is the way to go. > >> > but still I would expect the updater is able to >> > do this by its own. Do I miss some special setting to enable this? > > The code [4] seems to remove entries when they are deleted from the > file system. Was medialib-updater running when the files were > deleted/moved? > > [4] > https://git.xmms2.org/xmms2/xmms2-devel/tree/src/clients/medialib-updater/main.c#n586 > >> > another thing that surprised me is that I did not get any indication >> > of changed or added entries in the medialib using the >> > broadcast_medialib_entry_added and broadcast_medialib_entry_changed in >> > my python code running in parallel to the updater, is that normal? and >> > in case it is how can I know if something is happening? > > That shouldn't be normal, and it works for me (using a devel xmms2): > > $ ./watcher.py > Entry 236 changed. > Entry 236 changed. > Entry 702 changed. > Entry 702 changed. > Entry 1069 added. > Entry 1069 changed. > > I did notice that the ordering of the statements having to do with > xmms/connector/ml in the attachment seem a bit sensitive. I don't know > enough about the python bindings to know why straight away. > > Would you mind filing a bug report with your program? We should at > least print a warning when the ordering seems off. > >> > >> > cheers >> > Michele >> > >> > 2016-11-20 14:00 GMT+01:00 Erik Massop <e...@ixsop.nl>: >> >> On Sun, 20 Nov 2016 12:36:19 +0100 >> >> Michele Spelta <aspelt...@gmail.com> wrote: >> >> >> >>> Hi, I see there was a script for doing the update of the medialib, but >> >>> the link is broken. >> >> >> >> Is the link you are talking about the link to >> >> http://nooms.de/media/xmms2-mlib-update.py on >> >> 0https://xmms2.org/wiki/Contribs#Medialib_updater? >> >> >> >>> now just remove all entries no longer in the filesystem and add all >> >>> the new ones can be good, but if possible I would also like to just >> >>> change the url in case the file was just moved. >> >>> also having this in the standard client would be good I suppose >> >> >> >> There is xmms2-mlib-updater in the main source tree at >> >> https://git.xmms2.org/xmms2/xmms2-devel/tree/src/clients/medialib-updater, >> >> but I'm not sure if it handles moves gracefully. >> >> >> >> Anyway, it can be configured using >> >> $ xmms2 server config clients.mlibupdater.watch_dirs "${dir?}" >> >> and you can either start it manually or with a >> >> symlink in ~/.config/xmms2/startup.d. >> >> >> >> On Debian this is available in the package >> >> xmms2-client-medialib-updater. See >> >> https://packages.debian.org/jessie/xmms2-client-medialib-updater. >> >> >> >> >> >> I hope that helps. >> >> >> >> Cheers, >> >> >> >> Erik (nesciens on IRC) -- _______________________________________________ Xmms2-devel mailing list Xmms2-devel@lists.xmms2.org https://lists.xmms2.org/cgi-bin/mailman/listinfo/xmms2-devel
