Had a short mySQL outage this morning. No idea why. Seems to be a problem with the 99k control panel server also. Some disk space issue. Everything was sorted out in a jiffy and that is the important thing I guess.
Another thing that shocked my slightly when I was browsing through the database was that the nucleus_ tables has increased with over 100% for apparently no reason. I hadn’t realized how the NP_Related plugin for Nucleus stored its data. Or should I say that I hadn’t realized how bulky its caching system was. The nucleus_plug_related_cache table is now over 4650 rows. Ouch. Despite how useful this feature is I’m considering dropping it because of the prolonged access time and database usage.
As it stands there are three major tables in the database that make up the bulk of disk space usage. First, there is the nucleus items themselves, second there is the related cache and finally there is the matter of the mp3 database, which I never seem to be able to complete.
Right now, the problem (with the mp3db) isn’t database related, rather my sense of perfection and the investment of time required to get the stupid cataloging program to scan, store and export the songs. Tens of thousands of lines and a need to have artists and albums being named and sorted using consistent rules. I.e. not having the same album being spread out over three or four access points just because of a pesky variation in spelling .. e.g. “Manowar”, “ManOwar”, “ManoWar” etc. And just devising a way to update that table in a sensible way (if you consider the constantly growing offline catalogue) is a nightmare. The entire idea lacks viability. But I will do it anyway.
Contact
Lifestream




