Mnyb;695864 Wrote: > *Enhancement* request 142 is a problematic one for a reason I think. > > As the server software is committed to a solution where it never ever > write to the files directly and this is very dear to many users. This > paradigm wins in this situation. > > This will undoubtedly always lead to a situation where you loose all > ratings, Erland has gone to some lengths in his plugins with an > externally available trackstat backup . But this is for technical > reasons not safe either as there are circumstances where the file can't > be 100% identified . One way it works is by the extremely geeky music > brains id and some other means . > > There are great ideas that could be implemented if the server did not > treat the dB as a temp a mere reflection of the tags . > But that would need a whole other level of programming where the dB > always could be recovered and translated between schema changes and not > needed to be " cache cleared" aka tossed away for every minor scanner > issue and it would need to hash every file during scan to > create unique identities but eventually for safety reason it would need > to write an Id to the file . > > Then the dB could be augmented by all sorts of info and associated > functionality not only ratings that would only be the 1% of what would > be possible .
I fully agree with your last statement. Solution is to store info in hidden files in the media directories ( in addition of database). See how Picasa works with photos. No need to reinvent the wheel. -- reniera ------------------------------------------------------------------------ reniera's Profile: http://forums.slimdevices.com/member.php?userid=40705 View this thread: http://forums.slimdevices.com/showthread.php?t=94109 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
