Troubleshooting

Use plain-language status and sanitized diagnostics without exposing protected values.

For Search sources, Find More Sources, or limit warnings, follow [Will my indexer account get rate-limited or suspended?](indexer-account-limits.md). Wait for the reset or correct credentials; never evade a restriction.

When the installer stops

The installer stops at the step that failed, prints the step number, and gathers a

report. Nothing in that report is a credential — send it as it stands.

Each entry below was seen on a real first install. The installer now prevents it, so

you should not meet it; the entry stays so that the message means something if you do.

### "No such image" while starting

**What it means.** The machine was asked to run an engine it had never downloaded.

**What to do.** Run the installer again; it fetches what is missing.

**Why it will not happen again.** Every engine GeekStream pins by digest is allowed to

be fetched once. Only the GeekStream server image itself is never fetched, because it

is built on your machine from the files you installed.

### The streams engine will not start

**What it means.** AIOStreams exits immediately, naming settings it was not given.

**What to do.** Run the installer again. It fills in any setting that is absent without

touching one that already exists.

**Why it will not happen again.** The installer writes the engine's full set of

settings when it first creates them. One of those, the encryption key, cannot be

changed once the engine has run — everything you have configured is encrypted with it —

so a later run only ever adds what is missing.

### "local_release_identity_not_pinned"

**What it means.** The server files carry no record of which version they are, and the

server will not run code it cannot account for.

**What to do.** Install from a release download or from a git clone. A folder copied

out of either one loses the stamp.

**Why it will not happen again.** The installer resolves the version while it places

the files, and stops with a plain sentence if it cannot — before anything is built.

### "physical_runtime_server_identity_invalid"

**What it means.** The server looked for its own identity before you had set it up.

**What to do.** Nothing. This was a fault in the server, fixed on 2026-09-22.

**Why it will not happen again.** A server nobody has set up yet reports that it has no

identity instead of failing. A malformed identity still stops the server.

### "No servers are configured" from the downloader

This is not a failure. NZBGet says this until you enter your Usenet provider on the

**Sources** screen. Everything else starts normally.

### The fix you installed does not seem to be running

Run the installer again. It rebuilds the server image whenever the installed files come

from a different version than the image that is running, so an update runs the code it

just installed.

### Your address answers, but the dashboard does not load

If the installer stops saying your address did not answer, the server is running and it

is the route to it that is not. The tunnel's own last lines are printed with the

message.

**"exec format error"** — the tunnel build does not match the machine. Run the installer

again; it now chooses the build for your processor.

**"Failed to read token file: permission denied"** — the tunnel could not read its own

credential. Run the installer again; it gives the file to the tunnel's user.

**Error 1033 in a browser** — Cloudflare reached GeekStream's address but no tunnel was

connected. It means one of the two above, or that the machine was off.

Plex, when this server cannot reach it

Connecting Plex can end with **None of this server’s secure routes could be

verified**. Every address Plex offered was tried and none answered.

This is usually not a fault in GeekStream or in Plex. Plex tells GeekStream where it

is, and the answer is normally an address on your home network plus your home

connection with a port open on the router. A GeekStream running on a rented server is

on neither: it is not in your house, and if your router will not forward a port there

is no way in from outside. Plex Relay does not help here either, because it carries

playback rather than the library reading this needs.

Nothing about your Plex is broken. The two machines simply cannot see each other.

### Import it from your browser instead

The browser you read the dashboard in is almost certainly on the same network as your

Plex, even when the server is not. So it can do the reading.

In **Connections → Plex**, sign in as usual, then open **GeekStream cannot reach my

Plex** and press **Read my Plex from this browser**.

1. Your browser tries each address Plex gave, nearest first, and says which one worked.

2. You choose a library — films, series or music.

3. Your browser reads it and sends the list to your server as it goes, telling you how

far along it is.

4. The same review appears as any other import, and **nothing is imported until you

approve it**.

Your server reads those entries with exactly the same code it uses for a library it

fetched itself, with the same limits and the same refusals. Only the delivery differs.

### What this means for what is private

To ask Plex for your library, your browser needs your Plex key, so the dashboard sends

it to the page. It goes from your browser to your own Plex and nowhere else, over an

encrypted connection, and the dashboard is allowed to contact Plex addresses and no

