docker-filebot icon indicating copy to clipboard operation
docker-filebot copied to clipboard

2 issues

Open YouveGotMeowxy opened this issue 3 years ago • 9 comments

I just installed and played around with it and noticed some things:

  • the UI is very laggy and slow/ I don't even mean doing the actual rename, but just using the UI itself.
  • After a fairly short time, it disappears, and just leaves a blank screen. I've tried adding the "keep running" environment var (I forget what it actually is off the top of my head) but that didn't do anything:

image

Is therea way to fix these?

here's my compose:

version: "3.6"

services:

      filebot:
        image: jlesage/filebot:latest
        hostname: filebot
        environment:
          - TZ=America/Chicago
          - USER_ID=1000
          - GROUP_ID=1000
        volumes:
          - /opt/docker/configs/FileBot:/config:rw
          - /mnt/h/FileBot:/storage:rw              # Storage
          - /mnt/h/FileBot/input:/watch:rw          # AMC Script watch folder
          - /mnt/h/FileBot/output:/output:rw        # AMC Script output folder
          - /etc/localtime:/etc/localtime:ro
        deploy:
            mode: replicated
            replicas: 1
            resources:
              limits:
                memory: 300M
            restart_policy:
              condition: any
        networks:
          - ocm

networks:
  ocm:
    external: true
    name: o-misc

YouveGotMeowxy avatar Mar 20 '21 21:03 YouveGotMeowxy

The issue you shown with the screenshot is often fixed by clearing the browser's cache. You can also try using a private/incognito window to eliminate any caching issue.

For the slow UI, does it look like a network issue ? Do you see the same behaviour when using different machines to access the UI ?

jlesage avatar Mar 22 '21 01:03 jlesage

@jlesage

The issue you shown with the screenshot is often fixed by clearing the browser's cache. You can also try using a private/incognito window to eliminate any caching issue.

For the slow UI, does it look like a network issue ? Do you see the same behaviour when using different machines to access the UI ?

I just tested on an incognito window and it still happened

image

The slow UI, I don't think is a network issue. All of my other tabs and containers run at normal speed.

YouveGotMeowxy avatar Mar 22 '21 15:03 YouveGotMeowxy

What is the message displayed when you put your cursor over the read X ? Does the container stay up and running or it shutdown itself and restart?

Can you give more details about how you access the UI? Are you accessing from the same LAN as the host ? Did you try to setup the container with the default bridge network ?

Note that under the hood, UI is transferred with the VNC protocol. This is more heavy to transfer and process than a normal web page.

jlesage avatar Mar 22 '21 17:03 jlesage

What is the message displayed when you put your cursor over the read X ? Does the container stay up and running or it shutdown itself and restart?

Can you give more details about how you access the UI? Are you accessing from the same LAN as the host ? Did you try to setup the container with the default bridge network ?

Note that under the hood, UI is transferred with the VNC protocol. This is more heavy to transfer and process than a normal web page.

@jlesage Ty for helping out.

It shows this:

image

And the container log shows this:

