Web App (Chrome/Edge) - Does not connect to server as "Local".

[Steveo369 10]

I have bookmarks to http://app.emby.media or http://tv.emby.media (non-SSL server installation) within my browsers.  I use Emby with a variety of devices, both local and remote. 

When using the web app while on the same local network as my Emby server, the web app is determined to be 'remote' and subject to internet streaming bitrate limitations, etc.   This is noted by transcoding occurring, and the reporting IP address for the web app session in the Server dashboard is reported as my external IP address. 

This is not ideal, as it appears to be bouncing the data, and results in lower playback quality, slow menu navigation, and other internet related issues (I have a very modest upload speed)

When selecting the server using Emby Connect (on local network), the server address is reported in the Web App appears as my external DDNS address, not a local IP.

This bounceback behavior does not occur when I enter http://LocalIPaddress:port and connect directly (as expected).

Other devices on my local network (iOS, FireTV) using Emby Connect all report connections via the local IP address, and when selecting the server using Emby Connect, the local IP address is shown if I am on my local network, and the remote DDNS address is shown if I am remote.

So...  Why is this happening?  I know that I can create a pair of "Emby Local" and "Emby Remote" bookmarks in my browser and use one or the other depending on if I'm accessing using this PC/Browser remotely or local, but that seems contrary to the behavior of the other available applications.  Is this expected behavior for the Web App?

Nothing unusual about this LAN, no VLANs, VPN's or other unusual networking configurations.  Basic router config with UPNP (no static port forwards related to Emby), and DDNS setup.

Not sure which kind of log I should generate; I've currently got (4) sessions running, (tv.emby.media, app.emby.media, localipaddress:8096, iOS (remote), iOS (local)).  tv.

[Luke 37067]

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[Steveo369 10]

Ok.  My OP describes the situation as best as I can, I'm attaching several logs generated immediately after a server restart.  Hopefully this additional information helps identify the issue.

Here's the steps I took:

1. Laptop PC is connected on same LAN as Emby Server
2. Restart Emby
3. Start Chrome, use bookmark to open tab to http://Local_IP:8096, go straight to server Dashboard (leave tab open to view Activity)
4. Open new browser tab to http://Local_IP:8096, began streaming "Letterkenny" (approx 10s)., pause/stop and return to Home.(leave tab open)
5. Open new  browser tab to http://app.emby.media, began streaming "Sonic Highways" (approx 10s, paus/stop and return to Home.

When Chrome is playing media at "Local_IP:8096", the Activity shows this client app originating from it's assigned local IP.

 

 

When Chrome is playing media at app.emby.media, the Activity shows this client ap at my External IP (masked below)

embyserver.txt ffmpeg-remux-18470903-1c3b-46ce-9a3b-e89f84b601e8_1.txt embyserver-63843284812.txt hardware_detection-63843284838.txt ffmpeg-transcode-e452a196-4851-44f8-b31d-002fafb7e36d_1.txt

[Luke 37067]

 

Hi, can you give it another try? thanks.

[Happy2Play 8282]

In my test http/https online web client (app.emby.media) show LAN gateway when logged on via LAN

 

[Steveo369 10]

8 hours ago, Luke said:

 

Hi, can you give it another try? thanks.

What sorcery is this!?  Nicely done, this problem seems to be resolved.

Whatever you changed on the back end seems to have changed things for the better.  My server now recognizes when my laptop client web app is on the local network.  Streaming at full quality, without restriction to the Internet Speed setting.  Thanks!

I do note that the Activity section of the dashboard looks a little different when the connect is made through Emby Connect vs direct via Local_IP. 

In the image below, both clients were streaming from separate tabs in Chrome.  The client on the left is connected via Emby Connect.  It reports Emby Web 4.8.1.1, and shows remote pause/stop/message at the bottom of the card.  The client on the right is connected via LOCAL_IP, and it reports Emby Web 4.8.1.0, without pause/stop/message.  