other outside address. It is the same key that browser would be given by signing in to

Plex directly.

No media is copied at any point. What is imported is a list of what you have.

### If your browser cannot reach it either

Then Plex is not running, or this computer is not on the same network as it. Open Plex

in another tab of the same browser to check. If Plex opens there and the import still

fails, say so — that is a fault worth fixing rather than working around.

**Your Plex answered but refused the request** — your sign-in expired. Press Connect on

the Plex card to sign in again, then retry.

Nothing from Usenet will play

Playing anything from Usenet reads it through InfiniDysk, and that read needs its own

sign-in — separate from your Usenet provider account, and separate from InfiniDysk’s own

browser sign-in. Without it, searching and downloading work and playback does not.

GeekStream makes that sign-in itself. In **Connections → InfiniDysk media access** the

line at the top says whether it is set up. If it is not, press **Set up media access**:

GeekStream creates the credentials, proves them with a real read, and keeps them only if

that read succeeds. You never see them and never need to.

If it will not set up, InfiniDysk is not answering. Wait a moment and press it again.

Nothing is changed by a failed attempt.

The panel underneath, **I made my own sign-in in InfiniDysk**, is only for someone who

went and created one by hand. What you type there is checked against InfiniDysk before it

is kept, so a wrong one is refused rather than saved and left to fail later.

Your Live TV service tests fine but its guide is refused

**What it means.** The test reported the EPG as invalid while the guide itself was

perfectly good -- you could open its address in a browser and see every station. Nothing

was ever fetched: the address was refused for being `http` rather than `https`, one line

after the check that accepts `http` for the service endpoint your username and password

are actually sent to.

IPTV providers serve XMLTV over plain http, usually on port 8080, almost without

exception, so this refused essentially every provider. On a real server the guide behind

the refused address answered 200 with valid XMLTV, and the host did not speak TLS on that

port at all (2026-09-25).

**What to do.** Nothing. Save the service and test it again; an http guide is accepted

for an http service.

**What has not changed.** A service reached over https still requires its guide over

https, so a secure connection is never quietly downgraded. An address that is not a web

address at all is still refused.

A search source you removed is still reported as broken

This was a fault and is fixed. A source whose key had been refused kept its refusal after

it was removed, so Connections went on saying **a search source will not accept its key**

for an account that no longer existed — naming it by a short string of letters and

numbers, because there was no longer a name to show.

A removed source now takes its refusal with it, and a refusal is only ever reported

against a source you still have.

If you see this warning, read the name in it. It is a source you still have saved, and

its key is genuinely being refused. Replace the key in **Search sources**; saving a new

one clears the refusal and it is tried again. Correcting the address does the same, which

matters because an address missing its `/api` path is a common cause — the indexer serves

a web page instead of a result, and the key looks wrong when it is not.

Nothing downloads, and nothing says why

This was a fault and is fixed. The downloader was being given a password under a name

it does not read, so it kept the one printed in its own public documentation and refused

GeekStream on every request. Nothing reported it: the downloader was healthy, the

dashboard was quiet, and downloads simply never started.

Installing now checks that the downloader accepts the sign-in GeekStream generated for

it, and stops with a plain message if it does not. A wrong setting name is silent by

nature — nothing reads it and nothing complains — so the install asks rather than assumes.

If you installed before this was fixed, run the installer again. It replaces the

credentials and checks them. Nothing you have saved is affected.

Your titles disappeared, and nothing was deleted

**What it means.** Settings has a **Library visibility** choice. Set to *Matched content

only*, it shows just the titles that currently hold a retained source receipt, and hides

every other authorized title across Film, Series, Music, Audiobooks and unlocked Unrated.

Live TV is unchanged.

On a real server this turned 78 visible films into 3 and a full Audiobooks shelf into 2

(owner, 2026-09-23). Nothing had been removed: the catalogue still held every title, and

switching back to *All catalog titles* restored all of them at once.

**What to do.** Settings > Library visibility > *All catalog titles* > Save. It takes

effect immediately; no restart, and nothing is re-imported.

**Why it is easy to meet.** Visibility and background retention are saved together, so

turning retention on asks you to choose a visibility policy in the same breath. Choosing

*Matched content only* before anything has been matched empties the shelves you already

had.

