iOS client gets frequently logged out

[mprasil 14]

This one has been bugging me for quite a while. I have one iOS client (the only iOS device actually) that regularly gets logged out from my server completely. Every couple weeks (possibly even days - this device is not used frequently, so I'm not entirely sure) the App seems to completely forget login details. Every time I need to go through the whole login setup. (enter server address and port, username, password, etc..)

The app does keep the downloaded offline content, so not all things are lost, just the credentials.

At first I thought that I just forgot to check the "remember me" checkbox. But that is not the issue, I definitely checked it last few times.

I have couple other devices and users - Android, Web, Linux apps - and all of these don't have this problem.

I'm only using local accounts on my server - in case this is important here.

Any ideas what could be causing this?

[Luke 37090]

Hi, that's strange. I wonder if local app data is being cleared for whatever reason 

[mprasil 14]

That's what I would assume. But then I'd expect the offline content to also disappear, right?

[CharlieMurphy 73]

I just came here to ask the same question. This is happening to a family member. I'm not an iOS user but it seemed like the equivalent of "clear data" on Android. I thought maybe the storage being full of pictures was causing it to clear app data to make space to run. I made him clear out pics and stuff to make storage space, logged him back in, a week later and it's logged out again.

@mprasil Do you also have nearly full storage? I may have been wrong in assuming that was the issue.

[mprasil 14]

16 minutes ago, CharlieMurphy said:

@mprasil Do you also have nearly full storage? I may have been wrong in assuming that was the issue.

No, that iPhone does not have anywhere near full storage.

[CharlieMurphy 73]

Okay thanks. I am a total n00b on Apple devices but if I happen to find a solution I will report back. Right now I don't even have a theory anymore.

[Thuzad 42]

I have noticed this problem when I switch from my local network to the outside. You have to specify the external URL of the server and that it is also accessible locally.

[CharlieMurphy 73]

That does make sense but in my case the iPad has never been local to my Emby server. It's just behaving like I never entered the server info or user. It might be relevant that I don't use Emby Connect.

[mprasil 14]

1 hour ago, Thuzad said:

I have noticed this problem when I switch from my local network to the outside. You have to specify the external URL of the server and that it is also accessible locally.

I have the same URL locally and outside, but I wonder if the resolved IP from local LAN isn't cached and then fails when outside?

1 hour ago, CharlieMurphy said:

It's just behaving like I never entered the server info or user. It might be relevant that I don't use Emby Connect.

This is exactly the same for me. I also don't use Emby Connect. (and don't want to)

[Luke 37090]

The app automatically switches between the two addresses as the network changes, so it shouldn't matter which one you start with.

[mprasil 14]

12 minutes ago, Luke said:

The app automatically switches between the two addresses as the network changes, so it shouldn't matter which one you start with.

Which two addresses are we talking here? There's only single URL configured or am I missing something?

[Luke 37090]

1 hour ago, mprasil said:

Which two addresses are we talking here? There's only single URL configured or am I missing something?

The url you enter into the app only establishes the initial connection. After that it will get the addresses from the server so that it can automatically switch as needed.

[mprasil 14]

1 hour ago, Luke said:

The url you enter into the app only establishes the initial connection. After that it will get the addresses from the server so that it can automatically switch as needed.

Oh that's interesting. I run Emby behind reverse proxy and server running as Docker container, so I wonder if there's a chance that this address resolution is somehow messed up. The dashboard shows both local and wan URLs wrong (from client POV):

The LAN IP is just container IP. This IP is not directly accessible from LAN. Also it's using http, which is not correct. The WAN has correct domain there, but both LAN and WAN have wrong ports. It should be https and standard port 443 for both.

Could this be causing these issues? I never really paid any attention to this as other clients seem to be working fine locally or from outside.

[Luke 37090]

3 hours ago, mprasil said:

Oh that's interesting. I run Emby behind reverse proxy and server running as Docker container, so I wonder if there's a chance that this address resolution is somehow messed up. The dashboard shows both local and wan URLs wrong (from client POV):

The LAN IP is just container IP. This IP is not directly accessible from LAN. Also it's using http, which is not correct. The WAN has correct domain there, but both LAN and WAN have wrong ports. It should be https and standard port 443 for both.

Could this be causing these issues? I never really paid any attention to this as other clients seem to be working fine locally or from outside.

I don't know if this is your specific issue, but yes, in general, if the server doesn't know the correct addresses then this may cause you problems. For most servers the automatic detection should work fine but in your case you may need to customize the lan address as well as the public facing port, which you can do in Emby Server network settings.

Alternatively if you put Docker in host networking mode, then the autodetection will be more likely to produce the correct result. The only downside of customizing the LAN address is that you're going to have to remember to go back there and update it in the event that it changes.

[mprasil 14]

7 hours ago, Luke said:

I don't know if this is your specific issue, but yes, in general, if the server doesn't know the correct addresses then this may cause you problems. For most servers the automatic detection should work fine but in your case you may need to customize the lan address as well as the public facing port, which you can do in Emby Server network settings.

Alternatively if you put Docker in host networking mode, then the autodetection will be more likely to produce the correct result. The only downside of customizing the LAN address is that you're going to have to remember to go back there and update it in the event that it changes.

Thanks for reply @Luke that makes sense. However as far as I can tell, I can't quite configure Emby to reflect the actual setup I have. First of all, there is no http, I only use https - I don't see any option anywhere to change LAN access to https. I managed to change the LAN IP, but not the port or protocol.

As for using host networking, this is not possible as Emby is behind reverse proxy, that does all the encryption.

