Trouble with Emby Connect and/or libraries

[andybundy 0]

Firstly, before we all get confused over wording, assume the following:
An Emby Server refers to the emby software running on a host.  This server software resides with its own configuration data, including user database and horrendous quantities of metadata and cached images.

A host refers to the facilities upon which the server runs.  Our world is no longer simple enough that we can easily state that one server application runs on one operating system on a single hardware machine.  I currently run multiple server applications within Docker, running on a virtualised Debian Buster image, on VMWARE, all sitting on a HP ML350P server.  None of this really matters.  Much.

Suffice it to say, I have two instances of Emby. 

One runs as described above, using the official Emby image, with the aforementioned humongous pile of metadata and image caches residing in a persistent filesystem folder structure.  Over the past weeks I have resolved and eliminated each and every folder and permission related problem.

The second is running on my Terramaster F5-421 NAS which runs a form of Linux (possibly a customised Centos/Fedora variant, I know not what).

All of my media is currently stored on the above Terramaster NAS.

I have three users, all with Emby Connect user-ids, all created identically on both servers.  All boxes have been ticked, confirmed, and filled, according to the knowledgebase guidance.

My users run Emby on a variety of devices, including three Android 10 mobile phones, a Kindle Fire 10" HD tablet, and two LG smart tvs.  One is WebOS, the older one an older smart system.  Both have native Emby apps running upon them.  We also use Emby on a Roku Express device.

Problems:

1.  The app experience, which seems consistent across multiple devices is that server instances, as connected to via Emby connect, can, and do, appear multiple times, and with the same names.  In the case of one, it is impossible to remove. 

2.  Out of our three users (I am one of these), invariably only one of the 'server' instances actually provides for a working connection.  There is no consistency between users and devices.

3.  Frequently, once logged into a server, one or more users will be faced with Libraries which are apparently empty of media..

4.  When this happens, if I connect to the individual server using Firefox/Chrome, AND login with my Emby Connect, I reach the same screen and find the libraries packed with media.

Normally I would find it a challenge to learn how the software works and to figure the problem out for myself.  However, there is absolutely no documentation in the knowledgebase which explains the relationship between Emby Servers, Emby Connect, individual APPS, and what is seen, ought to be seen, and should be seen.

I cannot actually work out where each user actually receives the connection information for the servers to which they are permitted access, because my experience is that this seems to vary between devices, even when the Emby APP has been manually shut down, memory cleared, and restarted (to use the Android approach to resetting an app).

I appreciate this is long - but I had to clearly describe the problem, and provide the symptoms without the aid of any log entries or error messages.

Thanks in advance

 

 

Following the instructions in the Knowledge base I have created identically named users for each of my family on each server, referencing their respective Emby Connect userids which are, naturally, their email addresses.  I have then registered each Connect account with the two servers, and each user has confirmed their acceptance of the respective invitations from the servers.

@cayars

[Carlo 4561]

OK a couple questions for you just to make sure your servers aren't tripping over each other.

Did you give different names to each Emby Server?

Did you open separate ports for each Emby Server so it's visible remotely?

Example port 8096 forwards to Emby1 server on port 8096, while port 8097 forwards to Emby2 server on port 8096 but has port 8097 set in the network settings?

The above is tricky if you don't understand port forward the "Emby way". 

So I just want to verify we have a good base setup first.

Carlo

[andybundy 0]

OK. I don't port-forward in the traditional way as for most of my apps, which are containerised, I use traefik reverse proxy, which allows me to use an https connection to my own domain, as described on 'smart home beginner.com'. Traefik then takes the apparently incoming connection, and maps it to port 8096 on my app server.
The only ports forwarded are 80 and 443.

The second server is outside of this, and local devices connect, or seem to, directly. I will confess I've not found much detail on the connectivity of emby, nor have I done much packet analysis. In my defence with no knowledge as to how it should work, I cannot start to see if, or where, it might fail.

Can you point me at any description of the connections both internal, and external, using 'connect', with internal servers and clients?

Thanks

 

[Carlo 4561]

This knowledge base article covers the basics and has some diagnostic testing info as well.

https://support.emby.media/support/solutions/articles/44001849007-connectivity

 

I've got ZERO experience with "smart home beginner.com" Traefik so I'll say that upfront but do run my own Emby server through a CDN proxy.  I also remap the ports to 80 & 443 as well.

Let me share a couple of things that might trip you up and important to understand.  This will ignore a proxy and only be for a standard setup with a home router and a Emby Server running inside the LAN.

First important to understand that in a basic setup EMBY always listens on two ports which are 8096 (non SSL) and 8920 (SSL). These are the ports used to connect to your server from inside your LAN.

When you setup port forwarding on your router you will pick 2 ports to use.  We'll use port 80 and 443 as examples and we'll assume your server is setup with a static IP of 10.0.0.100.

You will setup a port forward in your router for port 80 inbound sent to IP 10.0.0.100 going to port 8096 for TCP.

You will setup a port forward in your router for port 443 inbound sent to IP 10.0.0.100 going to port 8920 for TCP.

Now on the Emby server you go to NETWORK menu, scroll down until you get to remote setting and will configure them as such:

The key to understanding this is that the ports setup in Emby are the ports you configure in your router.  Emby will still be using 8096/8920 internally.  When requests come in from remote addresses the URLS get written with the router ports.

That can be a bit confusing but I thought I'd explain that a bit more because it will help you when you setup the proxy.

Of course if you only allow SSL connections to your Emby server then you can skip setting up a port forward for port 80 as it won't be used or needed.

We an assist with any questions you might have if not clear.

Carlo

Edited July 27, 2020 by cayars

[Luke 42077]

@andybundy has this helped?

[andybundy 0]

So far, so good. This is all quite logical, with no surprises at all. Indeed I'm quite comfortable with port forwarding, re-mapping of ports, even CDN stuff now, as I was 'brought up' in a mixed networking and mid-range server environment from earlier jobs with US network companies.
My problems lie somewhere in the middle of all these bits - and could be totally unrelated.

Where I struggle is with the original question of how Emby connect interacts with the App on our devices, and stores server information, connectivity info, and links the two. Consistently we have a 'dead' entry that won't delete, for example.

Secondly, we are almost always using Emby internally with clients and servers on the same subnet. How does the connectivity with emby connect work there?

I'm sorry that it seems I've over-complicated my setup - but much of it is 'extra' as we've used IP addressing, still, in most cases for connections, and in the docker-hosted instance, the emby listening ports are still exposed. I'll check further with what's been posted.

Thanks!!

 

[Luke 42077]

Thanks for the feedback.