chaug wrote: > Thanks. However, this did not work. It was even worse than with the > default query: not only did no results show up but LMS became completely > unresponsive and I could not even fix this by stoping and restarting > LMS. I actually had to reboot the whole device... If fact, as I write > this, I realize that not even this has worked. Even after rebooting the > NAS, LMS does does not respond at all. I actually dont know what to do > now. > Really sorry to hear that, if it's not possible to run this query, which is really simple, my feeling is that something strange is going on in your setup and it will be hard for me to help you since I don't have any way to try it myself. I think you basically need to use some other outside tool to check the tags, doing it by querying the database won't work if it's this slow. I could see the above query making the web browser hang if most of your files is missing musicbrainz identities, but it shouldn't hang the NAS LMS runs on. I'm sorry to say that this just gives me more indications that it's very hard to get LMS to work reliable on NAS boxes, it can work for a while but eventually it will break in one way or another.
If TrackStat is installed it runs some queries towards the database at startup, probably these queries cause the same issues as when you executed the above query via Database Query plugin, so I suspect this is what's causing it to not work. I'm sorry to say that I'm not sure how to get TrackStat to work reliable in a setup where it isn't possible to run these kind of database queries. I would strongly recommend you to not use musicbrainz identities in a setup like this because using musicbrainz identities is probably going to make the performance problem worse rather than better. However, to get things going, you probably need to deactivate the queries TrackStat does at the startup, there is a few different ways to do this: SOLUTION 1 (ONLY RECOMMENDED IF YOU DON'T PLAN TO USE TRACKSTAT) The easy solution is just to completely uninstall TrackStat, you would probably have to find the Cache directory of LMS and login via ssh and remove it, I suspect it's in /var/lib/squeezeboxserver/Cache/InstalledPlugins/Plugins/TrackStat but I can't say exactly since I don't know your setup. SOLUTION 2 (DEACTIVATE MUSICBRAINZ IDENTITY LOGIC IN TRACKSTAT) Try to login via ssh, find the preference folder, probably in /var/lib/squeezeboxserver/Prefs or something similar, find the file plugin/trackstat.prefs and change the line: musicbrainz_enabled: 1 to musicbrainz_enabled: 0 And restart everything and see if it comes up, TrackStat still runs some queries but the ones causing the biggest performance issues are deactivated after this change. SOLUTION 3 (DEACTIVATE REFRESH OPERATION IN TRACKSTAT) Try to login via ssh, find the preference folder, probably in /var/lib/squeezeboxserver/Prefs or something similar, find the file plugin/trackstat.prefs and change the lines: refresh_rescan: 1 refresh_startup: 1 to refresh_rescan: 0 refresh_startup: 0 And restart everything and see if it comes up, this will deactivate all the queries TrackStat runs at startup, so it should definitely help but I wouldn't trust TrackStat in a setup where both these needs to be deactivated. I think you should at least re-activate refresh_rescan after it have come up and see if it hangs at the end of a rescan, if it doesn't a solution is to set refresh_rescan: 1 but refresh_startup: 0. However, if you have startup problems it would surprise me if you won't have rescan problems also. SOLUTION 4 (DELETING THE DATABASE) Try to login via ssh, find the Cache folder and delete the library.db, library.db-shm, library.db-wal files and delete them. This will delete the database parts which are usually deleted during a full rescan. After deleting these files, restart the system and preform a full rescan and see if it works again. These are the alternatives I can come up with for now, independent which one you choose I would recommend to not rush it, if it seems to hang, let it stand there a few hours and see if it solves it self after some time, it could be that it just needs some time and will work after that. Shutting it down abruptly can in worst case corrupt the database and make it completely unusable and then you have lost all TrackStat data unless you have a backup you can restore. If you have Custom Scan plugin also installed, it could also be that it is causing the startup issues as it runs similar queries at startup as TrackStat. The procedure is basically the same as the above solution 2, 3 or 4, but it's using the plugin/customscan.prefs file instead of plugin/trackstat.prefs. Unless your tags or something else have changed in your setup it's hard to say why you haven't seen these kind of issues before, but I have seen cases where the SQLite database used by LMS suddenly becomes very slow for a specific operation and after it has finished executed it's fast again, so it could be that it's just a temporary issue. Finally, if the problems are really bad, there is an alternative to solution 3, to delete both the library.db* files and the persist.db* files. This will delete the TrackStat data also, but if the persist.db files have become corrupt this might be what you have to do. Hopefully you have a backup of the TrackStat data which you can restore afterwards when you get it working again. ------------------------------------------------------------------------ erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=35962 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