Audiobooks that match but never appear

**What it means.** A book could reach your shelf only if the posting's title spelled out

its format - `m4b`, `mp3`, `m4a`, `flac` or `aac` as a separate word. Most real postings

are named like `NMR-Stephen King - The Mist` and never say. Those were discarded even

though the posting was perfectly usable.

On a real server, 73 matched releases produced 2 usable ones, and those 2 were exactly

the two whose titles happened to contain `MP3` (owner, 2026-09-23).

**What to do.** Nothing. This is fixed, and books that were already matched become

available on the next matching pass.

**Why it will not happen again.** The format a book actually plays in is read from the

file once it arrives, never guessed from the posting's name, so the name is no longer

allowed to disqualify a source. A test now feeds in a posting that names no codec and

requires that it still be acquirable.

A section of your library fills up far more slowly than you expected

**What it means.** Wanting a title and finding it are two different things. Adding a

book, an album or a film to a section records that you want it; a background worker then

searches your indexers for it, slowly and in rotation, because every search is a real

request against an allowance that resets hourly and daily. A large section can therefore

sit for days with most of it never having been searched even once. Measured on a real

server, 2026-09-25: 64 of 77 wanted audiobooks and 102 of 289 albums had never been

searched at all.

**What to do.** Open that section and press the Build control in the top right of its

header - the circular arrow, to the left of the count. It says BUILD AUDIOBOOKS (or

whichever section it is) when you reach it. It runs that section's real search now,

shows you how far along it is and names the titles as they arrive, and it also moves that

section to the front of the background queue afterwards, so it keeps being favoured once

the screen has gone.

One press works for a few minutes rather than for ever - the allowances are still the

allowances - so a very large backlog takes a few presses across a few days. Titles that

have never been searched are taken before ones that are being retried, so each press

goes to new ground.

**Why it was worth saying.** The mechanism had always been there and the control had

never been put on a screen, so on a real server it had not been pressed once.

A television says playback is unavailable

**What it means.** The television shows one sentence for every possible cause, so it is

not, by itself, evidence of what failed.

**What to do.** Check the media endpoint's log first - it now records one line per

request with the status, the byte range asked for, how many bytes were sent, and how the

stream ended (`complete`, `capability_expired`, `client_disconnected`, or `refused` with

the state it answered). That line distinguishes a server that refused from a player that

gave up, which is the whole question.

**Why this needed fixing.** That endpoint previously printed nothing at all. The only

output it ever produced was a stack trace when a player closed its connection - ordinary

behaviour, since players disconnect to seek - which looked like a crash while a genuine

failure left no trace. Tracing one real report took hours and reached no answer for want

of a single log line (owner, 2026-09-23: "there's nothing in the debugging log").

A title will not play, and other titles do

**What it means.** A television only plays what its own chips can decode, and that is not

what the box it came in advertises. The owner's streaming box is sold as 4K and is 4K -

through HEVC, VP9 and AV1. Its H.264 decoder stops well short of that. Handed a 4K H.264

file it refused outright, and the screen said only that playback was unavailable

(owner, 2026-09-23).

**What to do.** Nothing, once your television has told the server what it decodes. The

server compares the actual streams in a file against that and takes the cheapest route

that works:

| what is wrong | what happens | cost |

|---|---|---|

| nothing | played untouched | none |

| only the container | remuxed, streams copied | very low |

| one stream, e.g. the audio | that stream converted, the picture copied | low |

| the picture itself | re-encoded to something the device decodes | high |

| no route at all | said plainly, instead of failing at the decoder | none |

**Why a release name is never used to decide.** Names are marketing. The streams are

fact, and the device is the only thing that truly knows what it can decode, so it is

asked rather than assumed. A television that has not reported yet is treated as modest -

1080p H.264 and stereo AAC - so an unknown device degrades to safe rather than broken.

**Why transcoding should be rare.** The server usually holds several sources for a title.

Choosing one the device can already play costs nothing and is always preferred; the

transcoder is the safety net for when no source fits, not the normal path. If it runs

often, that is a sign selection is choosing badly, not that it is earning its keep.

Your Live TV picks look like they never arrived

**What it means.** The television listed your channels alphabetically, and most IPTV

providers sign every channel they carry with the same label — `USA: ESPN`, `USA: TNT`,

