Thanks, Erland, for taking the time to write that post. I hope it will also others with the same problem. For me, the only way to get LMS running again was the option "Clean cache folder, including media library database, artwork cache etc." in the frontend configuration interface of the ReadNAS. The only problem with that is that it also seems to kind of uninstall most plugins. I'm saying "kind of" because LMS still remembers that I "have" those plugins and tells me that there are updates available for them (without listing them as installed, though). This is not a huge problem, only that the DataBase Query plugin is among those and if I select the "update" the whole trouble starts from the beginning. At the same time, selecting the "update" seems to be the only way to eventually uninstall it, since it is no longer listed as installed. So for the time being, I am stuck with a plugin update waiting to be installed which I never want to install again... I guess I can live with that, but if there is another way of uninstalling it, I'd be happy to try it.
Anyway, here is the full story of what I tried: I let the NAS (and LMS) run in its non-functional state for almost three weeks, hoping that this might give it sufficient time to sort out all the operations that seemed to be jamming the CPU/memory, but to no avail. In fact, as far as I could see from the NASMON interface, LMS (i.e. squeezeboxserver) actually disappeared as a process twice during that period. I simply restarted it both times. The other thing that happened was that the nightly backup that I had scheduled Trackstat to perform, increased in size steadily every night from 3344 kB on 24 April to 11109 kB on 15 May. And when I finally cleared the cache and got thing running again, it dropped back to 3848 kB. (Well, that's actually not surprising since I had to restore TrackSTat from backup and I think I chose the one from 24 April. The slight increase in size is probably due to some extra albums that I ripped in the mean time). So, here's what I did with your suggested solutions: erland wrote: > > 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. I did not try this since I really want to continue using TrackStat. erland wrote: > > 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. > I did not try this one either, since the whole point of this exercise was to start using musicbrainz IDs so that I can change the filenames of my music collection so that MusicIP will read them (i.e. remove all non ASCII characters). erland wrote: > > 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. > This is what I tried. Both refresh_rescan and refresh_startup are currently set to 0 but after I restarted LMS, the CPU load for LMS went up to around 100% again and the LMS webinterface remained inaccessible. Just as before. Same thing after rebooting the whole device. When looking at trackstat.prefs, I noticed that many of the variables have the same strange value: 1336855428. Just thought I'd mention it. BTW: the LMS preference folder on a ReadyNAS is somewhere in /c/.squeezeboxserver/... (forgot the exact path) erland wrote: > > 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. Tried all this, but to no avail. I did notice though, that the artwork.db was over 500 MB in size. After googling a bit, I decided that this is not extremely huge though, and disregarded it. erland wrote: > If you have Custom Scan plugin also installed (...) I do not have Custom Scan installed. erland wrote: > 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. I also tried this, but again, it did not change anything. (After restarting LMS, of course) So, although it seems that the ReadyNAS frontend button to clear the LMS cache does the same as what you described, it only worked when I did it through the front-end. So either there is some more stuff being deleted through the front-end or I didn't execute the rm command properly. My hunch is that the the front end button clears some more stuff, because, as I mentioned above, a number of plugins also (partly) disappear when I use it, most importantly, the database query and as long as I dont re-install (i.e. "update") it, things seem to work ok. So I'd like to say this for anyone else with similar problems: don't give up on using musicbrainz IDs. It seems to work also on a NAS. At least I can see the IDs in the TrackStat backup file, which, I take it, means that TrackSTat is using them. The problem that we're discussing here, hence, has is not caused by the musicbrainz-IDs that I've added to (parts of) my music collection. It seems to be closely connected to the database query plugin. ------------------------------------------------------------------------ chaug's Profile: http://forums.slimdevices.com/member.php?userid=47641 View this thread: http://forums.slimdevices.com/showthread.php?t=35962 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
