Hi everyone,
I have been using both Apple’s n-Serve app and Adobe’s flashplayer_32_sa_debug.exe on Windows to interface with my Unitiserve, however, they no longer work. n-Serve indicates the US is offline and nothing happens when I enter http://192.168.0.61/TV.swf in the Flash Player debug.
Anyone can help me with this ?
I assume the Unitiserve is actually up and running? (got to ask :-)).
Can you ping it from your PC? e.g. run up a command prompt and enter:
ping 192.168.0.61
I’m guessing that discovery (i.e. checking if anything is there to connect to) is done using UDP multicast/broadcast and the http will be over TCP. That both are failing implies that it isn’t being seen on the network.
Assuming the ping also fails, just try rebooting the Unitiserve. It’s network stack could have crashed. Rebooting would clear any issues.
Is the Unitiserve connected via Wifi or ethernet? If ethernet, check cables. If WiFi, maybe it’s not connecting to the network? You can check this by logging into your router from any browser in windows to see what devices have connected to the WiFi.
I used to have problems occasionally where N-Serve would fail to find my Unitiserve, and I never really got to the bottom of the problem. Restarting the Unitiserve usually resolved it.
The demise of Flash shouldn’t affect this, but it does prevent access to the web interface which was useful for some setup tasks. Fortunately there’s a simple workaround to get this working independently of any web browser:
Thank you both for your comments which I respond to, one by one.
I did a ping test and get the following never ending responses which I do not know how to interpret - the actual IP address is 192.168.2.11:
64 bytes from 192.168.2.11: icmp_seq=11 ttl=128 time=5.429 ms
64 bytes from 192.168.2.11: icmp_seq=12 ttl=128 time=5.377 ms
64 bytes from 192.168.2.11: icmp_seq=13 ttl=128 time=5.403 ms
I am not clear what Doyle means by “I’m guessing that discovery (i.e. checking if anything is there to connect to) is done using UDP multicast/broadcast and the http will be over TCP.”
The US is connected via ethernet. I checked the cable. The US shows as connected on the router browser. Also, I still can rip CDs onto my NAS which is the music store I use.
I turned off and restarted the US which did not solve the issue.
As for Adobe Flash, I did use the Adobe Flash Projector as mentioned by Steve Harris with Naim, but it stopped working at the same time that the US is showing offline on n-Serve.
Please let me have your further thoughts.
I read the original post a bit too fast :-). I had assumed that the http call was failing with an “address not found” or 404 error or something similar and hadn’t noticed that it was just that you were having a blank screen in the browser.
The ping responses, e.g. “64 bytes from 192.168.2.11: icmp_seq=11 ttl=128 time=5.429 ms” means that the server can be seen on the network from that PC. If it displayed something like “timed-out”, it would imply that it either is not on the network or that packets are not being sent to it or packets from it are being block coming back to you, etc. But that result looks fine.
Typically when you have an app which detects something new being on a network and where you don’t have to configure the streamer’s IP address in that app, (e.g. a Naim app “detecting” that there is a Naim streamer etc. that’s on the network), the app doesn’t at the start know what the address of that streamer is (unless it’s configurable in the app). To do this, apps can “discover” things on the network. This is typically done by sending either a message over UDP to address 255.255.255.255 (a broadcast address) or over UDP to a multicast address (I think they are in the range of 225.xxx.xxx.xxx and something above - I can’t remember off-hand). Anyway, devices that want to be “discovered”, listen in to any messages being sent to those addresses and if they receive a message and understand it, they reply. The app then knows that those devices are on the network and knows their IP address (i.e. the IP address that the response came from). When you then want to connect to that streamer, the app will know the IP address of the device that responded to the UDP message and connect to it, etc. That’s typically how these things work.
Back to your problem, I don’t know anything about the unitiserve to make any educated guesses as to what the issue may be from its end. Maybe the server software on the box isn’t running. I don’t know how you would tell.
Thanks Doyle. Strangely enough, I was fiddling around with the different apps and was able to reestablish the connection with n-Serve. I refreshed the IP address in the settings and I can now see the albums on I last ripped on n-Serve. Does that go ve you any hint as to what the issue is with the other apps not detecting the US?
I suspect that if n-serve is working, which you say it is, then other apps can’t see the Unitiserve because it will only respond to SMB1 , which is deprecated by pretty well everything now. You could try enabling SMB1 on whatever the apps are running on. I doubt there is anything wrong with the Unitiserve as n-serve works, except it’s very old now.
if (1) other app(s) work and (2) nothing has changed or have been upgraded on the server, then I’m going to guess that (as davidhendon) mentions, that the n-serve is okay. But I’m still curious as to why the other apps can’t see the server, unless they pass a version number as part of the handshake and the server is responding that it doesn’t support it. I had to ask google what SMB1 was :-). I’m not sure it would prevent an app from discovering another device on the network.
If I had this particular issue, what I’d do is (1) download an app called Wireshark and (2) check the traffic flow between your (faulty) apps and the server. That is all a bit vague and probably not very, very helpful and perhaps taking you down a rabbit hole :-). But I think that if some apps do work with the server, then the server IS running. Perhaps just clean/wipe any settings for the fault apps (including maybe uninstalling/re-installing).
If another device running an app speaks only SMB2 or SMB3 (the current norm), then the Unitiserve won’t respond to any attempt to discover it. It only speaks SMB1 and there is nothing Naim can do about it because Microsoft never patched Windows XP Embedded (which the US runs) to work with anything later than SMB1.
This SMB1 issue with Unitiserve/HDX etc is very well known and crops up here a couple of times a month.
It really can be seen as being similar to someone shouting to me “please wave at me” in English. I would know what to do. But if he shouted it in something I don’t understand like Finnish or Mandarin I probably wouldn’t do anything.
I asked google for more advice :-). If daviehendon is correct and the server uses SMBn for discovery and sharing files then I would go with his advice. Any apps that I’ve worked on which “discovered” devices on a network were Operating System agnostic and used standard udp/tcp messages for discovery, sending of data and not any particular protocol (e.g. SMB) which allows for discovery and sharing of files. I’ve learnt something :-). I had assumed that the US ran Linux rather than windows 
To be fair to Naim, if it was standard that apps would discover and communicate using SMBn, then that’s what they would use. Bit of a pain if/when apps move to a newer version of the protocol…
In a perfect world, apps would support multiple versions of protocols (or at least the previous 1 or 2 versions) with the exception of new commands.
David and Doyle, thanks for your input. The n-Serve that was working was the one on my iPad. On iMac, in n-Serve settings, I switched from auto connection to manual and entered the IP address as I noticed it did not detect automatically the IP address that had changed when I disconnected and reconnected the US (causing a change of IP). As for Adobe’s Flash debug, it is rather strange but the syntax I had been using was http//192.168.2.11/TV.swf. There was no " : " after http. I corrected it to htttp://192.168.2.11/TV.swf and it now works. I can’t understand how this happened and wonder if the syntax error was coincidental with the n-Serve not detecting the IP change. I any case, I want to thank you both for helping me solving this issue.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.