`USA: MTV`. A label shared by the whole lineup sorts the whole lineup under one letter.

On a real server, 159 of an owner's 200 chosen channels wore that signature, so all 159

filed under **U**, behind the 41 the provider happened not to sign. Those 41 were the

Spanish-language networks, so the first screen was nothing but Spanish and ESPN sat at

position 85 (owner, 2026-09-24: "none of my 200 picks are showing"). Every channel was

being sent the whole time. The order was the only thing wrong.

**What it does now.** The signature comes off before anything is sorted or shown, and if

you have chosen a guide under **Live TV > Cable guide**, your channels are listed in that

guide's numbering instead of alphabetically — MeTV at 77, CNN at 202, ESPN at 206. A

channel the guide does not carry is still yours, so it follows the dial rather than being

dropped. That is the one way the guide differs here from the same guide used as a filter

on the dashboard, where an unrecognised channel is left out on purpose.

**What to do.** Nothing, if your provider signs its channels the usual way — it is

detected automatically. A label is only taken off when most of the lineup wears the same

one, so a channel genuinely named `Music Choice: Classic Country` keeps its name.

**Local stations.** A cable guide lists national networks; local affiliates belong to a

market, and no national list can know which market is yours. They are recognised from the

way a provider names them — `NY | New York ABC 7 WABC` carries the state, the city, the

network, the broadcast number and the call sign — and placed ahead of everything national,

the way a dial puts them.

Every market is recognised, which is 218 of them on one real provider, so you have to say

which is yours under **Live TV > Local market**. Until you do, no local stations are shown

at all — letting every market in at once put ten different channel twos at the top of the

dial and pushed an owner's own two hundred channels fifteen pages down. The guide dropdown

also offers each region twice: with local stations, for what a television should show, and

national only, for when five hundred stations from markets you will never watch are just

rows in the way.

Where a provider types the broadcast number into the name, that number is used. Where it

does not — `NY | New York CBS WCBS` — the station is placed by network instead, so it

still sits with the other locals but not on its exact dial position.

Channel logos arrive late, or stop arriving, as you scroll the guide

Every channel your provider sends carries a logo, and the television now draws it beside

the dial position. Two things make two hundred of them arrive quickly rather than one at

a time under your thumb.

**They are fetched behind the curtain.** While Live is counting up its percentage it is

also pulling every logo in the lineup into the picture cache, six at a time. By the time

the guide is drawn they are already on the television, so scrolling costs nothing.

**The television is allowed to keep them.** Everything else this server sends is marked

`no-store`, which is right for media and was wrong here: the server held each logo in

memory for an hour and then told every client to throw its copy away, so a row scrolling

out of view and back again meant another round trip and another decryption of the whole

registry to find the address. A channel logo is now sent `private, max-age=86400` with a

tag, so a television that already has it is told so in a few bytes instead of being sent

the picture again.

Logos only change when you re-import a lineup, and the tag catches that without sending

anything that has not changed.

The television loses its artwork all at once, but keeps showing some

Clear art, series art, music and audiobook covers all stop arriving together, while

whatever was already on screen carries on showing and a section or two looks fine. That

pattern is not an artwork fault. It is the television's authorisation having lapsed:

cached pictures keep drawing, and everything that needs a live request is refused.

The television renews its token every few minutes, and renewing rotates the old one away

the instant the server commits it. A television killed between that commit and writing

the answer down -- an app update, a crash, a set unplugged -- comes back holding a token

the server will never accept again.

There is a replay record for exactly this, so a retry under the same request gets the

same answer back. It used to last sixty seconds, which is shorter than the gap between

an app being killed and somebody picking the remote back up, so in practice it caught

nothing. It now lasts as long as the access token itself, and a television that comes

back within that time recovers on its own.

A television that has been off for longer than its token still has to be paired again.

Pair it from the dashboard in the ordinary way; **never clear the app's data**, which

wipes the pairing along with everything else.

Discover is offering things you cannot actually watch

A film still only in cinemas, or a series that premieres next month and has no episodes

yet, used to reach the hub. The horizon it was filtered by asked whether a title was

within a month of release, which answers "is this worth knowing about" rather than "can

I watch this tonight".

Two stricter rules apply now, and both were already being worked out for other reasons.

