EmbyStat
EmbyStat copied to clipboard
mregni
Ping to Emby not working
I just tried the current nightly and the bug where EmbyStat calls itself instead of the Emby instance is still here, when do you plan to fix it?
Originally posted by @Ribesg in https://github.com/mregni/EmbyStat/issues/721#issuecomment-523017726
@Ribesg, can you add your log file on the issue. It seems that EmbyStat can't find your Emby server with the given url.
I have absolutely no log to provide because no file is being created in any of the mounted directories I have, and docker logs -f embystats just shows this:
Hosting environment: Production
Content root path: /app
Now listening on: http://[::]:6555
Application started. Press Ctrl+C to shut down.
Here's the script I use to create the docker container:
#!/bin/bash
IMAGE="uping/embystat:nightly-ubuntu-x64"
docker pull $IMAGE
docker create \
--name=embystats \
--volume /home/embystats/Logs:/app/Logs \
--volume /home/embystats/Database:/app/Database \
--volume /home/embystats/Settings:/app/Settings \
--publish 1341:6555 \
--env UID=1005 \
--env GID=1005 \
--env PUID=1005 \
--env PGID=1005 \
--restart unless-stopped \
$IMAGE
Oke cool! You don't need the 3 volumes anymore, I moved everything inside the /app/config folder. So the only one you need is --volume /home/embystats/config:/app/config
After that, check in the logs folder for an exception when you try the wizard again. Hopefully, this will work. If you get a file not found exception on nlog.config that means that the nightly build failed with the new changes so I have to check that one as well when I'm home.
I don't see anything specific in the log file:
2019-08-20 14:50:05.4665 [INFO] SYSTEM Booting up server on port 6555
2019-08-20 14:50:06.2417 [INFO] Starting Hangfire Server using job storage: 'Hangfire.MemoryStorage.MemoryStorage'
2019-08-20 14:50:06.2459 [INFO] Using the following options for Hangfire Server:
Worker count: 1
Listening queues: 'main'
Shutdown timeout: 1.00:00:00
Schedule polling interval: 00:00:05
2019-08-20 14:50:06.3856 [INFO] Server main server:1:b93a5a38 successfully announced in 119.8018 ms
2019-08-20 14:50:06.3898 [INFO] Server main server:1:b93a5a38 is starting the registered dispatchers: ServerWatchdog, ServerJobCancellationWatcher, ExpirationManager, CountersAggregator, Worker, DelayedJobScheduler, RecurringJobScheduler...
2019-08-20 14:50:06.3898 [INFO] Server main server:1:b93a5a38 all the dispatchers started
2019-08-20 14:50:17.3597 [INFO] SERVER-API Starting wizard for user.
2019-08-20 14:51:15.1629 [INFO] SERVER-API Starting wizard for user.
2019-08-20 14:51:15.1671 [INFO] SERVER-API Starting wizard for user.
2019-08-20 14:51:15.1774 [INFO] SERVER-API Starting wizard for user.
I still receive a 400. I looked at the request and it just contains the url.
Please note that my Emby instance is behind nginx, so technically my exposed port is 443, maybe that's a problem? The url sent in that request is https://MyEmbyUrl:443
Yeah, that might be the problem. Some other users mentioned that before I think.
I have to add some header to the requests for it to work on nginx it seems => https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-2.2
I'll create a docker image with the headers. When it's ready, can you test it for me before I push it to the nightly build?
Well if I can pull it directly with docker, or if you tell me how to use a downloaded image directly, sure. I don't know much about docker :)
I justed updated the nightly-ubuntu-x64 image. Can you retry fetching the container and run the image on nginx? Be sure that your host is not using a cached image put really pulls the new image from the docker hub.
Just tried. nightly-ubuntu-x64, sha256:ad5ec6f28cd232fb1d5a98144bad4fefbddc7788060b2c712dcf017149562395.
No change. Here is my nginx configuration, maybe I'm missing something?
location / {
proxy_pass http://localhost:1341;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
Is there a way to enable more logging? To know why it returns a 400? Did it even try to contact my Emby instance at all? I tried to find the associated code but I really don't know anything about the MS world of development, I'm a Java/Kotlin/Swift guy :|
Can you try again with the latest nightly? sha256:7428b2b8398375a07e0543a481616fb7632595e3426e50b1bc8c742325e777a2 (I think, not sure)
As for the logs you supplied, they don't really look complete. I include my logs after finishing the wizard. There should be an INFO log mentioning the start of a ping call.
EDIT: At the moment there is no extra logging no, so I hope you can see something more in the log files. I never used Nginx myself, I just added some forward headers like it was mentioned in the documentation. Not sure if I missed something.
Updated to latest:
Digest: sha256:3168812c4e0f2ad37f53f769c28f3059aa20d439ce8b14c7e0f09cd772ae931b
Status: Downloaded newer image for uping/embystat:nightly-ubuntu-x64
Still no change, here's my log file content:
➜ logs cat 2019-08-23.log
2019-08-23 17:27:19.0646 [INFO] SYSTEM Booting up server on port 6555
2019-08-23 17:27:19.8725 [INFO] Starting Hangfire Server using job storage: 'Hangfire.MemoryStorage.MemoryStorage'
2019-08-23 17:27:19.8767 [INFO] Using the following options for Hangfire Server:
Worker count: 1
Listening queues: 'main'
Shutdown timeout: 1.00:00:00
Schedule polling interval: 00:00:05
2019-08-23 17:27:20.0210 [INFO] Server main server:1:49090158 successfully announced in 123.7417 ms
2019-08-23 17:27:20.0252 [INFO] Server main server:1:49090158 is starting the registered dispatchers: ServerWatchdog, ServerJobCancellationWatcher, ExpirationManager, CountersAggregator, Worker, DelayedJobScheduler, RecurringJobScheduler...
2019-08-23 17:27:20.0252 [INFO] Server main server:1:49090158 all the dispatchers started
2019-08-23 17:28:08.9439 [INFO] SERVER-API Starting wizard for user.
2019-08-23 17:28:08.9439 [INFO] SERVER-API Starting wizard for user.
2019-08-23 17:28:08.9439 [INFO] SERVER-API Starting wizard for user.
2019-08-23 17:30:05.0857 [WARN] PINGEMBYSERVER-JOB Job not running because wizard is not finished
Something's wrong even before it pings my Emby instance I suppose
Looks like it yes, mmmm Can you see something in your console window in Chrome about the 500 status code returned? Maybe that can give me a better clue about what is going on.
I have the same problem.
On my architecture I have two servers on my local network (one gateway and one that hold emby and embystat). If I access embystat using the gateway (nginx) I get the 400 Bad Request on ping but if I access embystat directly using the ip of the backend server it works as expected.
Here is my nginx vhost config:
server {
server_name stats.emby.<host>.eu;
location / {
# Reverse Proxy
include proxy_params;
proxy_pass http://<internal backend ip>:6555;
# Websocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
access_log /var/log/nginx/stats.emby.<host>.eu.access.log;
error_log /var/log/nginx/stats.emby.<host>.eu.error.log;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/stats.emby.<host>.eu/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/stats.emby.<host>.eu/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = stats.emby.<host>.eu) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name stats.emby.<host>.eu;
listen 80;
return 404; # managed by Certbot
}
Means that there is still something wrong with the reverse proxy headers in EmbyStat. I have no idea how to fix this for the moment but still looking into this issue :)
@ArthurKnoep, can you try again with the beta.11 version? I added some Nginx support and for someone on the Emby forum it's working now. Fingers crossed it's working for everyone who is using Nginx :D
Maybe you can have a look at the Nginx config darkassassi007 posted here => https://emby.media/community/index.php?/topic/56640-developing-a-standalone-embystat-server/?p=789198 He got his setup running on Nginx.
Let's hope we missed something in your config :) Btw, make sure you are running beta.12 (released a few hours ago) If it's still not working on your system I'll try to set up an Nginx configuration myself.
Well I'm just always using the docker tags so I used whatever was behind the beta and nightly tags 2 hours ago :)
There is a lot of configuration to decipher in this link... This also looks like the global nginx configuration, I never touched it, only added the host configurations in site-available and symlinks in site-enabled
Having the same issue however on Jellyfin. I have also tried to use the local address of the Jellyfin server direct to IP:8096 and still getting the error.
@wjbeckett, at the moment this will not work on Jellyfin because the Ping message expects an "Emby server" string response while Jellyfin just returns an empty 200 HTTP status.
As for Nginx, I still couldn't get around to test it myself but I will try to make some time later on to fix this issue.
Someone just posted something interesting (@alkalinelito) in issue #1080. He stated in his last message (https://github.com/mregni/EmbyStat/issues/1080#issuecomment-613785027) that the ping was not working because he is using a base url on his server. Is that the case for you as well @wjbeckett?
If so, it maybe be a good idea to add an extra input field in the wizard so people with a base url can supply it.
@mregni unfortunately it's not the issue for me. I do not use a baseURL in my Jellyfin instance.
To bad, I'll have to setup my own testing env then to fix the Nginx problems