today at 1:46 PM  22/03/2021 13:46:48 Got connection from client 127.0.0.1
today at 1:46 PM  22/03/2021 13:46:48   other clients:
today at 1:46 PM  22/03/2021 13:46:48 Got 'ws' WebSockets handshake
today at 1:46 PM  22/03/2021 13:46:48 Got protocol: binary
today at 1:46 PM  22/03/2021 13:46:48   - webSocketsHandshake: using binary/raw encoding
today at 1:46 PM  22/03/2021 13:46:48   - WebSockets client version hybi-13
today at 1:46 PM  22/03/2021 13:46:48 Disabled X server key autorepeat.
today at 1:46 PM  22/03/2021 13:46:48   to force back on run: 'xset r on' (3 times)
today at 1:46 PM  22/03/2021 13:46:48 incr accepted_client=4 for 127.0.0.1:56900  sock=10
today at 1:46 PM  22/03/2021 13:46:48 Client Protocol Version 3.8
today at 1:46 PM  22/03/2021 13:46:48 Protocol version sent 3.8, using 3.8
today at 1:46 PM  22/03/2021 13:46:48 rfbProcessClientSecurityType: executing handler for type 1
today at 1:46 PM  22/03/2021 13:46:48 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8
today at 1:46 PM  22/03/2021 13:46:48 Pixel format for client 127.0.0.1:
today at 1:46 PM  22/03/2021 13:46:48   32 bpp, depth 24, little endian
today at 1:46 PM  22/03/2021 13:46:48   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
today at 1:46 PM  22/03/2021 13:46:48 no translation needed
today at 1:46 PM  22/03/2021 13:46:48 Enabling NewFBSize protocol extension for client 127.0.0.1
today at 1:46 PM  22/03/2021 13:46:48 Enabling full-color cursor updates for client 127.0.0.1
today at 1:46 PM  22/03/2021 13:46:48 Using image quality level 6 for client 127.0.0.1
today at 1:46 PM  22/03/2021 13:46:48 Using JPEG subsampling 0, Q79 for client 127.0.0.1
today at 1:46 PM  22/03/2021 13:46:48 Using compression level 9 for client 127.0.0.1
today at 1:46 PM  22/03/2021 13:46:48 Enabling LastRect protocol extension for client 127.0.0.1
today at 1:46 PM  22/03/2021 13:46:48 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFECC)
today at 1:46 PM  22/03/2021 13:46:48 Using tight encoding for client 127.0.0.1
today at 1:46 PM  22/03/2021 13:46:52 client_set_net: 127.0.0.1  0.0057
today at 1:46 PM  22/03/2021 13:46:52 active keyboard: turning X autorepeat off.
today at 1:46 PM  22/03/2021 13:46:52 created   xdamage object: 0x400030
today at 1:51 PM  22/03/2021 13:51:52 idle keyboard:   turning X autorepeat back on.
today at 1:51 PM  22/03/2021 13:51:52 idle keyboard:   turning X autorepeat back on.
today at 1:51 PM  22/03/2021 13:51:52 idle keyboard:   turning X autorepeat back on.
  • The container itself stays running the whole time.
  • It is all on the same LAN. I have docker running on one machine with that container, behind nginx (LinuxServer's Swag) and then access the filebot app from a different machine on the same LAN.
  • I use an overlay network due to using docker swarm, but I constrain it to just the one machine that docker is running on.

Here's the Nginx config I use:

## Version 2021/01/16
# filebot does not require a base url setting

location /filebot {
    return 301 $scheme://$host/filebot/;
}

location ^~ /filebot/ {

    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;
    set $upstream_app filebot;
    set $upstream_port 5800;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    rewrite /filebot(.*) $1 break;
}

and the compose:

version: "3.6"

services:

      filebot:
        image: jlesage/filebot:latest
        hostname: filebot
        environment:
          - TZ=America/Chicago
          - USER_ID=1000
          - GROUP_ID=1000
        volumes:
          - /opt/docker/configs/FileBot:/config:rw
          - /mnt/h/FileBot:/storage:rw
          - /mnt/h/FileBot/input:/watch:rw 
          - /mnt/h/FileBot/output:/output:rw
        deploy:
            mode: replicated
            replicas: 1
            placement:
              constraints:
                - node.labels.Main == true
            resources:
              limits:
                memory: 300M
            restart_policy:
              condition: any
        networks:
          - ocm

networks:
  ocm:
    external: true
    name: misc

YouveGotMeowxy avatar Mar 22 '21 19:03 YouveGotMeowxy

I suspect that the reverse proxy might be the cause of the issue. I don't have all the includes of the nginx config, but is it configured to support WebSocket? See https://github.com/jlesage/docker-filebot#routing-based-on-hostname for reference.

Is it possible for you to try to bypass the reverse proxy to access the container?

jlesage avatar Mar 22 '21 22:03 jlesage

@jlesage I'm not sure why, but whenever I try to use one of your containers and directly try to go to the port and IP of the container it just times out, but when using a reverse proxy it loads.

Reagrding the websockets, a quick question: does it make a difference if the websockify block is actually nested inside the other block? Or canit be separate, like this?

location ^~ /filebot/ {

    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;
    set $upstream_app filebot;
    set $upstream_port 5800;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    rewrite /filebot(.*) $1 break;
}

location ^~ /filebot/websockify {
    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;
    set $upstream_app filebot;
    set $upstream_port 5800;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port/websockify/;

    rewrite /filebot(.*) $1 break;
}

YouveGotMeowxy avatar Mar 23 '21 15:03 YouveGotMeowxy

Oh, also another quick question. While trying to get this working I also tried adding my opensubtitles name and pw env vars, but I used a secret for the pw, and when I did the container would kill itself, but if I just use the pw without being a secret, it stays running. Is there something that needs to be done to get it to support secrets?

version: "3.6"

services:

      filebot:
        image: jlesage/filebot:latest
        hostname: filebot
        environment:
          - TZ=America/Chicago
          - USER_ID=1000
          - GROUP_ID=1000
          - OPENSUBTITLES_USERNAME=bri
          - OPENSUBTITLES_PASSWORD=OpenSubtitles-PW
          - DISPLAY_WIDTH=1840
          - DISPLAY_HEIGHT=800
        volumes:
          - /opt/docker/configs/FileBot:/config:rw
          - /mnt/h/FileBot:/storage:rw              # Storage
          - /mnt/h/FileBot/input:/watch:rw          # AMC Script watch folder
          - /mnt/h/FileBot/output:/output:rw        # AMC Script output folder
          - /etc/localtime:/etc/localtime:ro
        ports:
          - 5800
        secrets:
          - OpenSubtitles-PW
        deploy:
            mode: replicated
            replicas: 1
            placement:
              constraints:
                - node.labels.MainDaemon == true
            resources:
              limits:
                memory: 300M
            restart_policy:
              condition: any
        networks:
          - ocm

secrets:
  OpenSubtitles-PW:
    external: true

networks:
  ocm:
    external: true
    name: misc

YouveGotMeowxy avatar Mar 23 '21 16:03 YouveGotMeowxy

@jlesage I'm not sure why, but whenever I try to use one of your containers and directly try to go to the port and IP of the container it just times out, but when using a reverse proxy it loads.

Probably because of the ocm network. If you don't set a network, the container will be on the same one as the host. You then just need to expose port 5800 (see https://github.com/jlesage/docker-filebot#docker-compose-file).

Reagrding the websockets, a quick question: does it make a difference if the websockify block is actually nested inside the other block? Or canit be separate, like this?

location ^~ /filebot/ {

    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;
    set $upstream_app filebot;
    set $upstream_port 5800;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    rewrite /filebot(.*) $1 break;
}

location ^~ /filebot/websockify {
    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;
    set $upstream_app filebot;
    set $upstream_port 5800;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port/websockify/;

    rewrite /filebot(.*) $1 break;
}

I don't see the WebSocket support. You should have something that looks like the following lines:

		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection $connection_upgrade;

jlesage avatar Mar 30 '21 01:03 jlesage

Oh, also another quick question. While trying to get this working I also tried adding my opensubtitles name and pw env vars, but I used a secret for the pw, and when I did the container would kill itself, but if I just use the pw without being a secret, it stays running. Is there something that needs to be done to get it to support secrets?

Secrets are currently not supported by the container.

jlesage avatar Mar 30 '21 01:03 jlesage