**A series needs an aired episode.** Its date carries the source it came from. When that

source is the last episode to air, an episode has aired and the show qualifies. A show

with no episodes falls back to its first air date, which for an unpremiered show is in

the future, and it is left off until that date passes.

**A film needs a home release.** The release decision is re-evaluated daily against the

metadata provider's regional release dates, and is only eligible once a digital or

physical release has actually happened -- so rentals, purchases and streaming count, and

a title in cinemas only does not.

A title that says nothing about any of this is still offered. Most of an owner's own

library carries no release information, and hiding it would be far worse than showing

something early.

An album sits on "preparing your album" and never plays

Pressing play on an album searches your indexers, takes a posting, and hands it to the

streaming engine. Three things used to make one indexer's bad day look like every album

being unavailable, and all three are worth knowing about because the symptom is the same

spinner.

**One indexer refusing is not the album being unavailable.** An indexer that has reached

its daily grab limit answers `429 Too Many Requests` to every fetch. That says nothing

about the posting and nothing about the album -- it is a counter resetting at midnight.

It is now taken as a reason to try the next candidate rather than as the failure.

**Candidates are tried one indexer at a time.** Matches arrive grouped by indexer, so

three attempts used to be three postings from the same one. They are interleaved, so the

second attempt is a different indexer's posting.

**A posting gets a turn, not the whole budget.** The engine knows within a second or two

whether it can fetch something. A posting that has not become playable inside its turn

hands over to the next one instead of holding the album until the operation times out.

**What was matched earlier is a head start, not the whole list.** When this server has

already found an album in the background, it remembers the posting each indexer offered,

and pressing play tries those first -- which is why a matched album starts in seconds and

costs no search. It used to try *only* those. On this server that meant most matched

albums had exactly one candidate, permanently: if that single posting had gone missing

from the providers, the album could not play, and retrying chose the same dead posting

every time. Now, once everything remembered has failed, it is forgotten and the indexers

are asked properly within the same press -- so the other few hundred postings of that

record become available. That happens once per press, not in a loop.

If every album still fails, check your indexers' grab counts for the day. Searches and

grabs are usually counted separately, which is why the app can find an album instantly

and still be unable to fetch it.

The library scrolled a little way and then jumped back to the top

Scrolling down a long wall of films got a few rows in and then lost everything and

returned to the beginning, or stopped dead with nothing below the last row.

This was the cursor, not the wall. Each page of a library row handed back a cursor, and

that cursor carried the library's revision -- a fingerprint of every row and every field

in all of them. The revision therefore changed whenever anything at all changed: a title

imported, a watch position saved, a piece of artwork arriving from the warmer. Any of

those, while somebody was reading, made the next page come back `library_changed`, and

the television did as it was told and started the row again from the top.

The cursor now records **which title you got to** rather than what the library looked

like at the time. Titles can be added, removed or renamed underneath somebody who is

reading, and the next page still continues from the right place; if the title itself has

gone, the old position is used instead of refusing. Nothing is served twice and nothing

between your position and the end is skipped.

The page stamp sent alongside it changed meaning for the same reason. It now says which

row a cursor belongs to and how that row is ordered, which is the question the television

is actually asking, and it does not move when the library's contents move.

**If a wall still stops short**, it is not this: check the row's total in the response

against what is on screen, and whether the response exceeded the two megabytes a client

will accept in one reply. A library row of two hundred and fifty films is about seven

hundred kilobytes, so that ceiling is not usually the limit.

The music wall loaded nine rows and stopped

Two thousand albums were being fetched thirty at a time -- seventy round trips for one

wall, each one a whole-library read on the server. It did not get to the end.

Both ends now ask for a wall at a time: the server accepts up to five hundred albums in

one reply and the television asks for two hundred and fifty, which is about three hundred

and fifty kilobytes and nine requests for the whole shelf.

A wall was black instead of showing its loading screen

A wall is covered while its pictures gather, and that curtain is deliberately skipped the

second time you open it -- stepping into a film and backing out arrives with everything

still in the image cache, and covering that up is a second of nothing for no reason.

What was missing was the difference between *seen before* and *ready now*. A wall that

had been opened earlier but had to fetch its contents again skipped the curtain and

showed a black screen while it worked. The curtain is now decided by whether there is

