[V4] Stuck on "Loading...", Uncaught SyntaxError: Unexpected token '<' when running reverse proxy #3483

SergeyKasmy · 2020-04-11T02:06:33Z

Describe the bug
After first installing and starting Ombi, the page is stuck on "Loading..." with nothing happening

To Reproduce
Steps to reproduce the behavior:

Install Ombi
Start Ombi
Go to http://servername:port
Watch the page be stuck on "Loading..." forever

Expected behavior
The OOBE should begin shortly after opening the page

Logs (Logs directory where Ombi is located)
Server log:

2020-04-11 01:42:49.866 +00:00 [Information] Default Quartz.NET properties loaded from embedded resource file
2020-04-11 01:42:49.945 +00:00 [Debug] TaskSchedulingThreadPool configured with max concurrency of 10 and TaskScheduler ThreadPoolTaskScheduler.
2020-04-11 01:42:49.953 +00:00 [Information] Initialized Scheduler Signaller of type: Quartz.Core.SchedulerSignalerImpl
2020-04-11 01:42:49.955 +00:00 [Information] Quartz Scheduler v."3.0.7.0" created.
2020-04-11 01:42:49.958 +00:00 [Information] RAMJobStore initialized.
2020-04-11 01:42:49.963 +00:00 [Information] Scheduler meta-data: Quartz Scheduler (v3.0.7.0) 'DefaultQuartzScheduler' with instanceId 'NON_CLUSTERED'
  Scheduler class: 'Quartz.Core.QuartzScheduler' - running locally.
  NOT STARTED.
  Currently in standby mode.
  Number of jobs executed: 0
  Using thread pool 'Quartz.Simpl.DefaultThreadPool' - with 10 threads.
  Using job-store 'Quartz.Simpl.RAMJobStore' - which does not support persistence. and is not clustered.

2020-04-11 01:42:49.963 +00:00 [Information] Quartz scheduler 'DefaultQuartzScheduler' initialized
2020-04-11 01:42:49.963 +00:00 [Information] Quartz scheduler version: 3.0.7.0
2020-04-11 01:42:49.964 +00:00 [Information] JobFactory set to: Ombi.Schedule.IoCJobFactory
2020-04-11 01:42:50.092 +00:00 [Information] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
2020-04-11 01:42:50.101 +00:00 [Debug] Batch acquisition of 0 triggers
2020-04-11 01:43:23.037 +00:00 [Information] Default Quartz.NET properties loaded from embedded resource file
2020-04-11 01:43:23.140 +00:00 [Debug] TaskSchedulingThreadPool configured with max concurrency of 10 and TaskScheduler ThreadPoolTaskScheduler.
2020-04-11 01:43:23.150 +00:00 [Information] Initialized Scheduler Signaller of type: Quartz.Core.SchedulerSignalerImpl
2020-04-11 01:43:23.152 +00:00 [Information] Quartz Scheduler v."3.0.7.0" created.
2020-04-11 01:43:23.154 +00:00 [Information] RAMJobStore initialized.
2020-04-11 01:43:23.159 +00:00 [Information] Scheduler meta-data: Quartz Scheduler (v3.0.7.0) 'DefaultQuartzScheduler' with instanceId 'NON_CLUSTERED'
  Scheduler class: 'Quartz.Core.QuartzScheduler' - running locally.
  NOT STARTED.
  Currently in standby mode.
  Number of jobs executed: 0
  Using thread pool 'Quartz.Simpl.DefaultThreadPool' - with 10 threads.
  Using job-store 'Quartz.Simpl.RAMJobStore' - which does not support persistence. and is not clustered.

2020-04-11 01:43:23.160 +00:00 [Information] Quartz scheduler 'DefaultQuartzScheduler' initialized
2020-04-11 01:43:23.160 +00:00 [Information] Quartz scheduler version: 3.0.7.0
2020-04-11 01:43:23.161 +00:00 [Information] JobFactory set to: Ombi.Schedule.IoCJobFactory
2020-04-11 01:43:23.290 +00:00 [Information] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
2020-04-11 01:43:23.298 +00:00 [Debug] Batch acquisition of 0 triggers

Client log:

Chrome:

Uncaught SyntaxError: Unexpected token '<'      app.js:1

Firefox:

