mt-daapd crashes suddenly – disk spindown?

[velociped]

Just curious, but what command did you issue to attempt the removal?

The correct syntax is

ipkg remove mt-daapd

If that is the command you used, you may have to resort to manual removal. The installed files and their respective paths are listed on the package page for mt-daapd at the slug site – about halfway down the page.

Remember to backup your configuration file.

Should you need to resort to manual removal, you will likely need to force a subsequent installation.

Herman

[politby]

OK, I did a manual remove and then installed the April 14, version of the slug package. This install went fine.

But the crash still happens in exactly the same way. The funny thing is that it runs great for several hours, no re-buffering, no errors or anything.
I started the server at 18.53 yesterday and it ran until 01.31 this morning – that’s almost 6 hours – until it crashed. I’m now running it with -d9 and just a few usic files to see if this version produces any more useful error output. Will post the results.

I’m considering going back to the stable version; would re-flashing the slug, reinstalling unslung and then mt-daapd ensure I’m back to a fresh start?

regards,
P-O

[velociped]

…would re-flashing the slug, reinstalling unslung
and then mt-daapd ensure I’m back to a fresh start?

That would definitely get you back to square one. However, I am thinking that going to that extreme may be overkill and only provides a slightly better than average chance of restoring stability.

I say that, because this this thread has been active on the NSLU2-linux list for the past couple of days. It seems to suggest a generalized reliability problem involving the combination of an NSLU2 and Maxtor OneTouch drives.

Your posting history suggests that you only recently (04 April) began using mt-daapd to broadcast your DAAP share and have done so from the slug all along. The history also suggests that you have been experiencing some degree of difficulty with this set-up all along. I have to wonder whether it is somehow your hardware combination which is more at fault than the daemon versioning.

Another obeservation…Other than your post on 12 April (current thread) containing the debug level nine log extract, it would appear that most of your crashes occur during an automatic rescan of the database. Much as it may be a feature you are interested in preserving, you may want to consider turning the auto-rescan off for a while and see if the stability improves. It may be that the Maxtor drive is spinning down between scans and some aspect of the interaction between the three (the slug, the Maxtor drive and the daemon) is causing the daemon to crash.

Herman

[politby]

Herman, thanks for your comments, very helpful. I ran mt-daapd with a music directory of just 17 songs, and it ran successfully for 7 hours withour crashing, so may be some combination of the large number of songs (=long rescan times) and the Maxtor drive spinning down.

I’ve now turned off the autoscan and will let it run until tomorrow morning to see what happens.

I guess I don’t really need the auto scan, I don’t add songs that often so I can just do a rescan via the web interface.

/P-O

[rpedde]

Aha. *that* sounds like a memory leak.

My guess is that it’s slowly leaking memory on rescans — with frequent rescans on lots of files, it would cause more memory loss, until the slug runs out of memory and the OOM killer reaps it.

I haven’t run memory or fd leak checks on it yet, but I bet that’s it. I’ll valgrind out the obvious memory leaks this weekend.

— Ron

obtw – to go back to stable, just “ipkg remove mt-daapd”, “ipkg update”, and “ipkg install mt-daapd”. That should pull latest version from the stable feeds. (0.2.1.1-1, although I might backport that cover-art fd leak patch into a 0.2.1.1-2 if I get to it this weekend).

The last “stable” snapshot was the the march 5th snapshot. If you want transcoding, but want a more stable db backend, that’s the one to use. After march 5th, it’s sqlite only, and a huge refactoring of the whole program. If you aren’t using transcoding, there really isn’t a reason not to use the stable version in unslung, unless you just want to play with it. Just be aware that the stability isn’t there like it is in stable.

Hence the name, i guess. 🙂

[politby]

OK, here’s the result – my mt-daapd does NOT crash when running with auto rescans disabled.

So I guess the memory leak theory is sound. I’ll stay with this version now, without auto rescans, until the next stable one comes around.

Thanks everyone who helped!

/P-O

[rpedde]

Found the leak. It will be rolled into next nightlies.

another thing — in the config file is an option called “always_scan”. On a nslu2, that should probably be set to 0. That tells it not to scan if nobody is connected. That stops the device from hitting the drive, and lets it spin down. Otherwise, it scans every 10 minutes or whatever, and stops the drive from spinning down.

When a client connects, it will start background rescans again (since it has to go to disk to read from the database and stream the audio file, it might as well start up background scanning again).

— Ron

[Anonymous]

Sorry to revive old posts, but the description of the
“always scan” mentioned above is exactly what I have been trying to find out and it took me quiet a while of searching to find this post.

Can I please ask if there is this sort of thing documented somewhere else that I am missing?

[rpedde]

@anthony-td wrote:

Sorry to revive old posts, but the description of the
“always scan” mentioned above is exactly what I have been trying to find out and it took me quiet a while of searching to find this post.

Can I please ask if there is this sort of thing documented somewhere else that I am missing?

In the config file itself, it has info about what the settings mean. It should also be defaulted in the proper direction in the nslu2 build.

— Ron

[Author]

Posts