anything on the wall at this moment, so a return to a wall that is already full is still

immediate, and a wall with nothing on it says what it is doing.

A film dated next year was on the hub

The hub has refused unreleased titles since 2026-09-25, and the rule was right the whole

time. It was being asked to decide with the dates taken away.

Every library title reaches the hub through a field allowlist, and that list carried the

overview, the rating, the runtime, the genres, the cast and five kinds of artwork -- and

no dates, and no year. Measured on the running server: of 21248 films the hub allowed

through, **none** carried a release date and forty carried an air date. So a film stored

with `airDate` 2027-07-28 arrived at the gate as a film with no date at all, and a title

that says nothing is offered, by design.

That is also why the forty-five day wait for a film still in cinemas appeared to do

nothing after it was added. It was reading the same absent fields.

The allowlists now carry `year`, `airDate` and `releaseDate`, and the hub's own candidate

metadata carries them onward.

**If a title you cannot watch still appears**, check what is actually stored for it before

suspecting the rule: the gate refuses a date later than today, and refuses a year later

than this one. A title with neither is offered on purpose, because most of a real library

says nothing and hiding all of it would be worse than showing one film early.

The hub threw itself away while you were reading it

The same defect as the library rows above, on the Discover feed. Each page handed back a

cursor stamped with a hash of every item and every domain in the feed, so the stamp moved

whenever anything did -- a picture arriving from the warmer, a watch position saving, a

title enriched in the background. The next page came back 409 `stream_changed` and the

television discarded the hub and started at the top.

Measured on the running server on 2026-09-28: roughly **one request in four**, each after

four seconds of work. That is also why the hub felt jerky and why the server looked busy.

The feed is ranked rather than alphabetical and it re-ranks as shelves fill, so there is

no stable landmark to continue after -- the title you last saw can legitimately be

anywhere next time, including last. The cursor therefore keeps its position, clamped

rather than refused, and the stamp now describes which feed a cursor belongs to instead

of what the feed contained. At worst a title appears twice, and the television merges by

identity anyway.

A film played for a while and then stopped with a diagnostic

Particularly when entering a film part way through, and particularly on a large 4K remux.

The playback diagnostic shows `HTTP status: 206`, a correct `Content-Range`, a first frame

drawn, zero rebuffers, and then `ERROR_CODE_IO_UNSPECIFIED` with

`UnexpectedLoaderException > IllegalStateException`.

That exception means one thing: the body was shorter than the `Content-Length` it was sent

with. A player has no way to read that except as a corrupt file.

This server proxies the film's bytes. It announced the length upstream gave it -- fifty-two

gigabytes of it, for the case that was reported -- and then copied the body with no error

handling and no resume. The socket timeout is forty-five seconds, so on a body that size a

dropped read is a matter of time rather than an edge case; when it happened the copy simply

ended and the television was handed a truncated film. Resuming into the middle makes it

likelier still, because the long read starts immediately instead of building up to it.

The proxy now counts what it has actually delivered. When an upstream read fails it

re-opens the source at the next byte and carries on, up to six times, so the client never

sees a short body. If it genuinely cannot finish, it breaks the connection rather than

letting the player read a clean end it should not trust.

The television also gives a stream that drops two chances to be picked back up before it

gives up, and says "this stream stopped" rather than "playback could not start" when it

had plainly started.

**If a film still stops**, the diagnostic is the thing to read. `Requested Range` says

whether it was a resume; a `Content-Range` that does not match what was asked for points at

the source rather than at this server.

Comics were listed but nothing would open

Every issue failed with `No space left on device` while the disk had ninety-three

gigabytes free.

`/tmp` inside the container is a **16 MB tmpfs**. An issue's archive was downloaded into

it before being unpacked, and `MAX_ARCHIVE_BYTES` allows 512 MB, so no comic was ever

going to fit. Seventy-eight downloaded issues sat unreadable.

Archives are now staged in `comics-staging` under the state root, on the same filesystem

as the pages they become -- which also makes the unpack a local write rather than a copy

across devices.

Two things made this hard to see, and both are worth remembering:

**The dashboard was reporting it as a feature, not a fault.** The check said comics had

"no way to ask for them and no reader to open them yet. This is unfinished work, not a