SyntaxError: expected expression, got '<'        app.js:1

Desktop (please complete the following information):

Server: Debian GNU/Linux 9 (stretch), except running Ombi as a user instead of a systemd unit with a separate account (shared server)
Client: Arch Linux with Chromium 81 and Firefox 75; Android 10 with Chromium 77

Ombi Version (please complete the following information):
I've tried both the latest release v3.0.4892 and the latest dev build v3.0.5115-develop

The text was updated successfully, but these errors were encountered:

ombi-bot · 2020-04-11T02:06:34Z

Hi!
Thanks for the issue report. Before a real human comes by, please make sure you used our bug report format.
Have you looked at the wiki yet? https://github.com/tidusjar/ombi/wiki/
Before posting make sure you also read our FAQ.
Make the title describe your issue. Having 'not working' or 'I get this bug' for 100 issues, isn't really helpful.
If we need more information or there is some progress we tag the issue or update the tag and keep you updated.
Thanks!
Ombi Bot.

ionred · 2020-04-15T22:13:36Z

@SleeplessSloth -- I had the same problem. For some reason a hard reload of the page was the only thing that would get past the loading screen (I also had identical console errors and logs). In Chrome, open developer tools, then right click the normal refresh button and choose hard reset.

SergeyKasmy · 2020-04-16T16:23:57Z

Didn't work, there's no difference between a normal reload and a hard reset sadly

ionred · 2020-04-16T17:31:02Z

Very odd indeed. The error actually came back for me after a restart of Ombi. My only recourse was to stop the service, wipe out any trace of the config file, and run it again. (I run it as a docker container).

Restarting or changing versions did nothing to help the problem. Only once I completed deleted the config folder.

tidusjar · 2020-04-18T23:49:20Z

how are you starting ombi up? Are you passing any args?

ionred · 2020-04-19T01:42:34Z

for me, docker compose:


  ombi:
#    image: linuxserver/ombi  ## Previously used image, I don't believe it ever happened on here but I only used it for a few hours before swapping to v4 preview
    image: linuxserver/ombi:v4-preview
    container_name: ombi
    environment:
      - PUID=${PUID} # default user id, defined in .env
      - PGID=${PGID} # default group id, defined in .env
      - TZ=${TZ} # timezone, defined in .env
      - BASE_URL=/ombi #optional
    volumes:
      - /mnt/external/downloader/config/ombi:/config
      - /mnt/external/downloader/config/ombi/Logs:/opt/ombi/Logs
    ports:
      - 3579:3579
    restart: unless-stopped

SergeyKasmy · 2020-04-19T02:15:20Z

./Ombi --host 'http://*:62156' --baseurl '/foo/ombi' in my case. I have somehow worked around the bug by not connecting from the internet but by using ssh -L for the first setup. After that everything has seemed to work okay. That couldn't be something like ports being not open or whatnot since I could connect to the page just fine but all I saw was "Loading..."

waynetx383 · 2020-04-21T14:59:42Z

I'm getting the same results. Even with the newest version release I can still only get the page to load via localhost, and even then it never makes it past the loading screen. Also seeing the same error in chrome developer tools of an unexpected <.

mike391 · 2020-04-21T17:43:22Z

It works when accessed from the internet via reverse proxy, but does not work when accessed directly

tommy-b-10 · 2020-06-12T02:32:19Z

I am also experiencing this issue on v4.0.365.
From my testing it looks to be linked to setting the base url. When the base url is set and the container restarted, it is not possible to access Ombi. And when appending the base url, a blank white screen appears as though it was not set at all.

tidusjar · 2020-06-12T06:44:51Z

If you have applied a base URL then you need to access ombi through a reverse proxy

tommy-b-10 · 2020-06-12T14:58:08Z

@tidusjar in v4.0.365 when attempting to access via reverse proxy with the base url set, the page appears blank/white, and the console shows the error SyntaxError: expected expression, got '<'.
When attempting to access via ip:port/base-url, it redirects to not using the base url at all, and intermittently becomes stuck on the colourful loading screen.

tidusjar · 2020-06-12T15:24:08Z

And you restarted ombi after making the Base URL change right?

What are you using to reverse proxy it?

tommy-b-10 · 2020-06-12T16:46:19Z

