Jump to content

Dediseedbox - not connecting to server depending on the client App


Recommended Posts

Posted (edited)

Firstly, hope this is in the right area of the forum. I can only assume Dediseedbox is running on Linux, I'm sure I read it was, but I now cannot find any documentation to back this up!

So I'm running Emby Server on a Dediseedbox as an installable app. Everything setup fine, no problems there.

I can access the server remotely no problem using Emby Theatre on a PC, Linux etc. I can access the server fine from the Android app and IOS app. The problems arise when using the TV apps, although I'm not convinced the TV apps are the problem...

The first thing I'm struggling to understand is Emby Server reports 8096 (http) and 8920 (https) have been opened up and displays the LAN access as xxx.xx.x.xx:8096 and the WAN access as https://xxxxx.dediseedbox.com:8920 - EDIT1: I'm assuming this is correct and they are open on my Dediseedbox server, otherwise why would they have Emby Server as an installable app? Strangely, if I use a port checker tool online, it instantly reports as "Timed Out" and doesn't display as open. So maybe that's a clue to all my problems?

My first confusion is the IP address in the LAN access is a different IP address to that of my actual Dediseedbox. Should it not be the same seeing as Emby is installed on that server? EDIT2: I think it's just clicked in my head why the LAN IP address would still be different even on the Seedbox environment, just as it would be if I installed it at home, as the IP address for my Seedbox will be the public IP address, so that makes sense.

As for the WAN access, https:///xxxxx.dediseedbox.com:8920 - this is accessible from most devices remotely, except not with port 8920. It's only accessible if I use the same port that's displayed in my web browser GUI: 36xxx 

When using the same port as my web browser GUI, I can access my Emby server from virtually any client, but not all. For instance I can use https://xxxxx.dediseedbox.com and web GUI port: 36xxx absolutely fine remotely from Emby Theatre on PC, Linux, as well as Android and IOS apps. A friend of mine can also access it from their TV app and it works fine. Another friend of mine can't - they just get unable connect to the server error. I have tried it on my TV app - an LG TV. The first time I tried I already had an old Emby server connected with my TV, when I clicked "change server" and added the new details in, it connected fine. When I removed the old server and connected to my new server that way with the same details, it says it was unable to connect to the server. (???)

So as you can see, I'm having trouble diagnosing what the possible problem could be, as there's not a clear pattern to work with. At first I thought it was the SSL certs - but seeing as it works on my TV when I click "change server" with an old server already present, but not when I have deleted the old server - as if to start the app from fresh, it makes little sense.

If anyone can give me any ideas or help on this it would be greatly appreciated as I just cannot figure out what's going on.

Edited by thenoog85
Posted

Emby server has two separate port settings in the network setup. The local http/https port number settings are what the server is actually binding on the host network interface, defaults are 8096/8920. The public http/https port number settings are what might be mapped from WAN to LAN and the server will advertise to client apps. It sounds like your hosted server has WAN port 36xxx mapped to LAN port 8920. If this is the case then update and save the public https port to the 36xxx value.

 

Posted (edited)
16 minutes ago, Q-Droid said:

Emby server has two separate port settings in the network setup. The local http/https port number settings are what the server is actually binding on the host network interface, defaults are 8096/8920. The public http/https port number settings are what might be mapped from WAN to LAN and the server will advertise to client apps. It sounds like your hosted server has WAN port 36xxx mapped to LAN port 8920. If this is the case then update and save the public https port to the 36xxx value.

 

That sounds right. Thank you very much. I shall try this tomorrow and report back. I'm just curious though, if this is the case would it be "normal" that some clients can already connect with the host URL domain and the port 36xxx without me mapping the public port to the local port already? Shouldn't it just simply not work for everyone with the way it's currently setup?

Just trying to understand... Thanks again!

Edited by thenoog85
Posted

The port is already mapped on the network. The changes you are making are what Emby advertises to client apps, it is not detected by the server. I don't know how every app works but many query the server for this info even after you connect manually. It's possible they try to use the details fetched from the server and why they need to be correct.

 

Posted

I see. Thank you, much appreciated. I'll see if this fixes the issue and report back on here. I've ran Emby Server before from a local NAS and I've always been able to work the port mapping issues out. For some reason since I've moved it to a remote server it's not making the same sense in my head, but what you have said seems like an obvious thing to try now. 

Posted

Just to clarify, once making this change in the Emby Server settings, the correct details for clients to be able to connect to the server would be host: https:///xxxxx.dediseedbox.com and port: 36xxx still wouldn't they? As 36xxx would be recognised by Emby and pointing to the local port on the server?

I've just been looking through the support pages on Dediseedbox and there's very little support on this that I can find. It's only now it's occurred to me from what you have said that it makes any sense to me - mainly because it's been working fine on some client apps as it is.

Posted

As I understood it your clients are working on port 36xxx. So you're not changing how clients connect to your server, you're making sure the server sends the right details.