So far I was able to set remote (WAN) overrides to the point where that URL is correct. But to actually also fix the local LAN, I need to:

• change the protocol to https
• change the IP to domain name (otherwise there will be certificate mismatch)
• change the port to 443

Is any of that possible?

Alternatively I could just leave the local LAN access unused and just let Emby think it's on docker network LAN with no local clients. And have all the clients "remote" using the remote URL, that seems to be currently correct. Is there any downside to that?

[Luke 37090]

@mprasil did you figure this out?

Quote

leave the local LAN access unused

What exactly do you mean by this?

[mprasil 14]

6 hours ago, Luke said:

@mprasil did you figure this out?

I'm not sure. I've changed some network settings in Emby and will have to wait to see if the app logs out or not.

6 hours ago, Luke said:

 

Quote

leave the local LAN access unused

What exactly do you mean by this?

So I have Emby in docker container behind reverse proxy. This reverse proxy also does SSL. As far as I can tell there's no way to configure Emby to be aware of this fact to the point where it would display correct protocol (https) and port (443) in the dashboard for the local LAN. Right now it shows this:

Which is kind of correct as that really is the URL that my proxy uses to reach it, but for the client applications neither the network (internal docker network) nor the port are directly accessible. I have Remote (WAN) access set up correctly in the form of https://mydomain:443, but as far as I can tell there's no way to set In-Home (LAN) access to the same?

[samuelqwe 313]

7 hours ago, mprasil said:

I have Remote (WAN) access set up correctly in the form of https://mydomain:443, but as far as I can tell there's no way to set In-Home (LAN) access to the same?

You can set the correct Local IP and the ports for both http and https within Emby’s network settings. I don’t think there is way to make the LAN address on the dashboard show as https, but if you don’t expose the http port on the container, I would assume an Emby client would try to connect with https if it can’t connect with http (though I haven’t tried).

I am running a similar setup myself (Docker container running on a custom Docker network to reverse proxy) though I don’t restrict http access on the local network (https only for remote connections). The way I have it set up, Emby has no trouble switching between local and remote connections without getting logged out.

[mprasil 14]

3 minutes ago, samuelqwe said:

You can set the correct Local IP and the ports for both http and https within Emby’s network settings.

Which I already do.

4 minutes ago, samuelqwe said:

I don’t think there is way to make the LAN address on the dashboard show as https

Exactly, so this one will always be wrong for that reason. You can't reach my Emby instance over plain HTTP. On top of that I haven't found a way to use hostname instead of IP for the local access, so even if I managed to somehow force HTTPS there, the certificate wouldn't be valid.

7 minutes ago, samuelqwe said:

though I don’t restrict http access on the local network

I would like to avoid that if at all possible.

[samuelqwe 313]

1 hour ago, mprasil said:

Exactly, so this one will always be wrong for that reason. You can't reach my Emby instance over plain HTTP. On top of that I haven't found a way to use hostname instead of IP for the local access, so even if I managed to somehow force HTTPS there, the certificate wouldn't be valid.

If I understand correctly, your Emby instance is only locally accessible through that hostname? And the cert is valid only for that hostname?

1 hour ago, mprasil said:

I would like to avoid that if at all possible.

I understand, I was just pointing out the differences between our setups. 

[mprasil 14]

2 hours ago, samuelqwe said:

If I understand correctly, your Emby instance is only locally accessible through that hostname?

Yes, exactly. The proxy wouldn't know where to route request to an IP as there might be another service there. (under different hostname)

2 hours ago, samuelqwe said:

And the cert is valid only for that hostname?

Yes, certificates are generally for specific hostname. (talking about usual certs that are provided by Let's Encrypt or so)

2 hours ago, samuelqwe said:

I understand, I was just pointing out the differences between our setups. 

Yep, thanks for that. It's interesting theory that the client might be trying (and failing) to use the LAN IP and logging out. If that's the case I hope there's some way to solve this. (after all Android devices have no problem with the exact same setup)

[samuelqwe 313]

39 minutes ago, mprasil said:

Yes, exactly. The proxy wouldn't know where to route request to an IP as there might be another service there. (under different hostname)

Is it the same hostname when accessing locally and remotely? Rather, are you trying to have every connection go through the reverse proxy regardless of origin (local or remote)?

39 minutes ago, mprasil said:

Yes, certificates are generally for specific hostname. (talking about usual certs that are provided by Let's Encrypt or so)

Yup… not sure why I didn’t realize that before asking haha 

Edited November 10, 2022 by samuelqwe

[mprasil 14]

41 minutes ago, samuelqwe said:

are you trying to have every connection go through the reverse proxy regardless of origin

Yes, exactly. The reason being that the proxy does SSL termination. And yes, it's the same hostname no matter what.

[samuelqwe 313]

21 hours ago, mprasil said:

Yes, exactly. The reason being that the proxy does SSL termination. And yes, it's the same hostname no matter what.

The only way I can think of forcing clients to always try to connect "remotely" is to change the LAN networks setting in Emby to something that isn't your local network subnet and make it think it's always remote. Don't know if that would work well or cause other issues though.

[K22R8CT 24]

On 11/10/2022 at 3:32 PM, mprasil said:

It's interesting theory that the client might be trying (and failing) to use the LAN IP and logging out. If that's the case

Maybe related:

I run two Emby instances (stable and beta) and noticed iOS would frequently prompt me to manually reconnect. When I changed the subnet of the beta instance (preventing it from broadcasting to the iOS device) the problem went away.