Local access address not correct

[raven-au 17]

Hi all,

 

The last two versions of Emby server I have installed on my QNAP NAS, 3.0.5821.0 and now 3.0.5870.0, get the local access address wrong.

 

This causes applications that use automatic discovery, such as Emby for Android TV, to not function.

 

There is no way to override this in the server configuration.

 

In my environment I have Emby installed on a QNAP NAS (IP 192.168.1.12), it's connected directly to a router (IP 192.168.1.1) and the router is connected to a router that is set to a modem, aka. pass through bridge.

 

But, even though the router is set to be a modem it does have an IP address (IP 10.0.3.1).

 

Emby server claims its local access IP address is 10.0.3.1 which is clearly wrong in multiple ways.

 

As I say this has only started happening recently.

 

Ian

[Luke 37083]

do you have an android smart phone? can you see if discovery with the mobile app works?

[raven-au 17]

do you have an android smart phone? can you see if discovery with the mobile app works?

 

I don't, I do have some iOS devices.

 

It certainly doesn't work with Emby for Android TV, it sees a sever of the address displayed on the server dashboard, as expected, but that isn't accessible and is not where the Emby server is running. 

[Luke 37083]

doesnt' the app support manual address input though?

[raven-au 17]

doesnt' the app support manual address input though?

 

Yes, and AFAICS that address must be entered every time the app is run.

 

I'll install the newer version again later and check if it can be set to remember the address.

Edited February 16, 2016 by raven-au

[ebr 14916]

You can set the app to automatically log in to a particular user, which also implies a particular server address.

[raven-au 17]

You can set the app to automatically log in to a particular user, which also implies a particular server address.

 

But that can only work if the app see the server at the correct local address.

 

It tuns out that 10.* addresses aren't used anywhere on my local network.

The router I have in modem bridge mode actually has an address of 192.168.3.1 not 10.0.3.1 so it's a mystery why the servers thinks its address is 10.0.3.1.

[OddbOd 21]

I too noticed this on v.3.0.5818.0 yet my android tv client still connects correctly, I'm just about to upgrade my Emby server to 5870 so I'll see if there is any change.

 

Would you please check your server log and paste the "Creating SSDP listener" log lines that appear just after the server starts up? I have a suspicion of what the cause might be but would like to confirm that the reason is identical before proceeding.

[raven-au 17]

I too noticed this on v.3.0.5818.0 yet my android tv client still connects correctly, I'm just about to upgrade my Emby server to 5870 so I'll see if there is any change.

 

Would you please check your server log and paste the "Creating SSDP listener" log lines that appear just after the server starts up? I have a suspicion of what the cause might be but would like to confirm that the reason is identical before proceeding.

 

I will but I have reverted to the last working version now and I've fallen behind with work due to family needs so work catch up must come first over the weekend.

[raven-au 17]

I will but I have reverted to the last working version now and I've fallen behind with work due to family needs so work catch up must come first over the weekend.

 

Right, I see:

 

<logs] # grep "Creating SSDP listener" server-63591644257.txt             

2016-02-21 09:38:42.1289 Info IDeviceDiscovery: Creating SSDP listener on 127.0.0.1

2016-02-21 09:38:42.1289 Info IDeviceDiscovery: Creating SSDP listener on 192.168.1.12

2016-02-21 09:38:42.1289 Info IDeviceDiscovery: Creating SSDP listener on 10.0.3.1

2016-02-21 09:38:42.1362 Info IDeviceDiscovery: Creating SSDP listener on 10.8.0.1

 

in the log.

 

Looking further I now see where Emby is getting the addresses from.

They are probably from the docker lxc and native execdriver interfaces.

 

Ian

[Luke 37083]

which one does it list on your server dashboard?

[raven-au 17]

which one does it list on your server dashboard?

Said that several times above, 10.0.3.1.

[raven-au 17]

You can set the app to automatically log in to a particular user, which also implies a particular server address.

 

Which isn't useful if you need to be able to login as different users. family or kids for example.

I can't understand why the client doesn't remember an address when entered.

That's just not that useful, a message saying clearing the address will revert to auto discovery would be enough to avoid confusion.

 

But that can only work if the app see the server at the correct local address.

 

It tuns out that 10.* addresses aren't used anywhere on my local network.

The router I have in modem bridge mode actually has an address of 192.168.3.1 not 10.0.3.1 so it's a mystery why the servers thinks its address is 10.0.3.1.

 

