Playback of .VOB files over network share

While I understand the release notes of 2.05.08 somewhat states this problem, but does not define exactly how and when or what really happens…

I was not affected by this nasty bug till I setup a HOMENAS over the weekend and I found out that this bug (At least for me) is really really nasty…

Here is how the bug manifests itself… and the symptoms following the bug…

All is fine, WDTVLIVEHUB sees the .VOB files on the network just fine, It even plays .VOB files just fine for the first time or may be the second time if you get lucky… then the bug comes and this is really nasty…

Following the second .VOB file playback, When you attempt to play any other file types like .MKV, .AVI or even .JPG picture file or any online service like Blockbuster, You Tube anything to do with video playback or JPG display like Flickr etc;. Or music playback from HDD based or online services will not play anymore!!!

All you will see is a spinning waiting for the video playback or music playback or photo playback to start… 

I started my own investigation trying to isolate what causes this, but I could not pin point what is the real trigger, the only thing I can say is .VOB files playback over network share is the root cause of the problem which almost renders the functionality of the WDTVLIVE hub to play any other media types *EXCEPT ISO DVD*

You read correct, when this bug is present, ISO DVD media plays just fine! This is the only media file that plays when the bug is present… that is a really ODD and strange.

Before someone suggests the paper clip method to reset my WDTVLIVEHUB let me say, I have been a WDTV user since the WDTV first generation and I know the quick remedies one can think of and trust me when I say I have tried EVERYTHING…

I even rolled back to older release of firmware but the playback of .VOB files over network share is present in the older releases too… Just that WD realized the bug and put it in the release notes…

Now, Can someone tell me is this the correct BUG report of unable to play .VOB files over network share or I am experiencing something different?

I tried public access on the NAS device, I tried to make it read-write, tinkered with the samba configuration file on the NAS device to see if anything external is causing this problem but could not find a root cause.

Oh! I somehow feel that it’s got to do with the “RESUME Database” that WD maintains for certain files types and as ISO file do not have RESUME database when Media Library is turned off.

When this bug happens, it looks that WDTVLIVEHUB is waiting indefinitely for something and never able to start the video or Music playback as that routine prevents the playback to start, Looks like something in the RESUME database area to me.

Oh! You can always reboot the WDTVLIVEHUB by pulling the plug and all starts to work fine till you play another .VOB file from the network share and the whole thing repeats itself like clockwork!

Any ideas anyone? Or if WD engineers are reading this, Can you please comment when you expect to get this bug resolved in the next FW release?

What model NAS device are you using? What’s the current firmware rev on it?

Hello Guy_K,

The NAS is Seagate BlackArmor 440 NAS the NAS is running the latest factory firmware release  File Version:  4000.1211 

The current Firmware on the WDTVLIVEHUB is  2.04.13 , I had issues with the latest firmware  2.05.08 wherein the Menu Colors had incorrect Gamma so I rolled back to 2.04.13.

Hope this helps

Thanks

Cheers!

Thanks. We’re currently investigating some compatibilty problems with that NAS and a few other NAS products. 

Hello! Guy_K,

Thanks for confirming the issue, I hope your engineers will find a fix for this soon, BlackArmor NAS is a pretty huge investment on my part to keep all the media files in one place, I really would like to use the NAS for various other types of media files other than DVD ISO files which is the only media that works without any hiccup.

Oh! By the way, I would like to give you and your engineers feedback that initially I thought that playback of .VOB files from the NAS device trigged the endless loop condition which rendered the device useless for any other media files other than DVD ISO files, I was just browsing files using File Manager and looking at some family photos and one by one it would work from the NAS, But after about 5 -8 mins of browsing JPG files, The unit exhibited the same endless spinning loop condition wherein every playback of media would stop other than ISO DVD files!

So, my theory of the problem in the unit’s RESUME database could be wrong, It may be more in the lines of compatibility with the NAS itself… 

Please let me know if you need additional information for your engineers to troubleshoot this issue further and hopefully find a fix for this soon.

Thanks!

