WDTV live doesn't see any workgroup computers


I’ve browsed all forums and haven’t found any answer to basic issue.

My WDTV doesn’t see ANY computers in a local workgroup. If I want to view network share content, network share icon is greyed.

The interesting thing is WDTV sees exactly the same computers as media servers => no connectivity issue

Yes, all computers are in the same workgroup named WORKGROUP,

Yes, I’ve done mastre browser excercise - master browser in on eTrayz NAS as it always was

Yes - it doesn’t see yet another NAS in my network - Popcorn-hour A-110

Yes - it was working two years without ANY issue, it was discovering all computers (including NAS and Popcorn) within few seconds

It stopped working this month without any obvious reason. Nothing has changed in my network.

Popcorn can still see network shares on NAS,

Windows computers can still see netwrok shares on popcorn and on NAS,

“net view” command on windows shows wdtvlivehub in correct workgroup.

Any comment from WD on that?

Why it is not possible to add option to map network shares manually and don’t rely on discovery?

Is it so difficult to add one textbox in \ipaddress\sharename format?


P.S. Don’t tell me to edit browser settings - I have Linux based NASes - eTrays and Popcorn - with factory installed CIFS daemons. There’s no way to alter registry entries or whatever. Windows computers are used only occasionally.

And again - It WAS working two years without any problem.

workarroud: set static IP

(DHCP reservation doesn’t help)

Why would WD comment on it. By your own admission the player was working correctly for 2 years and you say that you have done nothing to your setup. What do you suppose WD have done to it?

I’ve just remembered - my son powered it up this month and has got ‘new update available’ - and he selected ‘yes’

WDTV had occasionaly difficulities to find the shares even before, but it always found them within few minutes.

This month it happened only once it found shares after one hour. Most of the time it doesn’t find them at all.

So… if not WDTV - do you suggest both NASes (from different vendors) went wrong at the same time?

This evening I will replace Zyxel by Cisco Catalyst, setup port monitoring and run wireshark.

I’ll come back with results. My suspicion is it doesn’t even start a discovery - we’ll see the evidence.

Downgrade is not the option because: “Very Important: Rolling back to version 1.05.04 or earlier may break your WDTV.”

network setup

Yeah, downgrading to 1.05 might be an issue, but I would assume you were running 1.06.34 before…

There you go. Something has changed at your end and you obviously thought it was insignificant to tell us. From a troubleshooting point of view I would say that its very likely that it has something to do with the update and given the detail of your post I am surprised that the firmware update was not mentioned or even considered to be the cause of your problem.
Have you tried resetting to factory defaults to see if that brings back your drives.

I’m sorry. If I had been updating it by myself I would had mentioned it.

Anyway - I’m running netbios packet capture at the moment. I see all local computers and both NASes are regularly broadcasting ‘netbios host announcements’ - approx every 10 minutes (including WDTVLIVE itself).

NAS is regularly briadcasting information it is a local master browser

WDTV is the only host which regularly queries for WORKGROUP<1d>. (It aparently doesn’t process announcements)

It always gets immediate response from e-Trayz NAS saying ‘I’m a local master browser for WORGROUP’.

No other netbios activity from WDTV…

Time to time hosts are querying for IP of some other specific host (by netbios name of the other host).

But WDTV never does it - it aparently doesn’t pick them up from broadcasts.

I keep running a capture - if you wanr me to focus on something specific, just let me know

you wouldn’t believe.

I was running on cisco catalyst whole afternoon, tuning capture filters and it wasn’t working.

Now I restarted capture and powercycled wdtv - and it works - sees all shares at the first attempt.

Nevermind - I at least have a baseline of how it should work.
 I can provide you a capture file if you are interested.

Just to summarize-

  1. on power-on wdtv broadcasts registration requests of its netbios name and netbios workgroup

  2. then broadcasts a name query for WORKGROUP

  3. gets reply from master browser

  4. SENDS SMB LANMAN QUERY directly to master browser

  5. receives list of all computers from master browser

  6. sends individual queries for each known host and scans their resources

Here we go - WDTV usually stucks in step 3 and never advances to step 4.

I will go on to confirm that

…it opens LANMAN tcp session regularly every 120 seconds and regularly downloads full list of netbios hosts from master browser - that’s probably the way how it (normally) keeps the list always up to date

It wasn’t doing that whole afternoon while under capture.

I’ll put it into a standby till the morning, we’ll see then.

lacyk wrote:
Downgrade is not the option because: “Very Important: Rolling back to version 1.05.04 or earlier may break your WDTV.”

It may break and that’s from 1.06.34 to 1.05.04. I had no problems going from 1.06.34 to 1.06.15 and then 1.02.21 (the last firmware where you could set 23.976 FPS manually).

ok guys,

I woke it up after few hours of standby, shares are not seen and here is wdtv’s netbios startup procedure:

0 sec - NB registration with 169.254 IP (broadcast to

 (apparently started NB activity before it got DHCP reply)

0 sec - name query to WORKGROUP<1d> (still the same IPs) - no reply (of course)

1,5 sec - second registration attempt (from 169.254. IP, broadcasts to

1,5 sec - second WORKGROUP<1d> query (from 169.254. IP, broadcasts to

3,5 sec - name query to WORKGROUP<1d> (from proper IP, but still broadcasts to

4,5 sec - name query to WORKGROUP<1d> (from proper IP, but still broadcasts to

25,4819 sec - name query to WORKGROUP<1d> (from proper IP, but still broadcasts to

25,4833 sec - third registration sent (from proper IP to proper broadcast)

27,5 sec - fourth registration sent (from proper IP to proper broadcast)

29,5 sec - fifth registration sent (from proper IP to proper broadcast)

silence (I waited 5 minutes)

note the point - it never sends out WORKGROUP<1d> query (finding master browser) after it knows proper broadcast IP

Now I see it is a lotery - when WDTV modifies its broadcast IP

whether it is before 25,4819 sec (then it works), or right after (then it doesn’t work)

How about changing netbios timers in a firmware?

If the activity which started at 25,4819 had started few seconds later, it would have been working without problem.

Or - if it was possible to enter shares manually (using hostname or even IP address), there wouldn’t be any issue at all.

Good troubleshooting.   Does it get hamstrung if you’re using a Static IP?

I’m not very keen on that - time to time I move it to parents’ network.

But I’ll give it a try.

Alternatively set each router to assign the very same IP address to the LIVE based on its MAC.

Yeah, but that still requires DHCP on the Live…

What I’m curious about is if the WD has a “race” going on in which DHCP has to complete first before browser discovery will work correctly.

If a static IP is set, that removes DHCP from the picture entirely.

If the problem remains in that case, then it’s not a race condition – it’s a different kind of bug.

Right, with static IP it works just perfect.

Here is a netbios startup sequence:

0 s registration attempt - from correct IP to correct broadcast

0,03 s WORKGROUP<1d> query (correct broadcast)

0,03 s response from master browser

2,03 s second registration attempt to correct broadcast (not sure why)

2,07 s name query to master browser for empty string (not sure what it is, but seems to be part of protocol)

2,07 s response from master browser

2,7 s third registration attempt (broadcast)

3,5 s name query for WORKGROUP<1d> (broadcast)

3,5 s response from master browser

3,5 s open TCP LANMAN session to master browser and downloads list of workgroup computers

that’s it

(wireshark capture file is available)

So static IP works well.

I wouldn’t say this is a “solution”, let’s call it a "workarround"

What next?

I had the same problem, I have done  a rollback on firmware 1.06.15_V and everything works fine. I my opinion it’s a bug in the new firmware.