Did you choose port 36xxx or did the hosting company do that for you? How did you discover that port 36xxx was the right one?

 

 

Posted

I came across port 36xxx as that is the port in the URL of the web browser that gives me access to Emby Server. For example I'll access my Emby Server by going to the URL: https://xxxxx.dediseedbox.com:36xxx/web/index.html 

Once logged in, Emby Server tells me the LAN access is http://xxx.xx.x.xx:8096 and the WAN access is https://xxxxx.dediseedbox.com:8920 - However I cannot access remotely with the WAN access details from anywhere. If I replace 8920 with 36xxx (from the URL displayed on my web browser for accessing Emby Server) then I do get access remotely, but not from every client. TV's being the biggest issue it seems. 

Posted

To conclude all my testing so far. With the below details

host: https://xxxxx.dediseedbox.com
port: 36xxx

I CAN login remotely from: Win PC, Linux PC, Android Mobile, Tablets, Firestick

But I CANT login from certain TV apps, but the mystery here is I've been both able to login from one of these TV apps absolutely fine (but only when there was already an old Emby server already present on the login screen, so I clicked "change server", put the above details in and I was straight in). Now that I have removed the old server (I no longer use it), effectively starting the app from fresh, if I put the above details in to add a new server, it won't connect.

I've done testing with other people to see what they get when they try to access with the above details. 1 person could get straight in using their Emby TV app, another person gets connection failed. Another person, like me has had both scenarios. Connected fine using the "change server" button when already having another Emby server connected on their app, but once they have removed that server and then tried to add a new one from fresh. Connection failed. The error is instant as well - almost like the app has said no before even attempting the connection. But that's just an assumption - I don't really know!

Posted

Is this latest testing after you change the Network -> Public https port number in the Emby settings?

 

Posted
7 minutes ago, Q-Droid said:

Is this latest testing after you change the Network -> Public https port number in the Emby settings?

I've tried it with and without now - exact same outcome. Very odd. I've also found a second Firestick for testing with. Same problem on that. Simply doesn't connect with the above details. Use a different Firestick, connects straight away. Both of these are on the same Wifi network, so I can't see a problem

The testing I've done with the LG TV app is the most odd to me. I've got another Emby Server I can connect to - it will connect to that fine. So then if I click "change server" and add the above details in for the new server, it connects. If I delete the old server (or simply delete the app and reinstall the app) and just try to add this new server with the details above - no can do! Won't connect. I can't fathom what could be causing that at all.

Posted

That's odd. You could attach the emby server log for review and might have to send a client app log to the devs.

The support team can also arrange a remote session if you're open to that.

 

Posted (edited)
25 minutes ago, Q-Droid said:

That's odd. You could attach the emby server log for review and might have to send a client app log to the devs.

The support team can also arrange a remote session if you're open to that.

 

Thank you very much for all your help, I will consider that. 

Just done another bit of testing on all the devices that I can't currently connect on. If I use a webbrowser on those devices and go directly to https://xxxxx.dediseedbox.com:36xxx  it takes me straight to the Emby Server login page no problem. I'm not really sure what that proves, if anything. Only that the devices in question are capable of finding the server with the correct details, but not through the Emby app for some reason.

Edited by thenoog85
Posted

What is the ssl certificate? LG is probably rejecting it.

Posted (edited)

It's a Lets Encrypt one according to Dediseedbox. The strange this is, I have actually connected to this server with the LG TV once yesterday with the exact same server details, however, that was a freak event it seems as I cannot get it to connect since.

Also, I can access the server through a web browser on the TV. In fact I can access it through a web browser on any device. I'm also fine accessing it through the proper Emby app on most devices, just not on particular Firesticks and particular TV's.

Edit: I've also tried changing the name of the LG tv in the tv settings as I did read that special characters could cause connectivity issues, so I renamed it to simply "lgtv", restarted the TV and even restarted the router the TV is connected to just to be sure, but no joy there either. It wouldn't be bugging me so much if it didn't connect at all, but it connected fine yesterday. The only thing I changed was removing an old connection on the app that was linked to another Emby server instance I used to run. Ever since doing that, it wont connect.

Could it be because i've moved my Emby Premiere key over from one Emby Server install to another? That's the only other thing I can think of.

Thank you.

Edited by thenoog85
Posted

I'm adding some screenshots to try and make it a bit clearer. So Dediseedbox gave me this URL to access my Emby Server install from a browser. I've blanked out any particularly sensitive info, but this is where I first come across this 36xxx port number. I assume this is the public https port which is mapped to 8920 on their end.

417231675_Screenshotfrom2021-08-1516-43-58.png.d4105ff14be61df575c5d56bab9d0683.png

This is how my dashboard looks. The LAN IP address supplied is different from the IP address I was supplied by Dediseedbox to access my content. Is that normal? I assume so, because the IP address they have given me to access my content is a public one, but Emby is seeing the local one assigned where Dediseedbox has been installed?

