[b_adl_y]

Hi, so I have ATV2 iOS 5.3 with XBMC Gotham Returns 13.1 Final freshly installed (7/3/14). I had previously been running Gotham 13.0 but thought a fresh install might help with HD playback (it didn't but changing the connection to Ethernet instead of WiFi did). After the fresh install I added sources for video using SMB through the Videos -> Files -> Add Videos -> Browse -> SMB -> and then selected the shares I have running on my Win 7 PC. (Previously setup following SMB/Windows Guide). **Note: All my video files have been scraped using Ember to facilitate sharing with XBMC.** This setup was previously working on Frodo and also on Gotham.

Last night (7/3/14) my folks tried to watch their show and had no problems. Tonight (7/4/14) they tried to watch their show and it didn't work. Giving them the "This file is no longer available.."

So I ran down a checklist of what it could be: PC powered on? Yes. PC ping ATV2? Yes. File in shared folder on PC? Yes. File play on PC? Yes. Can see shared folder from ATV2 XBMC video library? No. I got a "Could not connect to network server" message. I checked and the ATV2 is connected to the network and able to play video (Apple network test, and play trailer from ATV2 itunes store). Also I found through the add sources that I can see the Win 7 PC (and a couple other PCs on the network).

I tried searching the forums, but couldn't find anything pertaining to my situation exactly, other than the note that "SMB/CIFS UNC paths no longer work". But I don't think that applies to me exactly as the shares in XBMC sources were in the smb://server/path/to/share/ format.

It's frustrating, because I can't think of anything I changed today versus yesterday to change back.

Here is my Debug log.

**Note: I was connected via WiFi (had to move ATV2 to different TV to troubleshoot so folks could watch their show via my directly connected Macbook) while performing the Debug log, but the situation was the same as when I was connected via Ethernet.**

Hope someone can help! My folks love their binge TV!

[Ned Scott]

Sometimes those netbios names for SMB are temperamental. I don't really know all the details myself, but one of the computers on your network is a WINS (Windows Internetworking Name Server). This is what translates the name of an SMB share to an IP address. Sometimes this gets messed up, or more than one computer attempts to be the WINS and that messes it up, and then there's nothing to say what IP address that SMB name points to.

The OpenELEC wiki talks about this a little bit (even though in this case we're not using OE):

An election fight is a peer-to-peer negotiation over who gets elected to be in charge of the domain(s) and/or local master browser list which is the list of computer names that will appear in the Windows Network Neighbourhood (or it's current equivalent). The machine that wins the election is determined through a combination of uptime, OS version and config settings.

Rebooting various computers on your network will cause them to have this "election" again, and often that's all that is needed to get a working WINS up again.

You can also try to migrate your library to use an IP address instead of a netbios name, which can often be more reliable due to this crazy way WINS stuff works.

[gagnehj]

Hi b_adl_y,

If you move your aTV2 over to WiFi, do you experience the SMB connectivity issue - i.e. is the problem localized to Ethernet?

Are you able to reach your Win7 workstation from other workstation(s) and view the contents of your share(s)?

You could try flushing the WINS and DNS resolver caches on your workstation; launch an elevated command (CMD.EXE) and enter the following commands:

Code:

nbtstat -R
nbtstat -RR
ipconfig /flushdns
ipconfig /registerdns

The nbtstat commands are case sensitive. If you want descriptions of what the command switches do, enter the following at a command prompt: nbtstat /? and/or ipconfig /?.

Cheers,

---

You can also try to migrate your library to use an IP address instead of a netbios name, which can often be more reliable due to this crazy way WINS stuff works.

I've used (and implemented) WINS in numerous infrastructure scenarios as many technologies still require WINS. Often times, problems with WINS indicate improperly configured WINS servers (Windows Server, etc.) or WINS services (routers, NAS /w DHCP, etc.). I've also seen cases where the DHCP server was providing incorrect DHCP Options to workstations causing all sorts of "fun" IT challenges.

Assuming a router-based configuration, it's possible that the router settings for DHCP are improperly set for the environment and it's now becoming an issue. It is additionally possible that the WINS/DHCP/DNS service implementation in the router isn't adhering to the standards - usually resolved via a firmware update. I mention all three as often times, they are interdependent.

Cheers,

[b_adl_y]

Rebooting various computers on your network will cause them to have this "election" again, and often that's all that is needed to get a working WINS up again.

::Facepalm:: I don't know why I didn't try this last night. Must have been tired. 3 Windows machines on the network: 1 Win7 Desktop (where the video file shares are located), 1 Win7 Laptop, and 1 Vista Desktop. Last night I shutdown the Win 7 laptop, but didn't think to shutdown the Vista Desktop. Read your post this morning and shutdown the Vista Desktop and SUCCESS! Thank you Mr. Ned Scott!

You can also try to migrate your library to use an IP address instead of a netbios name, which can often be more reliable due to this crazy way WINS stuff works.

I suppose that I will have to set this up. I was too lazy to do this sooner.

If you move your aTV2 over to WiFi, do you experience the SMB connectivity issue - i.e. is the problem localized to Ethernet?

Yes I had the same issue on both WiFi and Ethernet.

Are you able to reach your Win7 workstation from other workstation(s) and view the contents of your share(s)?

Yes I was able to reach my shares from my Macbook and also copy files from them.

You could try flushing the WINS and DNS resolver caches on your workstation; launch an elevated command (CMD.EXE) and enter the following commands:

Code:

nbtstat -R
nbtstat -RR
ipconfig /flushdns
ipconfig /registerdns

The nbtstat commands are case sensitive. If you want descriptions of what the command switches do, enter the following at a command prompt: nbtstat /? and/or ipconfig /?.

I don't think that is necessary right now, but definitely some commands I would like to learn. Thank you!

---

You can also try to migrate your library to use an IP address instead of a netbios name, which can often be more reliable due to this crazy way WINS stuff works.

I've used (and implemented) WINS in numerous infrastructure scenarios as many technologies still require WINS. Often times, problems with WINS indicate improperly configured WINS servers (Windows Server, etc.) or WINS services (routers, NAS /w DHCP, etc.). I've also seen cases where the DHCP server was providing incorrect DHCP Options to workstations causing all sorts of "fun" IT challenges.

Assuming a router-based configuration, it's possible that the router settings for DHCP are improperly set for the environment and it's now becoming an issue. It is additionally possible that the WINS/DHCP/DNS service implementation in the router isn't adhering to the standards - usually resolved via a firmware update. I mention all three as often times, they are interdependent.

Cheers,

Well I will need to look into this WINS business. I had seen the SMB WINS server but it was all set to 0.0.0.0 like the picture in Settings/Services - XBMC page and even though I had heard the term WINS before, I couldn't immediately find any info on how it should be set in XBMC. I also couldn't think of how it might be affecting my issue with connectivity.

** Could I change the WINS server to the IP of the Win7 PC hosting the shares and that solve the WINS issue? I might give that a try.

Thank you both gentlemen. I have the problem fixed for now and a general idea of how I can prevent this from happening again, in addition to a few more troubleshooting steps to take should it occur.

How can I Thank You, or Up both of your reputation? Also can I amend the forum title to say "-SOLVED!"?

[gagnehj]

Glad you got it working!

FYI, the commands I posted should save you from having to restart your workstation since it effectively does the same thing.

Check the WINS information on your workstation (ipconfig /all) via an elevated Command Prompt; that should tell you if and where WINS IP(s) are obtained. If it's from a router, verify the DHCP settings for the type of NetBIOS broadcast ... you'll likely need to review the router documentation and possibly the vendor forums (if any) of the router to see if others have encountered anomalies.

Cheers,


* EDIT *

I believe you can do a Full Edit on the first post of the thread (since you're the owner) and change the subject.

[Cranial]

It has been a while since I've played with Windows, but isn't it possible to manually set a WINS server in your network config to avoid this problem.

i.e. point your WINS server address to the computer most likely to be on in your network. Should stop different machines trying to grab naming rights.....