Correct, restarted Ombi, and changed my reverse proxy from pointing to my Ombi v3 instance to my v4 instance, no other settings changed. The v3 instance works perfectly with no issues accessing with the base URL.

Reverse proxy is Nginx

tommy-b-10 · 2020-06-14T04:43:44Z

@tidusjar

Screenshot showing the database setting showing the base url and showing attempting to access it using Nginx reverse proxy.

tidusjar · 2020-06-14T07:02:01Z

Please share your proxy config

tommy-b-10 · 2020-06-14T07:09:31Z

See attached text file. Ombi is being redirected too as per the /request location.
As noted above, with v3, the reverse proxy is working correctly, it's just v4 that is having issues.

plex-nginx.conf.txt

Do-while-Bacon · 2020-07-19T22:12:06Z

I just attempted to upgrade from v3 to v4 and I am having the same behavior. Accessing it through the nginx reverse proxy just produces a white screen. Accessing it directly via port 3579, with or without the /plexreq/ in the URL produces a colored loading screen that spins endlessly. Firefox console shows SyntaxError: expected expression, got '<'

Using the latest linuxserver.io Ombi and Let'sEncrypt containers.

    ombi:
        image: linuxserver/ombi:v4-preview
        container_name: ombi
        volumes:
            - /chobi/dockerdata/ombi:/config
        environment:
            - PGID=774200006
            - PUID=774200016
            - TZ=America/New_York
            - BASE_URL=/plexreq
        ports:
            - '3579:3579'
        restart: unless-stopped

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

location ^~ /plexreq/ {
    # enable the next two lines for http auth
    #auth_basic "Restricted";
    #auth_basic_user_file /config/nginx/.htpasswd;

    # enable the next two lines for ldap auth, also customize and enable ldap.conf in the default conf
    #auth_request /auth;
    #error_page 401 =200 /login;

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

}

# This allows access to the actual api
location ^~ /plexreq/api {
    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;
    set $upstream_app ombi;
    set $upstream_port 3579;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;

}
if ($http_referer ~* /plexreq) {
    rewrite ^/api/(.*) /plexreq/api/$1? redirect;
}

# This allows access to the documentation for the api
location ^~ /plexreq/swagger {
    include /config/nginx/proxy.conf;
    resolver 127.0.0.11 valid=30s;
    set $upstream_app ombi;
    set $upstream_port 3579;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;

}
if ($http_referer ~* /plexreq) {
    rewrite ^/swagger/(.*) /plexreq/swagger/$1? redirect;
}

haxx0r07 · 2020-07-27T17:36:37Z

I'm seeing the same errors and issues on my install as well.

Switch my docker container to use the v4-preview tag of the linuxserver.io container. The container starts and doesn't show any errors in it's stdout logs. However, when attempting to access the interface I just get a spinning loading screen.

ExDominatus · 2020-08-05T11:20:08Z

Getting the same issues with my install (blank white screen) using the v4-preview docker tag.

My nginx reverse proxy config for reference:

  proxy_pass        http://127.0.0.1:5000/ombi;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $http_connection;
  proxy_set_header Host $proxy_host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_redirect off;
}

Do-while-Bacon · 2020-08-06T02:53:35Z

I tried removing all my databases and doing a completely fresh setup of the v4-preview container and it still didn't work. Ombi doesn't seem to honor the baseurl setting at all in v4. I was able to get to the instance without using a baseurl, but absolutely could not get the baseurl to work with or without an nginx reverse proxy in front of it.

ben63vw · 2020-08-25T02:23:34Z

I'm seeing the same loading issue with v4 running on a Qnap. Had to revert back to using v3.

joggs · 2020-10-11T11:05:16Z

I am having the same problem. With a base url, you are stuck on loading../blank screen for direct connect/nginx reverse proxy respectively.
If I remove the base url, it works as expected.

tidusjar · 2020-10-12T07:23:02Z

OK,

When using a reverse proxy, if you are passing in the baseurl as a startup argument all good, if you are setting it in the Settings pages, Ombi requires a restart.

Then you need to make sure your Proxy Config is all good see here: https://github.com/tidusjar/Ombi/wiki/Reverse-Proxy-v4

Once you have changed your proxy config ensure you restart Nginx. You should be then able to access V4 via the proxy address.

