…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