Do not assume IP addresses are persistent by default

[Former user]

It would be preferable for devices to be saved based on their MAC address rather than IP address.

If your DHCP server re-uses IP addresses: -your device list in Serviio will be huge and it takes some time to clear it; -you will run into problems when an IP address is re-used.

Edit: Title changed to reflect UUID comments

[Petr Nejedly]

For devices that support UPnP M-SEARCH replies Serviio can use their unique identifier - in that case the IP can change and there will always be just one in the list. For the devices that don't support this detection by IP is the only possible way - Serviio has no way to find out the client's MAC address when a request comes in.

I'll consider this an invalid ticket unless you have something else to add.

Thanks.

[Former user]

Hi,

Is the UUID used currently? I have just forced a change of the IP address on my BDP-S570 - the UUID did not change but I now have two entries in my Serviio device list. So this can be changed to a bug report or a request for the UUID to be used, depending on whether it is supposed to be currently used.

The MAC address was just a suggestion based upon no knowledge of the UUID. The MAC address is not perfect because the client device may have multiple network interfaces. However it could be found out via an ARP request I would have thought and Windows does display it in the device properties (attached). However, this is irrelevant now, as the UUID is obviously the better solution.

My problem was based upon my own experience. My router was allocating different IP addresses to devices and I had about 20+ devices in my Serviio list. At this point streaming to my BD player stopped working, presumably because it had the wrong profile attached. It was also a pain to clear the device list, because after removing a device the Serviio console does not select the nearest one so you have to click Remove, click on a device, Remove (and repeat..). I have since changed my router configuration.

[Petr Nejedly]

Your player is one of those that doesn't support M-SEARCH and therefore detection is only based on the IP address matching.

I can only get the UUID from the device's description document which is only known if the device advertises it (via M-SEARCH reply).

I recommend to setup static IP addressing on your DHCP server.

[Former user]

Hello,

As far as the BDP-S570 goes, you can get the UUID via the Ircc.xml file at http://<bdpipaddress>:50001/Ircc.xml. This is device specific I think, though. The UUID is in its SSDP NOTIFY broadcasts, but maybe you can't wait for that.

I was going to say you could fallback on to its MAC address, but from a quick Google search it seems Java makes that difficult. At least, it is easy for native Windows applications e.g. using SendARP API.

BTW I did change my router configuration already, but that isn't really the point. At the very least you could fix the Remove button to select the nearest item after removing one.

[Paul York]

Petr, I've noticed this with my PS3. Not long after a power outage, I had the PS3 take an IP once used by a generic device and suddenly nothing was transcoding. It took me quite some time to track down the problem. Yes, it isn't that hard for ME to set up persistent IP's, but if the goal is to make this "just work," wouldn't it be good to try and address this in a more robust manner? Most folks are going to be doing REALLY well just to install this thing and point it at their photos, music, and videos folders.

A MAC address as a secondary, fallback ID to the UUID for devices that don't support M-SEARCH would seem to make good sense. And it doesn't seem that tough in JDK 1.6.

http://www.kodejava.org/examples/250.html

[Petr Nejedly]

The example you gave is for local MAC address. I have no means of working out MAC address of the remote device - just from a http request.

PS3 should autodetect the right profile, if not then the regex used might be wrong. If you work out why it doesn't autodetect then great (from logs, especially http headers sent when retrieving device description)

[Paul York]

I see the problem with the MAC, though the UUID should be usable...in theory. But the PS3 must be a non-standard UPnP device. I can't even see it using the UPnP tools. I have a /rest/status showing three different PS3 devices with three different UUID's. I guess this implies that you are assigning a new UUID yourself because the PS3 doesn't do the M-SEARCH thing? If so, then yes, that is quite problematic in a Java world with no ARP capabilities.

Regardless, the problem definitely is that when you have an old device at an IP address, you don't reassign the profile to the autodetected one when a different device connects using that same IP address. So, in my case, I had a generic device at 192.168.1.154, and when the address was reassigned to the PS3 and the PS3 connected, you assumed it was the old device and used the generic profile. I assume you either skipped the autodetect process because you found an IP match or you didn't want to reassign a profile to a device based on your autodetection on the chance that you were clobbering my customization of that device.

Anyway, I could pretty easily fix it on WHS by caching your device database, doing a MAC comparison, and then "moving" the old device to the new address using a delete/add. But since I have around 775 users and you have 100K+, perhaps you could do something on your end like:

1) store as part of the device entry BOTH the autodetected profile and the assigned profile. 2) when a device connects, first check that the UUID matches that of the IP-matched device in your database. If so, you're golden. 3) if not, perform your profile autodetect logic. 4) if the device has a different autodetected profile than the autodetected profile currently stored for the IP-matched device, then assume it is a recycled address and overwrite the device currently in your database.

Fairly safe and straightforward, if perhaps a bit ugly. But I think it would solve the issue for 90% of your users. And it would certainly seem preferable to the current situation.

[Petr Nejedly]

Made this change to store Renderers whose profile is detected based on HTTP headers:

1) If there already is an existing renderer on the incoming IP address (probably added by a proper UPnP renderer search or previous DHCP assignment) it gets replaced by a new Renderer only if a Profile can be found.

2) If there is no Renderer for the IP address try to get a profile based on HTTP headers and create a new Renderer in any case.

[Petr Nejedly]

reopening this. It seems this update disabled saving another profile as it always reverts back to the detected one. It then makes it unable to test a device with another profile (after restart).

http://forum.serviio.org/viewtopic.php?f=11&t=3410&p=22632#p22632

[Petr Nejedly]

Need to add a 'forced' attribute to renderer DB table which is set to true when user selects a profile in the console. Renderers with this set to true should not be assigned new profile by auto detection.

For proper UUID we have to support IP change still (and use the preferred profile), for fake renderers we can't do much and an autodetected profile should be assigned.

[Petr Nejedly]

Also check how UPNPSearch and HttpSearch work together: http://forum.serviio.org/viewtopic.php?f=5&t=4153