I went on some little investigation about the problem below and, I will try to
give an explaination.
It is, probably, due to the fact that upon forcing a rebuild, the directories
present both on the disk and in the tagcache files are not processed again to
save time. In this case, if a directory is removed, the rebuild algorithm
fails noticing it because it checks if all the remaining directory pathnames
(one by one) are already cached (and they are) but doesn't verify that in
cache there is something "more" than on disk. Of course, by deleting the
tagcache files the incoherence disappears.
I tried uncommenting line 2427 in tagcache.c:
2426. case Q_FORCE_UPDATE:
----> remove_files();
build_tagcache();
break ;
to remove files before rebuilding and, of course, it works.
What about changing the current option in the configuration menu to something
like "Update tag cache" and introducing a new "Force tag cache update" that
also removes current cache files?
Kind regards,
Gaetano
On Friday 02 June 2006 18:20, Gaetano Vocca wrote:
> Hi all,
> maybe I have found a little bug in the tagcache rebuild process.
> My audio file a re grouped by composer but tagcache rebuild seems not to
> care of deleted directories
> This is the procedure:
> 1) Rebuild tagcache
> 2) Reboot
> 3) Remove one directory containing all the files belonging to one composer
> 4) Rebuild cache
> 5) Reboot
>
> At the end of this process the composer is still present in the Tag menu
> but when audio files are selected for playing an error is issued.
> As soon as I have some time I will be happy to try investigating myself.
>
> Gaetano
>
>
>
>
>
>
> ___________________________________
> Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
> http://mail.yahoo.it
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
