That’s exactly the issue.
WD uses SQLite for the database engine, but, in the case of NAS shares, the database itself is on a shared medium.
The SQLite developers strongly caution against such use in their documentation, because it depends heavily on proper implementation of network file locking; and there’s nothing the database engine itself can do to guarantee that locks will be correctly honored. The database must assume that the remote OS is honoring locks when it says it is. And if the remote OS isn’t doing it right, well, yes, the fault is with the remote OS, and the WD becomes the victim.
http://www.sqlite.org/lockingv3.html
“SQLite uses POSIX advisory locks to implement locking on Unix. On Windows it uses the LockFile(), LockFileEx(), and UnlockFile() system calls. SQLite assumes that these system calls all work as advertised. If that is not the case, then database corruption can result…Your best defense is to not use SQLite for files on a network filesystem.”
I can see why this happened; The “blame,” if any, is really arising as a result of “feature extension.”
WD has ALWAYS used SQLite for the Media Library, dating back even to the old WDTV Gen 1… but in those cases, the database resided on local USB disks, with no chance for network access, thus no risk of “concurrency” issues.
This worked perfectly well for all WDTV products through and including the Live Hub and Live SMP
Until…
along comes the new firmware back in November / December where the USB disks could then be accessed via the network by another device wanting to use the existing on-disk Media Library database, as well as the Media Library being created on NAS disks as well.
They just didn’t go back and re-evaluate the limitation which previously didn’t apply at all.
Years and years of no changes leads to an issue when the feature is extended beyond its original intent.
WD is most definitely aware of the issue, and I’m confident they’re working to address this one.
There are many possible fixes.
They could change from SQLite to MySQL or PostgreSQL which have better concurency checks.
They could ensure that the database is UNIQUELY owned (this is the one I favor.)… It doesn’t matter if it’s remote on a network device if only one device is trying to use the files… locking is unnecessary except INTERNAL locks, and SQLite doesn’t care if the file is REMOTE.
There’s one major downside to that, though.
It’s actually pretty cool that I can watch something on one Hub (or SMP). Stop the video, then shut off the box, then start up another Hub or SMP, and resume where I left off.
The resume data is stored in the media library database (except for DVDs.) The same is true with Ratings, etc.
If every WD device maintained its OWN database, then those settings would then be unique to each WD; not shared across the whole system.