SlimServer crashing (won't start) with LazySearch (again)

[johnl@…]

Hi again Stuart,

Well the problem is back with Slimserver 6.3.1 (Win) and Lazysearch 1.1. When Lazysearch is in plugins directory and I start the server it crashes (slimserver won't start.) When I take Lazysearch out of the plugins directory the server starts up fine.

Could you send along some suggestions for debug and I'll send along results?

Thanks - John

[stuarth]

Yup - they were in the other ticket (now closed). I've copied them here:

To try to help narrow it down, could you try a few things?

1. Copy the slimserver database away somewhere safe because we'll try clearing it and it'll be useful to then look at what it was before it was cleared.

2. Move the LazySearch?.pm file out of the plugins folder and restart the server. This, I think, is what you said started up fine.

3. With the server running (but without the Lazy Search plugin), go to the web interface and go to "Server settings->Plugins", then change the loading settings at the top to "Load plugins on-the-fly".

4. Move the LazySearch?.pm file back to the plugins folder.

5. Refresh the SlimServer? web interface and navigate back to the "Server settings->Plugins" page. You should now see the lazy search plugin listed. I think it should have also tried to load it, but if not try ticking the Lazy Search plugin in the list below.

If the above does load the plugin after the server has started up, and immediately crash the server, then it really does look like a problem with the plugin.

As a workaround, you could try a complete database clear-and-scan ("Clear library and rescan everything" on the server settings page of the web interface), to see if that helps. If it does, I'd be interested in seeing the database file you copied somewhere safe as it indicates that something in the database is causing the plugin problems.

I'm pretty sure we can track that down, but have a go at the above and report back first so that I've a better idea of what to go on.

Ideally, it would be good to capture the message log, but lets try the above first to save the trouble that might cause.

Thanks for reporting this, and I'm sorry you're having trouble.

[johnl@…]

Stuart -

Can you explain where to find the database file? Also, I don't have the info on starting in debug mode - can you send that along?

John

[stuarth]

(For completeness of records, the original reporting of this problem was under ticket:14)

Yup; the database file is called "slimserversql.db" and, on Windows, I believe it's in the location given on the wiki:

 http://wiki.slimdevices.com/index.cgi?SlimServerDatabaseFile

As for running with debugging, I think the following might help (also from the wiki):

 http://wiki.slimdevices.com/index.cgi?LogFile

Remember that you should stop the SlimServer? background process before doing this since you can only run one copy at once. You should be able to do that from the little tray icon in the bottom right-hand corner of the screen (I think - I don't run it on Windows so I'm going from memory).

Unfortunately you're bound to see the log file fly past and the failure to load a plugin generally happens quite early. Quick use of CTRL-S and CTRL-Q to pause/resume the output might help. Alternatively, you can try to log to a file which might be easier (I've not tried this since I'm not on Windows at the moment):

cd C:\Program Files\SlimServer\server
slim --d_plugins >c:\log.txt 2>&1

You won't see any output, but it will hopefully be building up in the file c:\log.txt (a text file). By the way, if that works for you on Windows drop a note here and I'll clarify that in the wiki as it's useful for other people when they're trying to capture the logs.

Good luck! I've not had many repors of difficulties for quite a while so hopefully it'll just be either a configuration problem or something peculiar about your database - we ought to be able to get to the bottom of it, though.

[johnl@…]

Stuart,

Thanks for the WIKI references - OK so here's what happened:

1. I copied a backup of the database
2. I made sure the lazysearch file was NOT in plugins directory
3. I set the server to load on the fly
4. I restarted the server
5. I copied lazysearch into plugins dir
6. I confirmed it say lazysearch at plugins page - options checked ON automatically when I arrived there
7. Search button did NOT trigger lazysearch on SB3 (even after SB3 power off/on)
8. went back to server, and told lazysearch to rebuild it's database
9. slimserver crashed within a few seconds

My slimserversql.db is > 1.3Gb - how should i transfer that to you if you need the file?

John

[johnl@…]

Stuart,

A couple more things...

1. Sorry about the "Search button does NOT trigger lazysearch thing in previous report...mea culpa...I missed that I needed to reset the option to bind to the SEARCH key. In fact it responds just fine.

2. The database that causes the crash when zipped is 14.5 MB

3. I've rebuilt my main db and the lazysearch db and the systyem seems to be running fine now. Odd thing is that the min database is set to rebuild at 4am each night...so I thought lazy would have started working in the last day or two. Also, why did a manual rebuild seem to make the difference?

This problem seems to creep up periodically for my system - do you want to take a look at the DB even though the problem has gone away?

John

[stuarth]

Well, I'm glad we've got over the problem that was stopping you, but there does seem to be something odd going on there.

Yes, I think it would be useful if I could take a look at your database file. As it's quite large you might want to take a look at a we service like:

 http://www.transferbigfiles.com

You might want to password-protect your ZIP file if you're concerned about anybody looking at it.

If you drop it there I'll try it and see if I can reproduce the problem - if so I'm pretty sure I'll be able to track it down.

[stuarth]

Forgot to mention, but if you'd prefer to PGP or GPG that file for extra security then my public key is here:

 http://hickinbottom.demon.co.uk/wp-content/downloads/pubkey.asc

I don't think there's anything personal in the database, though.

[stuarth]

I have the database file now and will take a look at it against SlimServer? 6.3.1.

[stuarth]

I'm looking at your database and I think I can see the problem in that there's at least one album that keeps getting lazified over and over again (making that database column very large indeed - about 90MB for the lazified version of "BEST PUB JUKEBOX IN THE WORLD EVER DISC 2"!). This means the lazification performed when the database starts eventually eats all your memory and the process is killed, which is why once this problem occurs you can't start the server until you delete the database.

If you've got SlimServer? set to rescan for music library changes every night (and there's nothing wrong with that - I do too), then that will cause that column to get exponentially wider each night, which is why it seems to be fine for a while and eventually runs to a halt until you clear the database. I suspect you've also been seeing database performance get gradually slower as well.

That would explain why your database file became so large as well - much larger than I expected for that library size. I'll bet if you checked it now it would be much smaller than the 1.3GB it had grown to. That's why it also ZIP'd up very small as well because the same text was added to the title over and over again, and repeated things are good compressors.

I'll need to look at whether that's the only one (unlikely given the database file size), and why it's doing that, but hopefully I should be able to get to the bottom of it quite quickly tonight. I've a straightforward fix in mind but I want to try to understand how it happens in the first place.

If it's any consolation I don't believe this problem would affect v2 of the plugin for SlimServer? 6.5 beta as lazification is performed differently.

Thanks for your patience - I'm now intrigued why it happens here and nobody else has reported it.

[stuarth]

I think I've got this fixed in r134 (but needs testing). See the changelog for that revision for details.

Can you test this new release by downloading the beta of the new release at source:tags/1.2b1? In case that link didn't come out via email here it is in full:

 http://hickinbottom.demon.co.uk/lazysearch/browser/tags/1.2b1

Unfortunately you'll need to do a full database clear and rescan, but after that you should find Lazy Search works and the database file doesn't keep growing after each of your nightly rescans.

Thanks for reporting this and for helping to track it down. If you could just confirm this version is working (I don't run 6.3 so it's not too easy for me to give it a thorough going-over), I'll make a formal release and announce it on the list.

Ta.

[stuarth]

John has tried the source:tags/1.2b1 release and reports that it seems to be working. He'll monitor that for a week or so and if we don't see the same database growth as originally caused this problem then I think we can report it as closed and I'll release 1.2 formally (it will be the same as this release bar the name).

I'll also mention the database problem in the announcement in case Slim Devices are interested. For the record, I was trying this with SlimServer? 6.3.1, SQLite 3.2.1, DBD-SQLite 1.08.

[stuarth]

John has reported that the database has stayed a stable size for the last week or so and so I think we can say this resolves the problem. I'll push out a formal release in the next day or so (which will be the same as source:tags/1.2b1 aside from not being beta any longer).