Now, about that other thread with Recorded TV and "No Compatible Streams..."  still having problems with that one when connected using LOCAL_IP, but all seems to be OK when connecting using app.emby.media.  Now that the Emby Web App appears to be fixed and doesn't transcode down to my Internet speed limit, this isn't as big of an issue, but officially I am still having that as an issue when using my Local_IP. I wonder if this is partially related.  I'll update that other thread with some more logs.

[Luke 37067]

We had to renew our privilege for this with Google for it to work again.

But gradually they are taking away this capability and it's going to get to the point where you'll need to setup https to use app.emby.media

[Steveo369 10]

30 minutes ago, Luke said:

We had to renew our privilege for this with Google for it to work again.

But gradually they are taking away this capability and it's going to get to the point where you'll need to setup https to use app.emby.media

Interesting.  So this is almost all related to not having Emby SSL enabled, even on my local network? 

Well, I guess I need to do a little bit more reading up on getting a certificate going for convenience.  Between this and the http v https issue making a less than ideal end user experience (especially for non-techie folk), it seems that a few more guides/warnings in the Emby docs would be beneficial.  I know that you guys have this guide, but it doesn't really explain what might NOT work if it's not setup SSL.  

Unfortunate the Google's of the world are pushing this, don't know enough to say whether it's a good thing from a security standpoint, or just too many layers of needless security.

[Luke 37067]

https://developer.chrome.com/blog/private-network-access-update/

The deprecation trial has been going on forever, but every couple months we have to renew for it. They are trying to get rid of it but it has taken a while due to pushback that they're getting. But sooner or later it's going to happen.

[Steveo369 10]

21 hours ago, Luke said:

https://developer.chrome.com/blog/private-network-access-update/

The deprecation trial has been going on forever, but every couple months we have to renew for it. They are trying to get rid of it but it has taken a while due to pushback that they're getting. But sooner or later it's going to happen.

That chrome article is completely foreign to me, but I understand that this is a Google change. 

What (if anything) is or can the Emby team do to 'fix' this kind of issue or work around it?  Will you deprecate the Web App?  Or somehow give an informative redirect/info page if someone sets up an non-ssl server? 

The problems (plural) I've had in this thread and the other thread in this web app are related to this google security issue, and the errors I was getting did not provide details on the problems.  (One of the problems was Emby's google privilege, and the other is Chrome's implemented security restriction(s)).  When a user is literally trying to point a browser to an address on their local address and it just "doesn't work" with no feedback on why, this is a confidence killer (aka product-swapping) experience, unless information about why it isn't working is provided.

I get that this is a bit beyond your control, but the Web App has been the go-to defacto 'quick check' for most users to confirm that streaming from a server works, and if it doesn't (and doesn't tell the user/server owner why), this is a (HUGE) problem.

Enough of my mini-rant over, I do appreciate the Emby team for looking into this, but you guys need to really think about spinning up some additional communication if the web app is going to stop working reliably on the majority of browsers (Chrome, Edge).

On a similar subject, I'm generally not interested in investing the time or cost or continuing maintenance into establishing my own Domain + SSL Cert.  I've read through the various outdated guides on the forum and Emby's docs, and it appears to be more hassle than it's worth (to me, for my limited use case).

My main questions are -

• If I'm satisfied with using my DDNS and non-SSL connection for mostly local device access and only occasional remote access, should I simply plan to only stream my content via standalone Emby Apps such as Emby Theater or iOS/Android? 
• Is there any expectation (or chance) that the non-Web App would get into a similar security issue with a non-SSL server? 
• Any plans for a 'better' (or more full featured) dedicated Windows App? 
  • It appears that Emby Theater does not have full server dashboard management functionality, whereas the iOS app does.  

Again, thanks to the Emby team for a great product, I've been a user since this was a WMC plug-in.  Please don't take my comments above with any offense to you or your efforts, I'm just a bit frustrated by this change, and my lack of being able to understand WHY the issues were/are occurring without developing multiple forum posts.  

[Luke 37067]

Quote

Will you deprecate the Web App?

No, it's just that you might have to setup SSL in order to use it. 

But you always have the web app that is built into your emby server.