fault on your server." Both halves had stopped being true -- the routes and the reader

exist -- but the sentence was hardcoded, so a real failure read as something nobody had

built yet. That check now counts what is actually readable.

**`df` on the host tells you nothing about this.** The host showed 53% used. The 16 MB

limit is a mount inside the container, so look with

`docker exec geekstream-manager-1 df -h`, not from outside.

**If comics still will not open**, check the archive is actually where NZBGet says: the

shelf only lists issues whose download finished, but the file itself is read back out of

NZBGet's completed folder at the moment you open one.

"Start again now" on the Discover backlog did nothing

Because it was wired to the wrong repair. The finding offered `clear_lane_waits`, which

clears pauses on the **music** matching lanes and does not read or write anything in

Discover. Pressing it ran, reported success, and changed nothing.

The button is now `requalify_discover`, which checks every waiting pick against the titles

this server already knows and drops any that are past their thirty days.

**Why the backlog grows at all** is worth understanding, because it is not a queue being

worked through. A pick is shown once the same title exists somewhere this server already

knows about. Nothing goes hunting for one. So a pick for a book or album you do not own

waits until it arrives some other way, or until it expires. Ninety-six waiting against

twenty-nine shown is that, not a stall.

Making them actually arrive means putting them on a wanted list, which downloads them.

That is a deliberate choice about disk, not something a button called "check them again"

should do on its own.

"No sources" on albums and audiobooks that plainly exist

Three shelves came back empty for different reasons, and all three reported the same

thing to the owner: no sources. That wording points at your indexers, which is why it

kept being the wrong place to look.

**Music — an album's edition was treated as a different album.** A posting's album field

carries the release, not the work: "OK Computer OKNOTOK 1997 2017", "Nevermind (320)",

"Rumours 35th Anniversary Edition". That field was compared for equality and used to

refuse the posting outright. Fifty of fifty results for OK Computer were thrown away on

it, with eighty-seven FLAC copies visible in the titles. Metadata now confirms and ranks

a match and never refuses one; the title naming the artist and album is what decides.

**Audiobooks — the search asked the one category nobody files them in.** Every indexer

declares a `3030 Audiobook` category and posts almost nothing there. Measured: Pet

Sematary returns 0 results in 3030 and 16 with no category filter, all of them under

7000/7020, Books and Ebook. `ebook` had also been struck out of every scope, so the one

shelf holding them was the one shelf that was skipped. Books are searched now, and

anything from them must state an audio format so ebooks stay off the shelf.

**A warm cache can hide a fix like these.** Category routing is cached for a week, so

changing how categories are classified changes nothing until the cache is replaced. Cached

answers now carry the rules version that produced them. **If a routing change appears to

do nothing, check `rulesVersion` on `indexerCategoryDiscovery` before looking anywhere

else** -- and bump `ROUTING_RULES` whenever `parse_caps` classifies differently.

**How to tell these apart quickly.** Ask the indexer directly with no category filter and

count what comes back. Results with no filter and none with one is a category problem.

Plenty of results and none surviving our matcher is a matching problem. Nothing either way

is genuinely nothing.

Plex connects from home but not from a hosted server

Symptom: GeekStream tries an address like `172.18.0.5:32400` — a private address that

only exists inside the machine Plex is running on — and the connection fails with no way

to try another.

Plex hands out a `.plex.direct` hostname for **every** connection it knows about,

including ones only reachable from its own host. The address is spelled into the

hostname: `172-18-0-5.<hash>.plex.direct` resolves to 172.18.0.5. Routes were sorted

local-first, so that was the first one tried.

Local-first is right for the owner's **browser**, which is usually on the same network as

the Plex, and the browser routes still do it. It is backwards for the **server**, which is

typically somewhere else entirely — and for a Plex on a different host, a private address

cannot work from anywhere but that host.

Routes are now ordered by what this server can actually reach: public addresses and the

Plex relay first, private ones last. Nothing is dropped, so an owner running GeekStream on

the same network as their Plex still gets the local address, just not before the ones that

work from further away.

**If Plex still will not connect from a hosted server**, check whether the account lists

any non-local connection at all. A Plex with no public address and no relay enabled has

nothing a remote server can reach, and the fix is in Plex's own settings — enable Remote

Access or the relay.