Serviio Server losing Discoverability

I've noticed that with (at least) the last three versions of Serviio (I'm currently using 1.3.1), everything is working fine, but then the Serviio Server suddenly becomes undiscoverable.

At first, I thought the Serviio Server was perhaps no longer running, but it seems to be (I can still see the same processes). Restarting the Serviio Server always fixes the issue though.

I have noticed that in the Serviio log, there are some messages about re-acquiring an IP address shortly before I notice the issue, hence I'm wondering if part of that process isn't working properly.

I've attached two sections of my Serviio log, one from when my router was set to assign a static IP to the box running the Serviio Server (Static.txt), and one from when the router was set to assign it a dynamic IP address (Dynamic.txt).

Note: The box running the Serviio Server is a ZyXEL NAS325. (I'm currently using Oracle Java SE Embedded version 7 Update 21.)

If you have any ideas about how to resolve this issue, or require any further information, please let me know.

Hi,

I'm currently facing the same issue, using Serviio 1.3.1 (Windows Version) with Panasaonic VT60.

R

rcnike: I had a quick look at your posts in another topic, and they sounded like something different to me. Are you experiencing this issue as well as the other?

[DenyAll]

JamesUK: Can't tell you why its happening, but I will tell you what is happening and perhaps you can fill in the rest.

In both cases Serviio is losing it's binding to the current IP address of the NAS (simplistically, it attempts to send a multicast out on what it has determined previously is the NAS's IP address and this fails). It then goes through a process to either recover the IP address or find the new address if it has changed.

In your dynamic case, it is finding a new address (192.168.1.66 - it was 192.168.1.79 prior to that). Question here is, did the address change and was the .66 address correct? If so, then Serviio appears to have worked correctly. If not, then does the .66 address mean anything to you? Any idea why it would be selected?

In the static case, Serviio is not finding the new address. It is finding (incorrectly) the "local loopback" address, 127.0.0.1. This is a definite problem, however generally Serviio will go through the process again once it works out that this IP address is not valid... was there anything later in the log that shows it trying to resolve an new IP address again. How is the static address being assigned (by the router, or on the NAS?)

So while the log extracts you have provided show what is happening, it is not explaining why. It doesn't explain why Serviio is losing the bound IP address in the first case (in the PC world the main reason for this is the PC going to sleep - does your NAS go into a sleep state or low power state that shut's down its ethernet port?) or why once lost, its not recovering a correct address. You may need to provide more complete logs, and check whether the NAS is going into a sleep/power saving state that is disconnecting its ethernet port.

I can't say with absolute certainty, but I'm pretty sure that the IP address of the NAS will have changed (from .79 to .66 in this case), as the router just dynamically assigns something in that private range. It seems like the Serviio Console on my PC has no problem with connecting to the Serviio Server when it has gone through that recovery process, but the Serviio Server is simply not discoverable via DLNA (on any TVs or PCs etc) until I restart it on the NAS. In other words, whilst it seems like the Serviio Server has perhaps recovered to some extent, it doesn't appear to have done everything necessary (or something failed).

Note: The router dynamically assigning an IP address to the NAS is how things were configured initially, when I first noticed the issue, so I thought I'd try setting the router to always assign the same IP address to the NAS, as I was hoping that would workaround the issue. However, doing so seemed to cause more issues, so I then switched it back (after collecting some logs). In terms of the logs, the Serviio Server wasn't performing any retrying beyond what I showed in the previously attached logs.

It seems like the Serviio Server runs for a while before the issue is encountered, e.g. a couple of days, so I wondered if it was related to IP address leases expiring or something. The NAS is set to power-down HDDs on inactivity, but I'm not aware of any other power management settings. Having said that, I'm not familiar with how all of that is configured in Linux, i.e. I'm just going by the power management stuff shown in the web UI provided by the NAS.

What additional logs would help? Do you mean Serviio Server logs at DEBUG or TRACE level?

[DenyAll]

What additional logs would help? Do you mean Serviio Server logs at DEBUG or TRACE level?

