[Bug]: adBlock causes a ~110s startup stall (Tidal now awaits the blocked /users/<id>?countryCode endpoint)

[OtokoWa]

Pre-submission checklist

• I have searched the existing issues and my issue has not already been reported
• I have read the known issues documentation and my issue is not listed there

Note: #832 and #853 and the "Subscribe button showing and/or account details not
working" known-issue cover the cosmetic fallout of this same filter. This report is
about a new and much worse symptom from the same rule: the app is unusable for ~110
seconds on every launch. That is not documented anywhere.

Installation Method

Flatpak (Flathub, system install)

Linux Distribution

Fedora Linux 44 (KDE Plasma Desktop Edition), kernel 7.1.4-200.fc44.x86_64, Wayland/KDE

Tidal Hi-Fi Version

7.0.1 (Flathub's current build). The offending code is unchanged in 8.0.0 — the
// Adblock block in src/main.ts is byte-identical between the 7.0.1 and 8.0.0 tags,
so this is not fixed by the latest release.

Current Behavior

With adBlock enabled, the app sits on its loading screen for ~110 seconds on every
launch before the Tidal UI renders. With adBlock disabled it renders in ~3 seconds.

The cause is the ad block filter in src/main.ts:

if (settingsStore.get(settings.adBlock)) {
  const filter = { urls: [`${tidalUrl}/*`] };
  session.defaultSession.webRequest.onBeforeRequest(filter, (details, callback) => {
    if (details.url.match(/\/users\/.*\d\?country/)) callback({ cancel: true });
    else callback({ cancel: false });
  });
}

The regex requires a digit immediately before ?country, so it cancels
https://tidal.com/v1/users/<id>?countryCode=….

It appears Tidal changed their web app (around early July 2026) so that it now awaits
that endpoint before rendering the UI. Cancelling it no longer just hides account
details — the web app blocks on an internal timeout of roughly 110 s, gives up, and only
then renders. Nothing in tidal-hifi changed; my install has been on 7.0.1 since June 20,
and the stall started ~2 weeks later, which points to a server-side change on Tidal's end.

I captured a Chromium net-log (--log-net-log=) of a stalled launch. It shows the page,
all JS bundles and the initial API calls (favourites, subscription, playlists) all
completing by 3.9 s, then near-total network silence from 16 s to 108.5 s — the
only traffic in that window is Chromium's routine component-update check. At 108.5 s the
home feed and images are suddenly fetched and the UI appears. So the app is not waiting on
the network; it is waiting on a timer after the cancelled request.

Timings are very consistent, which is what you'd expect from a fixed timeout rather than a
slow resource:

adBlock	time until "Detected Tidal UI version"
true	108.0 s, 108.3 s, 110.0 s, 110.7 s, 112.2 s
false	3.0 s

Also worth noting: because the default config has minimizeOnClose: true and
singleInstance: true, closing the window only hides the app, so users only hit a real
process launch once per boot. That makes this very easy to misread as "slow only after a
reboot" — I chased boot/network causes for a long time before reproducing it warm.

Expected Behavior

The UI renders promptly with adBlock enabled — the ad block filter should not be able to
block the app's own startup path.

Steps to Reproduce

1. Enable adBlock (Settings → Integrations).
2. Fully quit Tidal Hi-Fi (make sure the process is gone, not just minimised to tray).
3. Launch it and time how long until the UI appears — ~110 s.
4. Set adBlock to false, fully quit, relaunch — UI appears in ~3 s.

Screenshots and Logs

Timestamps from the app's own stdout (Detected Tidal UI version comes from the 500 ms DOM
detection loop in TidalControllers/DomController/constants.ts):

adBlock = true
  17:04:27.6  Loading theme "builtin:Blood.css"    <- window created
  17:06:15.9  Detected Tidal UI version: new       <- 108s later

adBlock = false
  Detected Tidal UI version: new  after 3.0s

Net-log activity timeline for a stalled launch (seconds with any network events):

0,1,2,3   page + JS + API calls, all successful
12, 16    telemetry (dd.tidal.com, /api/event-batch)
59,60,62  update.googleapis.com  (Chromium component updater, unrelated)
108,109   home feed + images  <- UI finally renders

Additional Context

Possible fixes, in rough order of preference:

1. Narrow the rule so it can't cancel the account/session request the app now depends on
   (this endpoint appears to be load-bearing for startup now, not just for account UI).
2. Respond to the request instead of cancelling it — e.g. let it through and strip/redirect
   the ad payload — so the web app's promise settles instead of hanging.
3. At minimum, update docs/known-issues.md: the adblock side-effect is no longer only a
   "Subscribe button / account details" cosmetic problem, it now costs ~110 s of startup.

[Mastermindzh]

can you now verify where ads are being loaded from?
I am not in one of the ad-enabled countries and I pay for Tidal so I have no ads by default.

If you can find the urls ads are loaded from I'd be happy to tighten the regex :)

[rneilson]

Confirmed for me as well, version 8.1.1. I also have a paid Tidal sub so I don't get ads and can't help on the alternate regexes, sorry. I'd suggest a narrow exception for /v1/users/<user-id>?countryCode=<code>&locale=<locale>&deviceType=BROWSER just to allow proper startup. (Alternately, at least put a warning on the adblock toggle about the delayed startup...)

[Mastermindzh]

Thanks for the URL to allow.
I added it as a whitelist and also added the note you suggested:

I still can't test it, but I'll include it in the next version regardless :)