I did some more testing with Seagate BlackArmor NAS 440 In the hopes that I can keep this NAS to work well with WDTVLIVEHUB or to return it as it was a major investment on my part to keep all the media files in one place.

 I noticed that the condition was repeatable as it used to hang in specified intervals (5-6 minutes) no matter what file I am trying to view or attempt playback from the Seagate BlackArmor NAS

After fair amount of troubleshooting (About 3 days), I am fairly certain now that the main culprit was the “lld2d Daemon” that runs on BlackArmor NAS 440 on its two gigabit network ports.

Looks that WDTVLIVE HUB does not play well with devices that explicitly runs  Link Layer Discovery Protocol

As long as no devices broadcasts LLDP on the network subnet WDTVLIVEHUB resides, the WDTVLIVEHUB plays all the media files from the NAS device, As soon as the “lld2d” process is started on Seagate BlackArmor NAS 440, The WDTVLIVEHUB acts crazy and will stop playing.

Now, I am no network expert by any means, All I know is if you want WDTVLIVEHUB to co-exist with Seagate BlackArmor 440 NAS Device, You will have to HACK the Seagate NAS device to stop this Daemon from starting up in its /etc/init.d scripts (You need to have SSH access on the Seagate NAS device to complete this process)

Please do not ask me how to get SSH access on Seagate BlackArmor NAS; I cannot help you in this… Search Google for answers.

You will find an init script known as “S9lltd” you will need to prevent this script from starting by renaming it to “_SK9lltd”

This is just a workaround, the actual problem still remains and WD needs to fix this sooner or later. May be this will give WD engineers some ideas…

Thanks

With best regards

1 Like

Just a minor tweak to that:

lltd is LINK LAYER TOPOLOGY DISCOVERY.

lldp is LINK LAYER DISCOVERY PROTOCOL.

lldp is an open standard.

lltd is Microsoft specific.

The two are related by “function” only.   I’m not sure if the two protocols are actually “conversationally” compatible.

So which protoocol is it actually running?  Is Seagate using the name “lltd” to actually run “lldp?”

If it actually *is* lltd that’s bugging the WDTV Live Hub, then I’d think lots of people would be having problems, because Windows 7 runs lltd by default.

Tony,

As far as I can tell, Seagate NAS runs some sort of Debian LINUX with  Modified Kernel to work with Marvell Boards that it houses…

You are correct, Looks that they may be actually running the open source LLDP as the Daemon binary  filename seems to be lld2d but they call it  lltd in their scripts…

:wink:

You’re the net guy, Tony, not me, but if the Seagate will do CIFS as well as NFS, wouldn’t it need to be running Microsoft’s lltd?

As far as I can tell, the lld2d daemon is a responder for lltd.

I would also question the conclusion that the WDTV is the source of the problem.

Disabling LLDP on the NAS would more point to a problem on the NAS end. Someone of course would have to look through the source code for the WDTV to see if the WDTV is running the LLDP daemons (requester or responder).

Well, regardless of whether the problem is at WD’s end or at the NAS, if the NAS is unusable with that daemon running, and works fine with the script that launches it disabled, then that seems like a viable work-around for now, until the problem can be located and fixed. :wink:

That is fair and fully agree with you :wink:

We do not have the source code or SSH access to WDTVLIVE HUB… Only WD engineers can figure out what is causing the problem.

We can only point them in the right direction :wink: It is completely up-to them to decide who is not playing well in the LLDP world… and battle it out :smiley:

As far as I am concerned my Seagate 440 NAS works like a champ now and I am planning on keepin it, I can finally get rid of my  aging 3 year old home brew FreeNAS for good.

One bug down… 1000’s more to go… :smileyvery-happy:

Actually someone could probably figure it out from the the most recent post of the open source code for the WDTV, here http://support.wdc.com/product/download.asp?groupid=1003&sid=120&lang=en

But your postings do point to a possible cause for people who are are experiencing media streaming  interruptions on a regular 5-10min basis.

Glad you solved the problem.

As far as I know, the only reason MSFT uses LLTD is to draw the silly network map.   Only Windows Vista and Windows 7 have it by default;   you can download the responder for XP from MSFT’s website.

It’s definately not a requirement to run CIFS/SAMBA…