Emby Server Web Interface Not Accessible Over LAN

March 4, 2018

I have quite a few questions regarding a NEW Emby server installation, but this topic will strictly focus on 1 problem only.

Problem:

The EMBY web server interface on the "emby server" does not display over a LAN connection to a web browser running Firefox-ESR 52.6.0. All I get is a black screen. No swirls. No hourglasses. No nuthin.

Server:

CPU: Intel D2550 CPU (2+2, cores+HT)

Memory: 4GB (that's all that is supported by the CPU)

LAN: Gigabit Ethernet everywhere, no errors reported in any switches or NIC interfaces

OS: Debian 10 "buster", fully updated

Desktop: Openbox+LXDE

The "emby server" is the only "added service" running on this system.

I did ensure that the "minissdpd" package was installed and correctly configured.

This PC can PING devices on the LAN and on the Internet as well as pulling down Debian updates.

This PC does not have any firewall configuration; it is open to the LAN, but does not expose any ports to the Internet since a separate firewall handles that access and does not enter into this problem at any time since none of the client<->server traffic in this test goes through it in any way shape or form. LAN traffic is all "switched" in a common IP subnet such as this since it is a single Layer 2 and single IP broadcast domain.

Client for testing "emby server" web interface:

Windows 7 on an HP laptop

Browser: Firefox ESR, 52.6.0, 64-bit

LAN: Gigabit Ethernet, 1 "switch hop" away from the server

This PC can PING devices on the LAN and on the Internet as well as doing the other stuff typically associated with a personal PC.

PC anti-virus/security packages, when enabled, does not show any traffic being blocked between the "client" PC and the "emby server" PC. Disabling the AV/security software did not make a difference here.

Network:

All Gigabit Ethernet via Netgear "smart" switches so I can monitor/manage them. No "plug & pray" switches for me.

No VLAN issues; everything is in the same VLAN.

No SMB browsing issues or access isues in the "house LAN". No Internet access or web browsing issues. All of those functions work correctly.

Network throughput testing using "iperf" in Linux shows I can achieve network speeds up to 900+ megabits per second across all points of the LAN.

Everything is IPv4; no IPv6 here, though I have tinkered with it some.

Setup:

I installed "emby server" 3.3.0 using the ".deb" file as provided on the EMBY website.

Once the ".deb" was installed by "dpkg" I attempted to access the web interface over the LAN from the "client" at "ip address:8096", where "ip address" is the IPv4 address of the "emby server". All I got was a black screen in Firefox with the URL bar showing something about "setupwizard". I sat and watched that black screen for almost 5 minutes before giving up on it. So I consider that attempt "quite fair" to the EMBY product.

Seeing how an "over the LAN" setup interface did not seem possible I moved to the "emby server" to access the "http://localhost:8096"URL via the Firefox ESR browser (also 52.6.0, 64-bit) via the desktop. That DID WORK.

I would find it highly unlikely that the EMBY server should not be accessible over a network when it appears that's one of it's primary features.

Based on my own testing and my own experiences with my now multi-year old network, "network connectivity" does not appear to be the issue here. I am also ruling out web browser issues at the "client" and "emby server" PCs since they do everything you would expect a web browser to do.

I would like to say that I don't know how to setup a network or setup Linux-based services on a network, but that would be completely incorrect based on my many years of experience in Linux & computer networking; I use Windows only when I have to; years as a MCSE taught me to appreciate Linux.

I might have overlooked something in the EMBY setup since it is new to me and has lots of configuration options. I did see the initial EMBY prompts and dialogues to setup some stuff that finished with webpage showing a web dialog box and a "Finish" button highlighted in green which I presume were all part of the "setup wizard" process.

I then proceeded to the "emby server" settings and stepped through the menu items one at a time to see what might need to be changed. That process raises a number of other questions, but that's for another topic at another.

I am "going somewhere" with this entire project. Think "kodi + emby + old Silicondust HDHR3-US box + house LAN" and you should get the picture.

So my initial question:

Is EMBY not intentionally designed to be accessed by a web interface over a network for setup? For any reason? :huh:

Edited March 4, 2018 by oldguykodi

March 4, 2018

A few more details...

Via the web browser on the local "emby server" I was able to access content on the Internet and access EMBY plugins via the "emby server" GUI. So I know the "emby server" is definitely communicating on the "house LAN" to the "house firewall" and then out to the Internet.

I am able to monitor various parameters of the "emby server" PC using a separate monitoring application called "Monitorix". Monitorix has it's own web server interface that runs on a completely different and configurable port (default is 8080) relative to "emby server". I can easily access the Monitorix web interface from the client PC. That tells me that traffic between client and server is not blocked on the "house LAN".

The fact I got a "black page" from the 'emby server" and not a "disconnect" or other type of error in the web browser tells me that client & server were communicating as requested. The client PC requested "http://ip address:8096" and the server attempted to reply with something. Since the web browser on the both the client and server is the same version of Firefox, albeit one is compiled for 64-bit Windows and the other is compiled for 64-bit Linux, and both browsers can and are running the same Addons, I am inclined to rule out a web browser setup as the problem.

Maybe the secret to solving this is buried in one of the Sqlite databses that comprise some of the parameters of "emby server".

Honestly, I have never seen a webserver-based application act like this ("blank screen" at the client and "good/correct/working" directly on the server) between a locally connected client & server UNLESS (1) a client config error; (2) a server config error; (3) web application error of some type; and (4) network error of some type. I am pretty confident that (1) and (4) are not the "root cause" of this issue since everything they do or can do all works correctly. (2) and (3) are still possible.

March 4, 2018

Hi, have you tried another browser? Are you able to update to a newer Firefox? (52 should be OK, but 58 is the latest).

March 4, 2018

I just finishing trying the same Firefox ESR browser version (52.6.0, 64-bit) on another PC in the house.

This test PC uses an older Intel i3-3240 LGA 1155 CPU, 8GB RAM, Debian 10 "buster" 64-bit, Firefox ESR 52.6.0 64-bit. Using this test PC I was able to open the web interface via port 8096 on the "emby server" using the account that I created. I did verify that both this Linux PC and the Windows PC are using the exact same Firefox addons, even the versions match since I keep them updated, so I would probably rule out my choices in Firefox addons.

By the way, when you install the LXDE desktop on Debian 10 "buster" 64-bit, the Debian install process will install the "firefox-esr" package. I have not encountered nor looked for any other versions of Firefox in Debian's official repositories.

I was able to view "Live TV" on the Linux PC using the EMBY web interface. The broadcast TV feed was supplied from an old Silicondust HDHR3-US device. I could easily select between different channels. When I stopped viewing a channel I could verify that the "tuner" previously being used was released by looking at the front of the HDHR3-US device. I did not watch any channels for an extended period of time, but there were no apparent connection issues during those tests.

Getting "Live TV" from the HDHR3-US device over the LAN to the "emby server" and then on to my "network connected" KODI ("krypton", 17.6) PCs is my ultimate goal. I am trying out EMBY because I had a spare PC on which to run EMBY. That spare PC saves me the cost of buying a new Silicondust box with DLNA built-in to replace a perfectly functioning Silicondust HDHR3-US box that does not have DLNA, and all because KODI developers dropped support for the older Silicondust devices back in version 15 "dot something" before they had a working alternative.

So now this issue has entered the "strange zone". The "emby server" web interface seems to work correctly on a PC with a Linux-based OS, and it refuses to work with a web browser on a Windows 7 PC on the same LAN and in the same IP subnet.

As for changing browsers? That's not going to happen.

The newer versions of Firefox "break" addons that I prefer to use; some developers have not migrated to "the new way" of doing things in Firefox. I find some of the "behaviors" (Mozilla developer choices) in newer versions of Firefox to be unacceptable. So changing to a different version of Firefox is "off the table". If a newer version of Firefox is a requirement of EMBY, then that's definitely a "deal breaker" for me.

I do not trust Google's "Chrome" browser. Enough said there.

The newer versions of Qupzilla do not work with other applications that I use, so I have to use the older 1.89 version. I did try my existing Qupzilla 1.89 browser with the EMBY web interface. I could connect from the Windows 7 machine and obtain the login screen. I signed in with the proper account name and password and there was no further progress from the "emby server". The Qupzilla 1.89 browser stayed stuck on the login screen where you see the big green "Sign In" button. The user credential fields were still filled in. I could press "Sign In" as many times as I wanted and nothing changed. Restarting the Qupzilla browser did not change anything. Windows "task manager" did not show the Qupzilla app was "not responding". So I don't know what was going on there.

I do not trust nor like the "Opera" browser.

I refuse to use any version of MS Internet "Exploder". I do not even have MSIE installed on the Windows 7 PC; removing MSIE was quite a challenge.

Upgrading to or even installing Windows 10 on a PC so I can try out "edge" in this problem is a very strong "no go"; I do not trust nor even like Windows 10, and some of my needed Windows 7 apps appear to be incompatible with Windows 10.

I only have this 1 PC that needs to run, or is even licensed to run, Windows 7 because I have some "Windows only" apps that I need to use and those apps only run on Windows 7.

March 4, 2018

52 seems new enough that it should be fine. Does the browser console show any errors?

March 4, 2018

By the way check this out. I used browserling browser testing service to quickly test the Emby online web app on Windows 7 using Firefox 52. So essentially I am reproducing your exact environment, except no browser add-ons, and no tweaks.

And it worked just fine, no problem found.

March 4, 2018

You can try it here if you like:

https://www.browserling.com/

here is how I set it up.

My guess is you have customized something and potentially blocked a feature that is required. @@Happy2Play you might like this site.

March 4, 2018

I will reply to multiple messages from "Luke" here as this forum does not appear to "thread" messages.

Yes, I have tried another browser (Qupzilla 1.89), and I strongly avoid a few more (Chrome, Edge, Opera). Please scroll around this entire message thread for my detailed comments on that testing.

I will have to try the "browserling" app and let you know what I find out. In my personal experience, anything that does "emulation" is never as good as using the "real thing", but I could be wrong.

There are no errors displayed in the Windows web browser when accessing the "emby server". What I see is: (1) a blank screen that is black when accessing the "emby server" web URL in Firefox ESR 52.6.0 BUT ONLY in Windows not in Linux; or, (2) a frozen login screen after inputting the user credentials and pressing the green "Sign In" button using Qupzilla 1.89. The "emby server" web interface works quite well in Debian 10 "buster" 64-bit Linux using LXDE desktop & Openbox window manager.

As for it being a "browser settings" issue, that is distinctly possible as I tend to run that Windows system in a very strict setup, but I tend to be consistent (habitual?) in my browser setups across the multiple platforms that I have/use. I will have to "diff" the Firefox "prefs.js" files from the Windows and Linux machines for differences.

March 4, 2018

I will have to try the "browserling" app and let you know what I find out. In my personal experience, anything that does "emulation" is never as good as using the "real thing", but I could be wrong.

By the way it's not emulation. It essentially spins up a fresh VM and remote connects you into that VM so that you can control the browser and perform testing with it.

March 4, 2018

The "emby server" name is "nano2".

Looking at Firefox "web console" and only displaying the "JS" output while trying to load the EMBY web app on the Windows system does reveal interesting messages:

"fetchWithTimeout: timed out connecting to url: http://nano2:8096/emby/system/info/public" connectionmanager.js:1:2367
"RequireJS error: Error: Load failed: bower_components/emby-webcomponents/emby-button/emby-button: http://nano2:8096/web/bower_components/emby-webcomponents/emby-button/emby-button.js?v=3.3.0.0. Failed modules: " site.js:1:10393
"RequireJS error: Error: Load failed: bower_components/emby-webcomponents/emby-input/emby-input: http://nano2:8096/web/bower_components/emby-webcomponents/emby-input/emby-input.js?v=3.3.0.0. Failed modules: " site.js:1:10393
app is hidden apphost.js:1:4419
Begin ConnectionManager constructor connectionmanager.js:1:14650
loading ApiClient singleton site.js:1:7973
creating ApiClient singleton site.js:1:8081
"ApiClient serverAddress: http://nano2:8096" apiclient.js:1:2387
ApiClient appName: Emby Mobile apiclient.js:1:2442
ApiClient appVersion: 3.3.0.0 apiclient.js:1:2485
ApiClient deviceName: Firefox apiclient.js:1:2534
ApiClient deviceId: f9f64c3a720183185b754c3b355d1e4ee1a793c7 apiclient.js:1:2583
credentials initialized with: {"Servers":[{"DateLastAccessed":1520202113885,"LastConnectionMode":2,"ManualAddress":"http://nano2:8096"}]} credentials.js:1:179
loaded ApiClient singleton site.js:1:8415
initAfterDependencies promises resolved site.js:2:9784
Using default fonts site.js:2:11306
Loading installed plugins site.js:2:22641
Loading plugin: bower_components/emby-webcomponents/playback/playbackvalidation pluginmanager.js:1:571
Loading plugin: bower_components/emby-webcomponents/playback/playaccessvalidation pluginmanager.js:1:571
Loading plugin: bower_components/emby-webcomponents/playback/experimentalwarnings pluginmanager.js:1:571
Loading plugin: bower_components/emby-webcomponents/htmlaudioplayer/plugin pluginmanager.js:1:571
Loading plugin: bower_components/emby-webcomponents/htmlvideoplayer/plugin pluginmanager.js:1:571
Loading plugin: bower_components/emby-webcomponents/photoplayer/plugin pluginmanager.js:1:571
Loading plugin: bower_components/emby-webcomponents/sessionplayer pluginmanager.js:1:571
Loading plugin: bower_components/emby-webcomponents/youtubeplayer/plugin pluginmanager.js:1:571
app is hidden apphost.js:1:4419
triggering app resume event apphost.js:1:4294

This message simply continues to repat on the web console at this point:

"app is hidden apphost.js:1:4419
triggering app resume event apphost.js:1:4294"

I looked at the "emby server" in the "/opt/emby-server/system/dashboard-ui/bower_components/emby-webcomponents" subdirectory and I did find the files in question.

In Debian, the command "dpkg -L <package name>" can be a good friend.

When I examine the browser's "web console" with the "net" option selected I do see files being downloaded from the server to the client due to the "GET" command:

The "css" option in 'web console" reveals these messages:

Unknown property ‘contain’. Declaration dropped. site.css:1:114
Unknown property ‘user-select’. Declaration dropped. site.css:1:325
Unknown property ‘contain’. Declaration dropped. site.css:1:579

March 4, 2018

Yea i guess the main question is at the beginning why are those files failing to load.

March 4, 2018

More info....

I updated the "nano2" server to your latest Linux x86_64 frile as present on your web site based on the update notification on the "emby server" settings page. No change in this problem.

I did a fresh install on a different server, my mostly idle primary XBMC box. That is an Intel i3-3245 CPU with "QuickSync" support. There is plenty of memory and an addon GPU card with a Nvidia 710 GPU chip. The XBMC server is on the same LAN switch and same IP subnet as the HDHR3-US box.

I was able to complete the entire "emby server" install on my XBMC box via the web interface from another Linux desktop PC. That same Linux desktop PC could easily watch TV from the HDHR3-US box via the EMBY web interface. I repeated that same TV test using the Windows 7 client referenced previously in this thread and there was no difference in the problem. The Windows PC is no more than a "Layer 2 switch hop" away from the XBMC and HDHR3-US devices on a 100 percent Gigabit Ethernet house LAN.

Emby Server Web Interface Not Accessible Over LAN

Recommended Posts

oldguykodi 0

Link to comment

Share on other sites

oldguykodi 0

Link to comment

Share on other sites

Luke 37214

Link to comment

Share on other sites

oldguykodi 0

Link to comment

Share on other sites

Luke 37214

Link to comment

Share on other sites

Luke 37214

Link to comment

Share on other sites

Luke 37214

Link to comment

Share on other sites

oldguykodi 0

Link to comment

Share on other sites

Luke 37214

Link to comment

Share on other sites

oldguykodi 0

Link to comment

Share on other sites

Luke 37214

Link to comment

Share on other sites

oldguykodi 0

Link to comment

Share on other sites

Create an account or sign in to comment

Create an account

Sign in

Activity