Which isn't quite right, since the Emby server can be reached at the correct address, at least it can now I'm using a container.

That wasn't the case, IIRC, with the native QNAP qpkg install.

 

The container is set to network host so the address is still wrong in the current release, 5911.

As I said above, it isn't possible to save an address in the client if you can't use the auto login as a user.

 

The short of it is something was changed which now prevents the server from selecting the actual address it should advertise.

That hasn't been changed and the client hasn't been changed to allow use of an input address so I can't use emby on all the devices I need to.

 

That is a shame for the obvious reason, it prevents me from using emby.

[raven-au 17]

Which isn't useful if you need to be able to login as different users. family or kids for example.

I can't understand why the client doesn't remember an address when entered.

That's just not that useful, a message saying clearing the address will revert to auto discovery would be enough to avoid confusion.

 

 

Which isn't quite right, since the Emby server can be reached at the correct address, at least it can now I'm using a container.

That wasn't the case, IIRC, with the native QNAP qpkg install.

 

The container is set to network host so the address is still wrong in the current release, 5911.

As I said above, it isn't possible to save an address in the client if you can't use the auto login as a user.

 

The short of it is something was changed which now prevents the server from selecting the actual address it should advertise.

That hasn't been changed and the client hasn't been changed to allow use of an input address so I can't use emby on all the devices I need to.

 

That is a shame for the obvious reason, it prevents me from using emby.

 

And another thing about the client.

 

If I put in a pin code it reports two instances of the same server, one at the incorrect address and one at the correct address.

 

The one at the incorrect address can't be reached so is not useful.

The one at the correct address is missing the last digit on the port number (ie. 809 instead of 8096) and so cannot be reached.

 

I am reasonably patient waiting for things to improve and features to become available but not being able to use Emby on one of my primary devices pretty much forces me to not use Emby which is a bit of a shame.

[raven-au 17]

Still no comments and no suggestions.

That's not useful folks!

[Luke 37083]

Hi, sorry about the above. We are working on adding the delete server function to the android tv app so that you can clear out the one that you're no longer using.

[raven-au 17]

Hi, sorry about the above. We are working on adding the delete server function to the android tv app so that you can clear out the one that you're no longer using.

 

Sure, but there were other problems I described, did you understand what I described?

 

Wrt. the Android TV client, in my particular case:

 

1) when two servers are seen at different addresses the second is shown with an incorrect port number.

 

If the port number was ok I would have been able to connect.

 

2) If you need to specify a server by address there is no way to save that setting other than to set always login as that user.

 

So if you need to be able to login as a different user depending on who is using Emby you always need to enter the address.

This may be covered by the delete server function, I don't know.

 

3) One I didn't yet mention, when entering a server address the dialog imples only an IP address is needed which is plain wrong.

 

Now, you could say I should have known better and you'd be correct, but that doesn't change the fact that the dialog is lacking.

 

 

And I described a problem with the server too.

 

If there are multiple interfaces the server can select an incorrect primary interface.

 

It seems to me that since one can specify a particular external interface and port as well as the port for the primary interface (which probably means all interfaces) it would be sensible to be able to specify a particular primary interface (or interfaces) as well. A blank value could mean behave as it does now.

 

I don't know what changed to cause this but it has only started happening on that last several releases.

 

And I've had even more problems trying to work around it.

 

The same problem exists if I use a container in network in host mode, which as you probably know, is needed for it to work properly (I had to create my own because the supported one is not appropriate for QNAP).

 

Creating a Virtual Machine with an external-only network interface gets rid of the additional interfaces and functions fine except that when updating Emby the rpm failed the update, leaving some database or other locked, when it tried to scribble on the remotely mounted configuration (as the root user which I think was part of the problem) and that resulted in me spending a couple of days resurrecting it since I didn't know how to repair it.

 

This later problem might be on me for a couple of reasons to do with my wanting to use direct paths and the fact that only one server can be setup in Emby for Kodi to access both the config and the media files. I won't go into that further.

 

So, sadly, I'm fairly frustrated at this point, so any changes that you can do that may help would be very much appreciated,

At least now I have a working setup, at least until the next server update.....

 

Ian

Edited April 14, 2016 by raven-au

[ebr 14916]

2) If you need to specify a server by address there is no way to save that setting other than to set always login as that user.

 