joggs · 2020-10-12T08:10:01Z

It looks like the reverse proxy config is correct. Also the *rr apps works through the proxy.
The ombi android app also still works through the reverse proxy, also if you view page source in the webbrowser, you can see that there is code there.
I can see that basepath is '/' in the javascript below, even though basepath is /ombi in the database. Could that have something to do with it?


  | <!DOCTYPE html>
-- | --
  | <html lang="en">
  |  
  | <head>
  | <script type='text/javascript'>
  | function configExists(url) {
  | var req = new XMLHttpRequest();
  | req.open('GET', url, false);
  | req.send();
  | return req.status === 200 && req.responseURL === url;
  | }
  |  
  | var probePath = 'styles/please-wait.js';
  | var origin = document.location.origin;
  | var pathSegments = document.location.pathname.split('/');
  |  
  | var basePath = '/'
  | var configFound = false;
  | for (var i = 0; i < pathSegments.length; i++) {
  | var segment = pathSegments[i];
  | if (segment.length > 0) {
  | basePath = basePath + segment + '/';
  | }
  | var fullPath = origin + basePath + probePath;
  | configFound = configExists(fullPath);
  | if (configFound) {
  | break;
  | }
  | }
  | var basePathToUse = basePath.substring(0, basePath.length - 1); // trim off the trailing '/'
  | basePathToUse == '' ? '/' : basePathToUse;
  | window["baseHref"] = configFound ? basePathToUse : '/';
  |  
  | document.write("<base href='" + (configFound ? basePath : '/') + "' />");
  |  
  | console.log(window["baseHref"]);
  | </script>
  | <link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet">
  | <link href="https://fonts.googleapis.com/css?family=Roboto:300,400,500" rel="stylesheet">
  | <link href="styles/please-wait.css" rel="stylesheet">
  | <link href="styles/spinkit.css" rel="stylesheet">
  | <link href="styles/11-folding-cube.css" rel="stylesheet">
  | <link rel="icon" type="image/png" href="images/favicon/favicon.ico"/>
  | <script src="styles/please-wait.js"></script>
  | <meta charset="utf-8" />
  | <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  | <meta property="og:image:height" content="375" />
  | <meta property="og:image:width" content="991" />
  | <meta property="og:image" content="~/images/logo.png" />
  | <meta property="og:site_name" content="Ombi" />
  | <meta property="og:title" content="Ombi" />
  | <meta property="og:type" content="website" />
  | <meta property="og:description" content="Ombi, media request tool">
  |  
  | <title>Ombi</title>
  |  
  | <link href="https://fonts.googleapis.com/css?family=Roboto:300,400,500&display=swap" rel="stylesheet">
  | <link rel="stylesheet" href="styles.f86c5adfa764c951f59e.css"><link rel="stylesheet" href="main.505174cd50b2102321f0.css"></head>
  |  
  | <body class="mat-typography custom-background">
  |  
  | <app-ombi>
  | <script type="text/javascript">
  | var colors = ["#f44336", "#f44336", "#9c27b0", "#673ab7", "#3f51b5", "#2196f3", "#03a9f4", "#00bcd4", "#009688", "#4caf50", "#cddc39", "#ffeb3b", "#ffc107", "#ff9800", "#ff5722", "#9e9e9e", "#607d8b"];
  | var bgColor = colors[Math.floor(Math.random() * colors.length)];
  | window.loading_screen = window.pleaseWait({
  | // logo: "assets/images/logo.png",
  | template: `<div class='pg-loading-inner'>
  | <div class='pg-loading-center-outer'>
  | <div class='pg-loading-center-middle'>
  | <h1 class='pg-loading-logo-header'>
  | </h1>
  | <div class='pg-loading-html'>
  | </div>
  | Loading
  | </div>
  | </div>
  | </div>`,
  | backgroundColor: bgColor,
  | loadingHtml: "<div class='sk-folding-cube'><div class='sk-cube1 sk-cube'></div><div class='sk-cube2 sk-cube'></div><div class='sk-cube4 sk-cube'></div><div class='sk-cube3 sk-cube'></div></div>"
  | });
  | </script>
  | </app-ombi>
  | <script src="runtime.74394d19e9b47be0a522.js" defer></script><script src="polyfills-es5.6308fbeb21f20fe59dcd.js" nomodule defer></script><script src="polyfills.330e93a5e634aa70f222.js" defer></script><script src="scripts.1b13958999223135db0e.js" defer></script><script src="main.94f96b7704ff9c0d7172.js" defer></script></body>
  |  
  | </html>
  |

