Tag Archives: router

Fujiflim PC Autosave Gives “CAN NOT FIND DESTINATION PC”

software, , , , , , , ,

This is an esoteric and probably rare cause, and is being posting simply for technical interest. I will assume that the reader is familiar with Ipv4 networking in this article. For more common causes of this error message, try fujix-forum.com.

Here is the camera I got from eBay. I love it. Waterproof, 16 MP pictures, HD video, slow-motion video, geotagging, wi-fi, charges from USB, face-finding, auto macro down to a couple inches, and other modes. And it’s purple.

Fujifilm offers software to wirelessly transfer pictures from the camera to a computer. Seemed like a wonderful idea to me, since getting to either the USB jack or the SD memory card on this waterproof camera involved opening the watertight seal – something I wouldn’t want to wear out.

Setting up the software was squirrely on my Netbook. The installer detected that I didn’t have .NET 4.0, so installed that for me before the Autosave software. Then, I was able to connect and register the camera, but the connection was dropped before I could complete the process on the PC. It absolutely refused to connect multiple times after that. Whether by “simple” or “manual” setup, I would have no trouble connecting to the access point, but then get this “CAN NOT FIND THE DESTINATION PC” message.

Finally, for no apparent reason, it worked. And once it worked, it kept working. I then moved on to a Desktop PC that was hard-wired into the router. I tried 10 times, and never got past the error message above.

There was a firmware update available for the camera, which supposedly helped with wi-fi issues. I upgraded from 1.00 to 1.02 firmware. No change.

Online advice suggested that it might be a firewall or router issue. The Windows Firewall had the proper exceptions entered for the Autosave software, but even so, the Firewall was OFF. I looked at the router. Client isolation was at the default setting – OFF. Besides, the Desktops had no trouble communicating with wireless devices over the years.

Oh, the Desktop was Windows 10, while the Netbook was Windows 7. I doubted that could be it, as the software claimed support under Windows 10. But I went to another Desktop that had Windows 7, and tried that. Same symptom, can’t find destination PC.

I did notice, upon installing the software to the Windows 7 Desktop, that there was no complaint about .NET needing to be installed. A review of the installed Microsoft modlues showed that .NET 4.8 was already installed. Probably not a problem, as that would have generated an uproar if it happened. Just for kicks, I uninstalled .NET 4.8, and let the Fuji installer install its own .NET 4.0. The problem persisted.

Yet another difference was that the Netbook connected via Wi-Fi, whlie the PC was hard wired. I saw no reason why that should make a difference, but tried disabling the hardwired adapter, and plugging a USB wi-fi adapter into the PC. Surprisingly, it connected!

The Desktop had been set up as a static IP address, but when the USB wi-fi adapter was inserted, that configured itself as DHCP. Surely, there couldn’t be a problem with static addresses communicating with DHCP ones? Both addresses were 192.168.2.* . The router was set to assign DHCP addresses in the range of .10 to .99, and the Desktop was .106 . I tried adding a DHCP reservation on the router for .106, and expanded the DHCP range to be from .10 to .106 . No difference.

Below are the network adapter configurations for the Netbook and Desktop, respectively.

Here is the configuration of the Netbook that worked.
This is the configuration of the Desktop PC that did not work. No problem here. Or is there?

The only difference that I could see was that the Desktop was not actually using DHCP. Doubting it would make any difference, I set the Desktop to get its address through DHCP. It did, and the address was still .106 as before. But it worked!

Looking closer, the subnet masks were different between the camera and the Desktop when it had a static IP. I didn’t think this would make a difference, since both addresses had the first 3 octets matching. 255.255.255.0 should have been a sufficient mask, and if anything, 255.255.248.0 was more permissive. To verify, I changed the Desktop back to static IP, with a 255.255.248.0 subnet mask. It worked.

My speculation is that either it was an idiosyncracy of the Fujifilm software, or that the switch on my Asus RT-N16 router didn’t work the way I thought. Whether it was a bug or my lack of understanding, I have no idea. I could change routers to see if another brand behaves the same way, but have better things to do than pursue root cause at the moment.

Other Observations and Thoughts

When registering the camera to a PC, the following screen will come up. Whether you select Manual or Simple, the only difference is the instructions that will appear on the screen. For example, you could select Simple, then decide to use the Manual method on the camera, or vice-versa. But you must choose one of them, or it won’t work.

Manual or Simple Setting, must choose one.

The transfer is noticeably slower when the destination is wireless. In a quick experiment, a picture and movie took 43 seconds to transfer to the Netbook that was on the same wi-fi network, while transfer to the Desktop that was hard-wired to the switch took only 16 seconds.

Why was the laptop so difficult to set up, even the first time? Hard to say. It could have been because of the 1.00 firmware version on the camera. In any case, once it was set up, it was reliable, although slow, as previously noted.

Why was my netmask set to 255.255.248.0 in the first place? Why am I using static IP’s? Long story. Suffice it to say that it was once needed.