DEBUG level - was after more of the log, not just the snippets, to see if that shed any light on why it is happening. Seems though you already went through them so may not be any further benefit.

It seems like the Serviio Console on my PC has no problem with connecting to the Serviio Server when it has gone through that recovery process

How are you pointing your console to the Serviio Server - via IP address or via URL. If the former, that would suggest the IP address did not change....


The only thing I can think of is to set a static address for the NAS, in the NAS itself rather than via a fixed allocation from the DHCP server in your router which you did previously. This will remove all DHCP allocations and lease renewal from the mix. Make sure you also bind Serviio to that IP address in the console. You mentioned issues with a static address - what were they (its only a number and as long as its unique on your network and in the same subnet as your renderers, there shouldn't be any issues ...).

DEBUG level - was after more of the log, not just the snippets, to see if that shed any light on why it is happening. Seems though you already went through them so may not be any further benefit.

There was nothing else in the logs of interest (at the level being recorded), i.e. the only other stuff was irrelevant database/library updates. I might increase the logging level, just to see whether it captures anything else of interest, but the problem is that the issue happens fairly infrequently. It actually seems to have gone the longest without happening since I started this topic about it! (It's definitely gone longer than the DHCP lease time.)

How are you pointing your console to the Serviio Server - via IP address or via URL. If the former, that would suggest the IP address did not change....

The Serviio Console (on my Windows PC) is accessing the Serviio Server via hostname, hence the IP address of the NAS changing wouldn't cause an issue.

The only thing I can think of is to set a static address for the NAS, in the NAS itself rather than via a fixed allocation from the DHCP server in your router which you did previously. This will remove all DHCP allocations and lease renewal from the mix. Make sure you also bind Serviio to that IP address in the console. You mentioned issues with a static address - what were they (its only a number and as long as its unique on your network and in the same subnet as your renderers, there shouldn't be any issues ...).

As mentioned above, I'm not really suspicious of the DHCP lease time any more, as it's set for a day, and the problem seems to happen less frequently than that. In terms of the static IP address causing problems, I was really meaning that looking at the Serviio logs, it seemed like Serviio was having a harder time with a static IP address being assigned by the router. (I also have a feeling that the Serviio Server was not accessible from the Serviio Console when the recovery process ended-up using the loopback address, but I'm not sure about that if I'm honest.)

[DenyAll]

Yep, but the way you were previously doing the static address wasn't really static - the DHCP server was simply providing the same address each time (ps. this is the way I do it as well). I am guessing that the IP address is being lost for some reason, Serviio is then trying to find it but is doing so before the DHCP assigns the new (albeit the same) address. When it doesn't find it Serviio then uses the loopback address.

Assigning the address statically to the NAS device itself means that the there will not be this delay while the DHCP server (your router) reassigns the address, as the device will always have it. Hope this makes sense. I'm only trying options based on this guess - not sure whether this will work at all, but its worth a try.

Yes, it's easier to manage if you let the DHCP server look after it all. Anyhow, the next time that it goes wrong, I'll try cutting the DHCP server out of the equation, and see what happens. Thanks for the suggestion.

I'm now running with the NAS configured with a static IP address (not 'statically' assigned by the DHCP server), and it's been fine so far; It's only been about 40 hours though, so it's hard to say whether it's worked-around the issue or not yet.

For some reason, the NSA325 didn't seem to like the static IP address configuration, as when it rebooted it never came back up! I had to use the NAS Starter Utility from ZyXEL to let it gets its IP address from my DHCP server to get it working.

Anyway, after doing that it ran fine for ages, so I kind of forgot about the issue, but recently the issue has started happening again, and even more frequently than previously.

I have recently switched to the latest Serviio and Java versions, as well as the latest firmware on the NSA325, so I guess it could have been any of those "upgrades" that did it.

In the end, I created a mini web app (hosted on the NSA325) for restarting and checking the status of the Serviio daemon, so that it was easy to "fix" the issue from any web-enabled gadget in the house.