Secondly, the WAN port number is showing as 36xxx only because I have made that change in the settings from the default of 8920 which you can see in the third photo below.

dashboard.png.486c78eb6955b9884db4ddce6e87b1d2.png

Here you can see the change I've made in the public https. However, even when left as 8920 I'm getting exactly the same problem.

network.thumb.png.fcbfcd4e8e610418c4006086a81b5f45.png

These settings can't be far wrong if I'm able to connect from some devices and not others. Am I to assume this will be an SSL issue at this stage or is there something I'm definitely doing wrong from what you can see? I can only assume local port 8920 is open/forwarded at Dediseedbox's end seeing as I can connect from some devices.

If I use a port checker tool online with the domain https://xxxxx.dediseedbox.com and port 36xxx it reports it as opened. If i replace 36xxx with either 8920 or 8096 it reports "blocked". Not sure if that's any indication. It looks like the only public port they have opened for me is 36xxx.

Posted

It has nothing to do with emby premiere. What you could try for testing is connecting via plain http and see how that compares.

Posted (edited)

Unfortunately it looks like http is a no go as well. I can't seem to connect over http from any device. I think the issue I've got is the port 36xxx that Dediseedbox have given me is mapped to their https port of 8920 and that's the only means I seem to have of connecting. Even trying to visit the Emby server itself through a browser over http isn't happening.

I never used to have any such troubles accessing Emby remotely when I ran the Emby server from my own home, but since I've moved to a remote server it's caused these issues. Much easier to diagnose when I'm in charge of the actual router the server is connected on I guess. 

Just seems strange how I'm connecting fine from any desktop, but not from a couple of TV's and a couple of Firesticks.

Is it likely the Lets Encrypt SSL would be causing the issue? (even though using a web browser on any of these devices allows me to connect, just not happening with the Emby app). If not then I might have to see if Dediseedbox can provide a little more insight into how they are routing connections. 

Edited by thenoog85
Posted (edited)

I've just had confirmation from Dediseedbox that they route the connections as follows:

Quote

 

"Emby runs on an internal IP address over port 8920 which is then routed to the public IP address and port.

172.xx.x.xx:8920 > nxxxx.dediseedbox.com:36xxx"

 

So not learnt a great deal there other than what I already assumed. 

Are there any particular logs I could send that would be of any benefit to working out what the issue is? I'm assuming a log from the Emby client app that's causing the issue is going to be of the most benefit as I'm not even sure the Server is being contacted.

I can see how I obtain the server logs, but I'm not too sure how to obtain any Emby client logs, but i'll look into it if it's going to be helpful.

One other idea I had: I have a domain of my own that's got SSL, I could temporarily forward that domain to my Dediseedbox IP and see what happens when using that. If I forward it to the IP as opposed to the URL, it should only be using my own SSL. I'm not that up on how SSL works, so it's just an out there idea.

Thank you

Edited by thenoog85
Posted (edited)

With Dediseebox controlling everything from the public entry point to Emby server deployment that looks like Docker and even provisioning your certs it's hard to dig deeper without access to their side and yours. Even then there's likely other stuff that's hidden and not documented like their reverse proxy.

So yeah, I think logs from the clients with debug for working and non-working connections might be your best bet.

Pointing your personal domain to their public IP is something I don't expect to work if they're using a proxy with subdomains and SNI (again, the unknowns). You can always test it.

 

 

Edited by Q-Droid
Posted (edited)
24 minutes ago, Q-Droid said:

With Dediseebox controlling everything from the public entry point to Emby server deployment that looks like Docker and even provisioning your certs it's hard to dig deeper without access to their side and yours. Even then there's likely other stuff that's hidden and not documented like their reverse proxy.

Yes I think you are right. Their documentation is very poor at best anyway with regards to Emby. They tell you how to install it (which is pretty self explanatory anyway) and then provide no information after that. I wouldn't have even known the public port in use for https if I didn't happen to notice it in the URL.

The have now supplied me with the public port that points to http (or local port 8096). I've tried it on the TV app and guess what? It connects! But here's the next strange scenario: Once connected it's so slow it's unusable. I mean so slow that the app cannot even load the images up for any films in any normal time frame. I attempted to play a film and it crashed the app doing so.  Also find it a little strange that I have had to ask them for the public port thats pointing to their plain http. Almost like it was something they didn't really want me to know?!

Is there any legit reason though you can think of why http would run so slow compared to https? 

I'm only signed up with Dediseedbox on a monthly basis, so I might do a bit of research and see if there are any better providers in terms of Seedboxes going forward. It's a shame, because as a Seedbox it works really well and good value, but it's not looking so good with Emby and probably going to be a similar situation regarding any of their other installable apps when it comes to ports etc.

Thanks for all the help so far. I'm determined to get to the bottom of this just for my sanity now 😀

Edited by thenoog85
Posted

There shouldn't be a performance difference between http and https. Make sure your tests are like-for-like using the same client app or browser. Also verify the Emby network public http port value to make sure it's correct.

 

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...