I'm not sure why this is the case.  I just manually entered a server address (IP only ) and connected to it.  Exited the app, then re-entered and that server is in the list of servers for me to just click on...

 

 

3) One I didn't yet mention, when entering a server address the dialog imples only an IP address is needed which is plain wrong.

 

That is incorrect.  You can enter just an IP address - as long as your server is on the default port.  If your server isn't on the default port, then the assumption is, you know enough to know you'll need to specify it.  Adding any kind of text around that would, IMO, confuse the average user and make them think they have to know a port number.

[Luke 37083]

Can you help us improve by providing more details to these two points. In our tests they work, but you're saying it doesn't for you. Also, what exactly did you enter into the server address field? Have you customized the server port? Thanks.

[raven-au 17]

I'm not sure why this is the case.  I just manually entered a server address (IP only ) and connected to it.  Exited the app, then re-entered and that server is in the list of servers for me to just click on...

 

I didn't see this, perhaps because when there are two servers in the list of servers (as was the case for me) the second server is listed with an incorrect port number (three digits not four) and consequently doesn't work.

 

Perhaps this oddity is what is making things so bad for me....

[raven-au 17]

That is incorrect.  You can enter just an IP address - as long as your server is on the default port.  If your server isn't on the default port, then the assumption is, you know enough to know you'll need to specify it.  Adding any kind of text around that would, IMO, confuse the average user and make them think they have to know a port number.

 

That's not what I observed.

I've always used the default port on server instances and I needed to include that default port when entering an IP address otherwise it wouldn't work.

 

This is all on the Android TV app of course.

[Luke 37083]

Hi, can you please be more specific. What does "doesn't work" mean? Do you see an error message? If so, what does it say? Thanks!

[raven-au 17]

Hi, can you please be more specific. What does "doesn't work" mean? Do you see an error message? If so, what does it say? Thanks!

 

When it couldn't connect to the Emby server there were a couple of different messages I saw.

 

One fairly common message was something about a volley error, other times it would hang for ages and sometimes the screen would just turn black.

 

It depended on whether I tried a listed server at the address it won't get a response from, because it corresponds to an interface on which the server isn't available, or whether I selected the server listed at the correct address with an incorrect port. Neither of these results are surprising and are I think expected.

 

If I used the enter address dialog and provided only an IP address, IIRC, I would get the volley error.

 

Entering the correct IP address together with the correct port I was able to connect to the server.

 

I can't work through this and report the specific messages now because, firstly I've been trying to use Emby running in a virtual machine without the extra interfaces that are present when it runs either in a container with net type host or natively on the QNAP, and secondly the Android TV client fails to start at all now for the last several days, perhaps even more than a week.

 

At the moment the Android TV client will always hang on connection, after a while the screen will just go to a black without any message.

 

I don't know why this has started happening, it did work fine with the virtual machine for short while.

 

Ian

Edited April 20, 2016 by raven-au

[Luke 37083]

Ok, there's a new release of the android tv app out. I would try that, then report any issues in the android tv section of the forum. thanks.

[raven-au 17]

Ok, there's a new release of the android tv app out. I would try that, then report any issues in the android tv section of the forum. thanks.

 

Actually, for a change I have something positive to report.

 

I changed two things in my Emby VM.

 

One, I ran an update to get the latest Emby server version and that worked fine this time.

I guess I should have known better than to use a CIFS mount for the configuration, rather than an NFS mount on a Linux system.

So that's good news for me.

 

Second I set the server friendly name to a simple name rather than let the server use the host name (which has a domain name component) as it does by default.

 

Much to my surprise the Android TV client (and the iOS client for that matter) can now connect to the server.

 

What I saw was a little strange though, the auto detect didn't find the server.

 

After setting the pin I got an empty server list but selecting "enter manually" and entering an IP address only (no port number) I immediately got a users list and was able to use Emby.

 

Furthermore it appears to stick over restarting the client.

 

This is much more like the described expected behaviour.

 

Unfortunately I now see that the client has grown an aspect ratio problem recently.

Playing my SD DVD rips that should display as 16:9 now display as 4:3 but that has been mentioned in another thread.

I think this is something that has changed recently because I'm 99% sure they were working before I became unable to use the client.

 

So I guess we're only left with the original primary interface selection problem and some perhaps useful information about the server name setting that might be producing quite unusual behaviour. Worth keeping an eye out I guess.

Edited April 21, 2016 by raven-au