Yes, library corruption is a problem. However, as a user of MC, I'd hope that JRiver have designed their software in such a way as to be resilient to failures in the underlying OS. Transcationed db commits, etc, all come to mind.
I would hope that if MC tries to write to the db and something "underneath" fails, it will cope gracefully. Of course, there's always the case where something "underneath" fails but doesn't let the caller know about it.
Having said that, I remember a thread long, long ago, about people wanting concurrent db access, with multiple clients accessing the same library server and being able to update the library. I'm not sure if you're able to do this in current versions of MC, but back then JRiver said it was too hard (or costly, or something) to implement multiple user write access to the library. So, maybe the library hasn't been designed in an overly great way, in terms of robustness. (I'm
not having a go at JRiver or their software design practices here).
Anyway, was it verson 11 that the "new" database system came in? How big was that change? I seem to recall that the db became relational - e.g, multiple records could reference the same data. Did this bring in atomic, or transactioned commits?
I guess we're getting a bit OT. It would be nice to think, as a customer, that my library is safe. However, I know to back it up regularly. Users of free/open source software are used to the whole "no warranties" thing, and are usually fine with having to take responsibility for their data. I certainly don't guarantee that running MC under WINE won't destroy your library, but when it comes down to it, it's not the end of the world even if it does
Cheers