Ping to Emby not working

[mregni]

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

[mregni]

@Ribesg, can you add your log file on the issue. It seems that EmbyStat can't find your Emby server with the given url.

[Ribesg]

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.

[Ribesg]

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

[mregni]

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.

[Ribesg]

That's better!

[Ribesg]

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

[mregni]

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?

[Ribesg]

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 :)

[mregni]

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.

[Ribesg]

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";
    }

[Ribesg]

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 :|

[mregni]

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.

2019-08-23.log

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.

[Ribesg]

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

[mregni]

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.

[Ribesg]

That's all I got

[ArthurKnoep]

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
}

[mregni]

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 :)

[mregni]

@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

[Ribesg]

No change for me, tried the beta and nightly

[mregni]

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.

[Ribesg]

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

[wjbeckett]

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.

[mregni]

@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.

[mregni]

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.

[wjbeckett]

@mregni unfortunately it's not the issue for me. I do not use a baseURL in my Jellyfin instance.

[mregni]

To bad, I'll have to setup my own testing env then to fix the Nginx problems