tidusjar · 2020-10-12T08:38:02Z

and what is the URL you are accessing ombi on?
Can you also provide the console logs from the browser?

joggs · 2020-10-12T09:55:39Z

https://aaa.duckdns.org/ombi or http://192.168.0.40:3579. I get the same errors in console for both urls:

(index):8 [Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.
configExists @ (index):8
(index):36
runtime.74394d19e9b47be0a522.js:1 Uncaught SyntaxError: Unexpected token '<'
polyfills.330e93a5e634aa70f222.js:1 Uncaught SyntaxError: Unexpected token '<'
scripts.1b13958999223135db0e.js:1 Uncaught SyntaxError: Unexpected token '<'
main.94f96b7704ff9c0d7172.js:1 Uncaught SyntaxError: Unexpected token '<'
2(index):1 Unchecked runtime.lastError: The message port closed before a response was received.
DevTools failed to load SourceMap: Could not load content for chrome-extension://oaaadlnghojigbibgkbalkkmbfkakkbe/polyfills/promise-7.0.4.min.js.map: HTTP error: status code 404, net::ERR_UNKNOWN_URL_SCHEME
DevTools failed to load SourceMap: Could not load content for chrome-extension://oaaadlnghojigbibgkbalkkmbfkakkbe/libs/underscore-min.map: HTTP error: status code 404, net::ERR_UNKNOWN_URL_SCHEME
DevTools failed to load SourceMap: Could not load content for chrome-extension://oaaadlnghojigbibgkbalkkmbfkakkbe/libs/backbone-min.map: HTTP error: status code 404, net::ERR_UNKNOWN_URL_SCHEME
DevTools failed to load SourceMap: Could not load content for chrome-extension://gabdloknkpdefdpkkibplcfnkngbidim/maps/content.min.js.map: HTTP error: status code 404, net::ERR_UNKNOWN_URL_SCHEME

"Unexpected token '<'" are usually the result of an invalid reference to a resource as the filename is hashed and the site returns a 404 page which begins with a <

tidusjar · 2020-10-13T07:44:22Z

When accessing https://aaa.duckdns.org/ombi what is the Base Href in the DOM?

joggs · 2020-10-13T11:18:43Z

The base path is /

…

On Tue, Oct 13, 2020 at 9:44 AM Jamie ***@***.***> wrote: When accessing https://aaa.duckdns.org/ombi what is the Base Href in the DOM? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3483 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACLJXJCQG2VC3GLXGTLYIDSKQAONANCNFSM4MF2A5EQ> .

-- /Jörgen Bergström

tidusjar · 2021-01-13T11:21:04Z

I have not merged this fix in as I would like some more testing on the build, so there is no docker container for it. I could merge it in but due to the many different configurations that people are using to run ombi, i'd be worried that it would just cause more issues.

If anyone is available to test it outside of a docker container, that would be fantastic

palmfighter · 2021-01-13T11:46:32Z

more than happy to test it, perhaps I can make a copy of the repo into my own repo and building a container myself of it?

as I am also on your discord channel, we can discuss over there how to do it? I don't understand the link to the Azure host where I see some files?

tommek83 · 2021-01-13T19:34:35Z

But isn't the problem exactly in this docker configuration? People who have letsencrypt + ombi running in docker containers are the ones with the problems, aren't they? At least that's the case for me.

shanester64 · 2021-01-14T00:03:49Z

I am running Ombi 4 on Windows behind nginx reverse proxy & letsencrypt on the frontend.
Accessing internally (IP:Port) fails

Accessing via the WAN (https://mydomain/request) is not an issue.

I did not have this problem on v3

tidusjar · 2021-01-14T07:04:22Z

But isn't the problem exactly in this docker configuration? People who have letsencrypt + ombi running in docker containers are the ones with the problems, aren't they? At least that's the case for me.

The actual way you are running ombi makes no difference

@shanester64 please try the build above.

maquikun · 2021-01-14T22:11:03Z

@tidusjar I tried the test build that was sent but mine was still giving the Uncaught Syntax Error. Here is the setup/config:

Version: Ombi V4 custom build
OS: Windows Server 2019
Reverse Proxy: Plesk running NGINX with reverse proxy config on Ubuntu 20.04
SSL: Cloudflare full SSL setting
Base URL Field Left blank

Reverse proxy config:

location / {
	proxy_pass http://10.0.0.100:5000/;
	proxy_http_version 1.1;
	proxy_set_header Upgrade $http_upgrade;
	proxy_set_header Connection "upgrade";
}

ComteNiark · 2021-01-14T22:47:03Z

Still doesn't seem to work with the test build

OS: Windows server 2019
Reverse proxy: caddy
SSL: Let'sEncrypt through caddy

reverse_proxy /ombi* 127.0.0.1:5000

Even going to 127.0.0.1:5000 gives infinite loading.

Maybe this first line is the culprit?:

2021-01-14 23:47:49.354 +01:00 [Warning] could not read configuration using ConfigurationManager.GetSection: Configuration system failed to initialize
2021-01-14 23:47:49.370 +01:00 [Information] Default Quartz.NET properties loaded from embedded resource file
2021-01-14 23:47:49.393 +01:00 [Debug] TaskSchedulingThreadPool configured with max concurrency of 10 and TaskScheduler ThreadPoolTaskScheduler.
2021-01-14 23:47:49.396 +01:00 [Information] Initialized Scheduler Signaller of type: Quartz.Core.SchedulerSignalerImpl
2021-01-14 23:47:49.397 +01:00 [Information] Quartz Scheduler v."3.1.0.0" created.
2021-01-14 23:47:49.398 +01:00 [Information] RAMJobStore initialized.
2021-01-14 23:47:49.400 +01:00 [Information] Scheduler meta-data: Quartz Scheduler (v3.1.0.0) 'DefaultQuartzScheduler' with instanceId 'NON_CLUSTERED'
  Scheduler class: 'Quartz.Core.QuartzScheduler' - running locally.
  NOT STARTED.
  Currently in standby mode.
  Number of jobs executed: 0
  Using thread pool 'Quartz.Simpl.DefaultThreadPool' - with 10 threads.
  Using job-store 'Quartz.Simpl.RAMJobStore' - which does not support persistence. and is not clustered.

2021-01-14 23:47:49.400 +01:00 [Information] Quartz scheduler 'DefaultQuartzScheduler' initialized
2021-01-14 23:47:49.400 +01:00 [Information] Quartz scheduler version: 3.1.0.0
2021-01-14 23:47:49.400 +01:00 [Information] JobFactory set to: Ombi.Schedule.IoCJobFactory
2021-01-14 23:47:49.449 +01:00 [Information] Scheduler DefaultQuartzScheduler_$_NON_CLUSTERED started.
2021-01-14 23:47:49.452 +01:00 [Debug] Batch acquisition of 0 triggers

ghost · 2021-01-17T12:42:56Z

I have the same issue. Running on a local install, not sudo, not docker.
Tried the test-build, but didn't work either.

Reverted back to the stable v4 build.

Ombi opens just fine: https://pastebin.com/tzQ3Jsmn

My proxypass setup:
https://pastebin.com/3CA9jj01

I can access the /reqombi/swagger url just fine, but the /reqombi and /reqombi/api just returns blank pages.

Browser console output:
https://i.imgur.com/lGCugTt.png

NGINX Log (removed website name and username etc):
https://pastebin.com/jdW6NTCv

Edit: Tried to revert to Ombi v3, and the proxypass works there :/. Must be something in v4
Edit 2: Fixed for me in v4.0.1131 👍

zelik888 · 2021-02-01T01:35:06Z

Same issues with me, I just updated from v3 to v4. Using Caddy on Windows 10 x64, reverse proxy does not work.

Strangely, i can still access directly (ip address and port) but the base url that I have set in the configuration and even through startup options don't reflect in the url.

I've tried a fresh install and the issue still persists

--baseurl doesn't seem to work specifically. No matter what I change it to, it doesn't go into effect. If I log into the OMBI and look at settings it will show the baseurl in settings.

jpinnekamp · 2021-02-05T18:47:11Z

I'm having the same issue without a reverse proxy/base url in docker v4-preview.
In Chrome I'm stuck with the loading screen.
In Firefox I can partially use it, but also get some errors.

If you need more log data, let me know.

jamjop · 2021-02-08T07:56:10Z

I'm also having this issue. Ubuntu 20.04 with nginx setup per the instructions in wiki. blank screen. Works flawlessly with Firefox but not in edge. I'm using a baseurl

Ok so this is very weird. Everything works perfectly if I access it from a browser that I did not use to setup Ombi initially. So on my server I can’t access Ombi through Edge but all other browsers work, and edge works if I access through edge on my desktop. I’ve confirmed that all browsers work fine as long as it as not the browser I originally accessed Ombi via local host. This is true if I start with a clean install and initially setup with another browser.

jpinnekamp · 2021-02-09T23:32:18Z

I'm having the same issue without a reverse proxy/base url in docker v4-preview.
In Chrome I'm stuck with the loading screen.
In Firefox I can partially use it, but also get some errors.

If you need more log data, let me know.

Using hotio/ombi:testing instead of linuxserver/ombi:development helped a bit. Still get many errors, but not stuck on loading. So I'll check it out some more and maybe add a new issue.

tobyraistrick · 2021-02-24T23:52:56Z

I run Ombi v4 on a Windows server on port 80, and then use Cloudflare to connect to it over the WAN.
This "Loading..." issue only occurs on mobile and tablet devices. But desktop/laptops browsers load fine.

JaxonWright · 2021-02-28T23:34:34Z

This appears to be fixed in the latest version v4.0.1128

tobyraistrick · 2021-02-28T23:45:32Z

I just updated to v4.0.1131 and it's still not loading on mobile devices, but working perfectly on desktop browsers.

mikekuzak · 2021-02-28T23:47:22Z

@tobyraistrick works for me .. had to wait a while until the container comes up and cleared browser cache.

tobyraistrick · 2021-03-01T00:02:41Z

Oh yeah, when I tested in Private mode in Safari, it loaded. I can't get all my users to clear their browser cache. Is there anything I can do in the application to make this work normally? I've already tried purging all Cloudflare cache.

shanester64 · 2021-03-01T00:26:51Z

Updated to v4.0.1131. Confirmed local and reverse proxy access working on Win64

zelik888 · 2021-03-01T00:48:00Z

I fixed my issue by upgrading from caddy V1 to caddy V2.

I reinstalled ombi by deleting the folder and installing the amd64 version and copying the 3 files (Ombi.db, ombiexternal.db, ombisettings.db)

Changed my Caddy settings to V2 and viola, working reverse proxy.

goober2186 · 2021-03-01T02:10:55Z

Seems to be working for me now as well

ghost · 2021-03-01T07:47:17Z

Running v4.0.1131 and it works great 😄 !!

tidusjar · 2021-03-01T08:21:15Z

So just to update you, this is something i've been working on the past few months to try and resolve. It's not been easy due to this doesn't seem like a supported scenario in Angular. But I think i've cracked it and but the response in here it seems like I have so far. Thanks for the feedback everyone

conorlap · 2021-03-01T08:22:48Z

Working perfectly for me now, thanks so much @tidusjar !!

mduijm · 2021-03-04T13:55:12Z

thanks a lot, got it working! used latest version of linuxserver docker.

htims1989 · 2021-03-05T15:43:21Z

This does not seem to be fixed, I am getting the issue on 4.0.1142.0.

To reproduce:

do a fresh install via apt
download the linux64 tar
sudo systemctl stop ombi.service
extract tar into /opt/Ombi
sudo systemctl start ombi.service
point browser at host:5000
follow wizard through
set a base url in setting
sudo systemctl restart ombi.service
try reload page with/without baseurl

EDIT: of course a few minutes after writing this I found: https://docs.ombi.app/info/known-faults/#unauthorized-access-to-indexhtml

For some reason /opt/Ombi was not owned by ombi, a quick chown and it's working correctly now.

tommek83 · 2021-03-07T18:20:40Z

It's also working for me.
Thank you very much.

d-d mentioned this issue Aug 27, 2020

Ombi v4 migration Base url problem #3718

Closed

JaxonWright mentioned this issue Feb 26, 2021

Ombi V4 Baseurl on windows not working #4070

Closed

tidusjar closed this as completed Mar 1, 2021

tidusjar unpinned this issue Mar 8, 2021

AliceDTRH mentioned this issue Nov 15, 2021

Ombi v4 coder8338/appbox_installer#57

Closed

[V4] Stuck on "Loading...", Uncaught SyntaxError: Unexpected token '<' when running reverse proxy #3483

[V4] Stuck on "Loading...", Uncaught SyntaxError: Unexpected token '<' when running reverse proxy #3483

Comments

SergeyKasmy commented Apr 11, 2020

ombi-bot commented Apr 11, 2020

ionred commented Apr 15, 2020

SergeyKasmy commented Apr 16, 2020

ionred commented Apr 16, 2020 • edited Loading

tidusjar commented Apr 18, 2020

ionred commented Apr 19, 2020 • edited Loading

SergeyKasmy commented Apr 19, 2020

waynetx383 commented Apr 21, 2020

mike391 commented Apr 21, 2020

tommy-b-10 commented Jun 12, 2020

tidusjar commented Jun 12, 2020

tommy-b-10 commented Jun 12, 2020

tidusjar commented Jun 12, 2020

tommy-b-10 commented Jun 12, 2020 • edited Loading

tommy-b-10 commented Jun 14, 2020

tidusjar commented Jun 14, 2020

tommy-b-10 commented Jun 14, 2020

Do-while-Bacon commented Jul 19, 2020 • edited Loading

haxx0r07 commented Jul 27, 2020

ExDominatus commented Aug 5, 2020

Do-while-Bacon commented Aug 6, 2020

ben63vw commented Aug 25, 2020

joggs commented Oct 11, 2020 • edited Loading

tidusjar commented Oct 12, 2020

joggs commented Oct 12, 2020 • edited by tidusjar Loading

tidusjar commented Oct 12, 2020

joggs commented Oct 12, 2020 • edited Loading

tidusjar commented Oct 13, 2020

joggs commented Oct 13, 2020 via email

tidusjar commented Jan 13, 2021

palmfighter commented Jan 13, 2021

tommek83 commented Jan 13, 2021

shanester64 commented Jan 14, 2021

tidusjar commented Jan 14, 2021 • edited Loading

maquikun commented Jan 14, 2021 • edited Loading

ComteNiark commented Jan 14, 2021 • edited Loading

ghost commented Jan 17, 2021 • edited by ghost Loading

zelik888 commented Feb 1, 2021 • edited Loading

jpinnekamp commented Feb 5, 2021

jamjop commented Feb 8, 2021 • edited Loading

jpinnekamp commented Feb 9, 2021

tobyraistrick commented Feb 24, 2021

JaxonWright commented Feb 28, 2021

tobyraistrick commented Feb 28, 2021

mikekuzak commented Feb 28, 2021

tobyraistrick commented Mar 1, 2021

shanester64 commented Mar 1, 2021

zelik888 commented Mar 1, 2021

goober2186 commented Mar 1, 2021

ghost commented Mar 1, 2021

tidusjar commented Mar 1, 2021

conorlap commented Mar 1, 2021

mduijm commented Mar 4, 2021

htims1989 commented Mar 5, 2021 • edited Loading

tommek83 commented Mar 7, 2021

ionred commented Apr 16, 2020 •

edited

Loading

ionred commented Apr 19, 2020 •

edited

Loading

tommy-b-10 commented Jun 12, 2020 •

edited

Loading

Do-while-Bacon commented Jul 19, 2020 •

edited

Loading

joggs commented Oct 11, 2020 •

edited

Loading

joggs commented Oct 12, 2020 •

edited by tidusjar

Loading

joggs commented Oct 12, 2020 •

edited

Loading

tidusjar commented Jan 14, 2021 •

edited

Loading

maquikun commented Jan 14, 2021 •

edited

Loading

ComteNiark commented Jan 14, 2021 •

edited

Loading

ghost commented Jan 17, 2021 •

edited by ghost

Loading

zelik888 commented Feb 1, 2021 •

edited

Loading

jamjop commented Feb 8, 2021 •

edited

Loading

htims1989 commented Mar 5, 2021 •

edited

Loading