WARNING: If you have two or more HUBS or Live-SMP's

… running 3.00.28 and 1.04.12, and you’re using NASes, there is a SEVERE Content Aggregation Bug…

If you are…

  • Using NAS Boxes
  • Using two or more Live Hubs *or* Live SMPs (or any combination) with access to the same “FIRST SHARE.”

… your media library database *WILL* be corrupted and it will NOT FUNCTION correctly.

By FIRST SHARE, I mean the first share listed is the same for both boxes.   And this ONLY need to be the FIRST SHARE.  If all the others are different, it is STILL BROKEN.   But if the FIRST SHARE is different for both of them, then there will be no problem.

The reason is because the boxes try to store their data in the .wd_tv folder of the FIRST SHARE that it has access to via your Media Library.

I do not know what the effect is if you select SPECIFIC SHARES in the Content Library Management section.

Here is the issue report with details:


1 Like

YIKES!  :neutral_face:

I am glad I do not use Media library function! 

Thanks for sharing!

I am usuing a hub with 2 live plusses with super old firmware havent upgraded them in over a year and I do have a Stora Nas am I affected? The only problem I have as I stated in the firmware update post is that when I do media library as long as I am entering the video section while it is c ompiling and ask me to wait if I say yes then it goes to the media library just fine once I exit to the home page and then back to videos then it imeadiatly goes to the folder view.

It also seems to in the folder view after awhile it will say no media in folder I then have to pull up select source and pick my Stora from the network shares window to get it to read again

Kind of a bummer cause this firmware works almost perfect it loads fast thumbs pop up fast even in folder mode I have moviw metadata so I would not be opposed to keeping in folder mode just have to figure out why it losses the media after it sits any suggestions anyone? Either on getting the media library to hold it’s state or to keep from the folder view from losing it’s media

I have 2 live hubs but I haven’t tried to use the second one yet. So where is this FIRST SHARE. Is this something on the hub or something on the computer. Sorry for my ignorance.

On the computer.

This answers a couple mysteries involving mine and my room mate’s Hubs talking back to our NAS.

I just chalked it up to more shoddiness. Turns out I was correct, just mistaken regarding the nature of the problem. lol

I am thinking WD should change development outsourcing firms. Maybe upgrade to the $3.75/man hr. Bangalore Code Factory.

Correction:  After seeing the grammar in some of the error messages, I am changing my guess from India to China, regarding where these updates are being coded. Lemme guess, they code it, ship it to WD, who tests it, puts a couple people on bug fixing, and whatever can be fixed in the gap gets fixed. The rest, maybe next time… Am I right?

I guess I’m not familiar with an NAS so I’m probably not using one. I only copy videos from my computer over to the hub and use it to play them. I also sometimes hook a usb drive to it. If I hook the second hub to my computer to use it the same way, would I be affected by this. I doubt that I would ever connect both hubs at the same time.

Hi Tony,

Do you know if this has been changed/fixed with the latest FW 3.03.13 or is it still broken? I don’t see it in the “fixed/solved” notes in the release notes but you never can tell with WD releases - sometimes things become broken without being documented and maybe something could be solved by accident and also not documented. Yeah, I know - I’m a fanciful dreamer living in fantasyland.

This issue is something that is stopping my purchase of a second WD device for the bedroom. I did move everything off the hub’s internal drive onto NAS so that if/when this finally works correctly I can have 2 devices pointing to the same repositories without collision.


“Not Richard”

No, nothing has changed.

Just to clarify if the Hub scans the shares and compiles it’s Media Library, then if the SMP scans the same directories, the SMP Media Library won’t finish compiling, even if the Hub is switched off and is not accessing the same shares?

Tony on your post on the Live Streaming issues forum, a user Toddler made a comment about creating separate empty shares and a “junction point” Does this work and how would you create a “Junction point” I’m looking at buying an SMP in addition to my Hub. I was planning to have both devices use the same shares.

I do not know.  I’ve never tried it.

As far as I can tell, as long as there is never more than ONE box powered up, there’s no issue.

But if there are TWO powered up (even in standby), it’s at risk.

TonyPh12345 wrote:


I do not know.  I’ve never tried it.


As far as I can tell, as long as there is never more than ONE box powered up, there’s no issue.


But if there are TWO powered up (even in standby), it’s at risk.


Thanks for the reply Tony. So this looks like a file locking problem? The Media Library should only let one device have access at a time and lock out the second device?

If I point the SMP at my files on the NAS, the SMP Media Library will ignore any files on the Hub. If I use network sync to copy files to the Hub, the Hubs Media Library will only use the local files. So the Hub and SMP will have separate Media Libraries and there shouldn’t be any conflict. Pretty low tech but would this work?

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.


“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


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.

Thanks for the explanation Tony. It seems that WD dropped the ball pretty badly on this one. I hope when / if they change the Media Library to allow multiple access, they keep the improvements that they introduced in the version 3 FW and maybe even improve it.