Using the MyURemote Network Scanner

1. What the Network Scanner is for

The MyURemote Network Scanner is designed as a general local network inspection tool. It helps determine which hosts are active on the LAN and can optionally enrich those hosts with protocol-specific information.

In practice, the scanner is useful when you want to answer questions such as:

• is the device still visible on the local network?
• does it still have the expected IP address?
• does a Global Caché unit still appear where it should?
• does the device respond to a direct ping test?
• does the device expose DLNA / UPnP information?

This is especially helpful during installation, support, troubleshooting, or when a previously working integration appears to stop responding.

2. Core principle

The scanner is built around a clear separation of responsibilities:

• Scan = detect hosts on the subnet
• Ping = test one specific host for support/debugging
• DLNA / GC = enrichment, not the base scan itself

This distinction is important. A device may be perfectly visible on the network even if it does not support DLNA, and a device may support a certain protocol while still requiring a separate support check.

In other words: host visibility comes first; protocol-specific identification comes afterwards.

3. How it works

The Network Scanner runs through the local MyURemote server on localhost:9090. The frontend in the WebView calls local endpoints, and the native side performs the actual scan.

The high-level flow is:

1. The Network Scanner page is opened.
2. The frontend starts the scan.
3. The native backend begins scanning the local subnet.
4. The frontend polls the current results repeatedly.
5. Hosts appear progressively in the list.
6. Extra protocol-based information is added later where available.

Frontend (WebView) → localhost:9090 → NetworkScannerHandler → NetworkScannerManager

4. Local endpoints used by the scanner

The scanner communicates through a small set of local endpoints:

4.1 Start scan

/networkscanner?mode=start

Starts the scan and returns basic scan metadata such as subnet and IP range.

4.2 Poll scan results

/networkscanner?mode=results

Returns the current state of the scan, including the list of hosts found so far.

4.3 Ping one host

/networkscanner?mode=ping&ip=192.168.0.125

Performs a direct reachability / latency test on one selected host.

4.4 DLNA info for one host

/networkscanner?mode=dlnainfo&ip=192.168.0.125

Attempts a DLNA / SSDP lookup for a single host and returns model-related information if available.

5. What the scanner shows

Each host typically appears with a subset of the following data:

• IP address
• hostname
• latency
• MAC address (if available)
• DLNA status and device information
• Global Caché identification, where detected

Example host object:

{
  "ip": "192.168.0.125",
  "hostname": "192.168.0.125",
  "latency": 6,
  "mac": "",
  "hasDlna": true,
  "friendlyName": "Yamaha Receiver",
  "manufacturer": "Yamaha Corporation",
  "modelName": "RX-A1080",
  "modelNumber": "A1080"
}

Not all fields are always present. Basic host data usually appears first, while DLNA or Global Caché details may appear later.

6. Global Caché detection

The scanner can also recognise Global Caché devices. This is especially useful in MyURemote environments because those devices are frequently used as network controllers.

Global Caché detection is not based on DLNA. It uses a separate multicast discovery mechanism.

In practice, this means the scanner can:

• identify that a host is a Global Caché unit
• preserve that identification while the rest of the scan continues
• show extra information such as model/type where available

Typical examples include:

• GC-100
• iTach IP2IR
• iTach IP2SL
• other Global Caché variants

This is particularly helpful when a system no longer responds as expected and you first need to verify whether the correct Global Caché still exists on the expected IP address.

7. DLNA / UPnP enrichment

The scanner can optionally enrich hosts with DLNA / UPnP information. This is useful for receivers, amplifiers, media renderers and similar devices.

Typical DLNA fields include:

• friendlyName
• manufacturer
• modelName
• modelNumber
• deviceType
• udn

However, DLNA is best understood as enrichment, not as the basis of the scan. A host may be active and useful even if it exposes no DLNA information at all.

Also note that DLNA responses may appear later than the basic host entry, because multicast responses can arrive asynchronously and some devices answer more slowly than others.

8. Typical workflow in the app

1. Open the Network Scanner page from the Tools menu.
2. Start a scan.
3. Wait for hosts to appear progressively.
4. Use the PING action if you want to validate direct reachability.
5. Use the DLNA action when you want protocol-specific details for one host.

This makes the scanner useful both as:

• a quick local network overview
• a support/debug tool for problematic devices

9. Practical use cases

9.1 Verifying whether a device still exists on the network

If a previously working device stops responding, the first question is often whether the host is still visible at all. The scanner gives a quick answer.

9.2 Confirming the IP address of a Global Caché unit

A Global Caché controller may still exist but no longer be reachable under the expected IP address. The scanner helps confirm whether the correct unit is still present.

9.3 Checking whether a receiver exposes DLNA information

Some amplifiers and receivers can be identified through DLNA, making it easier to confirm brand, model and role.

9.4 Support and debugging

The separate ping action gives a direct, host-level test. This can help distinguish network reachability problems from protocol-specific issues.

10. Performance principles

The scanner is designed to show useful information quickly.

• the first hosts should appear fast
• the UI should not block while scanning continues
• protocol enrichment should not prevent basic host visibility
• slow devices should not make the scanner feel unusable

In practice, this means that scan logic and enrichment logic should remain clearly separated.

11. Important limitations

• not every host responds reliably to every reachability method
• not every host supports DLNA
• not every host exposes a meaningful hostname
• multicast-based discovery depends on the local network and platform behaviour
• different platforms may behave differently for the same device

In particular:

• Android uses host detection based mainly on InetAddress.isReachable(...)
• iOS does not offer an identical equivalent and may rely more on hybrid detection techniques
• Android multicast discovery requires a MulticastLock

This means the Network Scanner is best understood as a practical support tool, not as a perfect network inventory engine.

12. Quick debugging guide

When a device does not behave as expected, this is a useful order of checks:

1. Does the IP address appear in the scan?
2. Does the host respond to a direct ping test?
3. Does manual DLNA info retrieval return anything?
4. Does Global Caché discovery identify the host correctly?

This helps separate:

• network visibility problems
• reachability problems
• protocol support problems
• device identification problems

13. Summary

• The MyURemote Network Scanner is a local support and diagnostic tool.
• It detects hosts on the subnet and displays them progressively.
• It offers a separate PING action for support/debugging.
• It can enrich hosts with DLNA / UPnP information where available.
• It can identify Global Caché devices independently of DLNA.
• It should always be understood as: scan first, enrichment later.

Bottom line: the Network Scanner helps distinguish basic network visibility from protocol-specific device behaviour.