keithwalker80 6 Posted June 10, 2023 Posted June 10, 2023 Since the issue with the plugin that caused the servers to not start, I have had quite a few users not able to login remotely with the Emby App. I have verified the proper port forwarding, and had the users uninstall and reinstall the app and they consistently get a connection error. They are able to access from a web browser with no issues. Any assistance would be greatly appreciated.
ebr 15574 Posted June 10, 2023 Posted June 10, 2023 Hi. How are they connecting? Direct to your server address or through Emby Connect? If they enter your server address manually does it work?
keithwalker80 6 Posted June 10, 2023 Author Posted June 10, 2023 Hi Ebr. They have tried both ways and get the same result. The issue is through the Emby app on Firestick, or Roku or iPad or Android phones. If they go through the web browser on a computer or the mobile device with direct address or through Connect, they have no issues.
ebr 15574 Posted June 11, 2023 Posted June 11, 2023 Hi. Can you ensure that both addresses are exactly the same? http or https? Are you sure your cert is valid if https?
keithwalker80 6 Posted June 11, 2023 Author Posted June 11, 2023 HTTP only. Port forwarding rule is applied for the proper IP. No cert used.
warrentc3 45 Posted June 11, 2023 Posted June 11, 2023 (edited) I'm seeing a similar issue. Even with my iphone on cellular network ... it will play a video if i'm in safari, but if i use the ios app, it just spins. Local users, no emby connect. Edited June 11, 2023 by warrentc3
Junglejim 383 Posted June 12, 2023 Posted June 12, 2023 19 hours ago, keithwalker80 said: HTTP only. Port forwarding rule is applied for the proper IP. No cert used. This is not ideal for a secure server. I would look at securing it with a cert at least for remote access. I wonder why there are security issues at the moment..
rbjtech 4916 Posted June 12, 2023 Posted June 12, 2023 (edited) 5 hours ago, Junglejim said: This is not ideal for a secure server. I would look at securing it with a cert at least for remote access. I wonder why there are security issues at the moment.. The fact it is still even allowed in 2023 is personally a little irresponsible. I hope with the recent 'security' initiatives, http (edit - for remote access) is removed as an option - and a formal guide and/or partnership with a free TLS Cert provider is the only want to remotely connect. Edited June 12, 2023 by rbjtech clarify - for remote access only
keithwalker80 6 Posted June 12, 2023 Author Posted June 12, 2023 Good morning. While I appreciate the information about a cert, this does not lend any assistance to the issue at hand. Certs are something I am working on as I go. However, I am still needing help to figure out why only certain connections are an issue on certain devices. Any assistance with that would be greatly appreciated.
pwhodges 1814 Posted June 12, 2023 Posted June 12, 2023 30 minutes ago, rbjtech said: I hope with the recent 'security' initiatives, http is removed as an option But https between a local reverse proxy and a backend process is a real pain. Paul
rbjtech 4916 Posted June 12, 2023 Posted June 12, 2023 (edited) 15 minutes ago, pwhodges said: But https between a local reverse proxy and a backend process is a real pain. Paul A fair point - to clarify, I meant for remote access only. For local access (incl from a reverse proxy), then imo http is perfectly fine. Edited June 12, 2023 by rbjtech
rbjtech 4916 Posted June 12, 2023 Posted June 12, 2023 25 minutes ago, keithwalker80 said: Good morning. While I appreciate the information about a cert, this does not lend any assistance to the issue at hand. Certs are something I am working on as I go. However, I am still needing help to figure out why only certain connections are an issue on certain devices. Any assistance with that would be greatly appreciated. Have you tried removing the app and the app cache - rebooted the client - and then reinstalled ? I'm unsure if you are using an IP or a FQDN/DDNS Domain name - but it's possible that has changed or maybe you used a fixed IP on those devices originally, which has now changed ?
keithwalker80 6 Posted June 12, 2023 Author Posted June 12, 2023 Good morning Rbjtech: I have had the users clear the cache, and remove and reinstall the app on the offering devices. I have a static IP and port forwarding in place. I have had them use the external URL which contains the FQDN and tried to have them manually log in with ip or URL plus port. If they use the web browser, they can log in with no issues using Emby Connect or manual login. I am just at a loss at this point as to why it only affects some users and only on some devices.
rbjtech 4916 Posted June 12, 2023 Posted June 12, 2023 10 minutes ago, keithwalker80 said: Good morning Rbjtech: I have had the users clear the cache, and remove and reinstall the app on the offering devices. I have a static IP and port forwarding in place. I have had them use the external URL which contains the FQDN and tried to have them manually log in with ip or URL plus port. If they use the web browser, they can log in with no issues using Emby Connect or manual login. I am just at a loss at this point as to why it only affects some users and only on some devices. Very strange ! I know you would not want to keep it this way, but have you tried forcing the IP rather that using a FQDN (because you are using http, this is perfectly possible) - ie http://1.2.3.4 Port 8096 (or whatever port you are using). Clutching at straws here, but maybe the clients are not refreshing their DNS cache...
visproduction 250 Posted June 12, 2023 Posted June 12, 2023 (edited) KW, it sounds like you have a domain name non-secure from a quick read. Some browsers versions may automatically reject a non-ssl, non-https site with an alert. The user is sometimes presented a screen with an option to bypass this alert, which looks like the site is unavailable. An older version of the same browser may not have this alert. There also might be some virus checkers that add in a browser protection and also stop access. Try doing a traceroute (windows: tracert) on the IP address without the port. If that works, then your IP access to your server is working. I think that would point toward a browser, virus checker or firewall issue on the client's side. Edited June 12, 2023 by visproduction
rbjtech 4916 Posted June 12, 2023 Posted June 12, 2023 2 minutes ago, visproduction said: KW, it sounds like you have a domain name non-secure from a quick read. Some browsers versions may automatically reject a non-ssl, non-https site with an alert. The user is sometimes presented a screen with an option to bypass this alert, which looks like the site is unavailable. An older version of the same browser may not have this alert. There also might be some virus checkers that add in a browser protection and also stop access. Try doing a traceroute (windows: tracert) on the IP address without the port. If that works, then your IP access to your server is working. I think that would point toward a browser, virus checker or firewall issue on the client's side. The OP knows connectivity is working, as it works from a web browser from the same remote IP. It's odd that it's not working on the client - so it must be 'something' on the client - but I'm not sure what .. lol... as the OP has tried everything I would have done myself...
ebr 15574 Posted June 12, 2023 Posted June 12, 2023 Is it possible the routers on the remote network are not allowing unsecured traffic from those devices?
keithwalker80 6 Posted June 13, 2023 Author Posted June 13, 2023 For further info, I have attached a picture of the message that is being received. Again, this is only happening on mobile devices or streaming devices such as chromecast, roku or fire stick.
rbjtech 4916 Posted June 13, 2023 Posted June 13, 2023 So on the devices with an issue - the only thing left to do is to try and run a browser or something that allows network command lines. I know it will be painful, but if you load the 'Silk Browser' on the FireTV (it's probably already installed) and use the http:\\yourdomain.com:8096 - does that connect ok ?
keithwalker80 6 Posted June 13, 2023 Author Posted June 13, 2023 Thanks. I will try to explain that to the users.
visproduction 250 Posted June 13, 2023 Posted June 13, 2023 The last image is a mobile screen. Mobile browsers do not allow direct IP address in the URL. Instead, the browsers always use a search engine first, by design. You need to open a private / incognito browser window, to be able to go to an IP address. Users often don't understand this and assume that typing an address in the URL goes to the site. Most mobile users never type an address anyway. They just tap on links.
darkassassin07 603 Posted June 13, 2023 Posted June 13, 2023 3 minutes ago, visproduction said: The last image is a mobile screen. Mobile browsers do not allow direct IP address in the URL. Instead, the browsers always use a search engine first, by design. You need to open a private / incognito browser window, to be able to go to an IP address. Users often don't understand this and assume that typing an address in the URL goes to the site. Most mobile users never type an address anyway. They just tap on links. Where are you getting that info? Mobile browsers accept ip addresses just fine:
visproduction 250 Posted June 13, 2023 Posted June 13, 2023 Safari or Chrome on Apple IOS goes first to a search engine, which finds nothing on an IP address. It depends on which browser and OS you are using in mobile to see this issue.
pwhodges 1814 Posted June 13, 2023 Posted June 13, 2023 Some browsers will search if just given an IP address alone, but will do what they should if it starts with http:// Paul 1 2
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now