Repository navigation
Backlog
A list kept up to date of what remains open on the catalog and on the
definitions. The status entries (da-provvi, bloccata, morta, degradata)
live in index.json and sites.yaml; here there is only what is not
already classified, with the evidence and how to verify it.
Last updated: 2026-10-30.
Live sites that changed something: the definition stays in the catalog but is
degradata (not offered to the user) until someone re-reads the page.
| Definition | What changed | Evidence |
|---|---|---|
torrentbyte |
Cloudflare no longer opens even with the solver | home 403, the solver returns a 403 Forbidden page of 698 bytes; 0 rows |
torrentsome |
the CSRF search responds 400 (it worked on 25/10) |
POST /topic/index with _csrf + keywords → 400; the home page responds 200 with 108 KB |
Verification: go run ./cmd/... is no longer enough; a live test of the
definition is needed (reach + search) with the local FlareSolverr.
| Item | Problem | What is needed |
|---|---|---|
rintor |
the definition works on www.rintor.net (POST /), the queue row uses rintor.org, which serves a different theme and the login page |
decide whether rintor.org is a mirror (then it must be re-read and adapted) or another site (then the row is left as is and the definition stays on .net). Today the row stays in the queue because of a host error, not a code error |
| Definition | Why | What is needed |
|---|---|---|
btdirectory |
download.resolve_on: search opens up to 4 detail pages during the search: it exceeds 90 s |
evaluate resolve_on: grab, or reduce max_concurrent, measuring before/after |
mixtapetorrent |
same pattern, 45-55 s per search | as above |
None of these can be verified without an account: the da-provvi status is
the right one and must not be forced to bloccata.
| Group | Sources | Note |
|---|---|---|
| Semi-private | 57 | 52 declare username/password (or cookie), 4 show the login page (AniDUB, Erai-Raws, RuTracker.org, UniOtaku), 1 is a series site with no torrents for guests (LostFilm) |
| Private | 439 | reachable or with login, no verification possible without an account |
| Private drafts | 11 | definitions to complete, the settings are needed |
With an account the path is: session (vault), search observation, detail and
grab, real fixtures, definition verificata.
| Item | What is open | Evidence / verification |
|---|---|---|
ddunlimited |
the forum responds 200 with the «Informazione» page when flood control blocks the search. Live search now uses the local index (TV t=61463, movies f=1988 by letter) and search.php remains only the fallback; the TV list is however the list of reports, not all releases: old series fall back to search.php. Since 2026-10-29 the TV list is read across all three pages of the topic (next), 15,028 titles instead of the 6,521 of the first page, which only went from # to H; it remains to measure how many queries are left uncovered. Since 2026-10-27 the comparison is by word start (before it was by substring: «It» matched «Hitman» and skipped the fallback) and book/music searches do not read the index. Since 2026-10-28 a TV search with a season skips index topics naming another season (including a free search such as «Bones S06E05», the one from Gextto's manual search: before it gave 0 eD2k, now it opens «Stagione 6»), file names read by the filearray script no longer carry HTML entities (L'amore), a file that names the episode (Bones.S06E12…, Bones - 6x12 - …) is published with only the file name (with the topic in front, Gextto read the series «BONES - Stagione 6 - Bones» and never matched it to the followed series), and a free search with S06E12 or 6x12 uses the same season/episode filter as tvsearch («Fallout 1x01» 0 → 131 titles, «Bones S06E12» 40 → 74, A/B against d7837d9 119% on the average of two runs), and if the forum drops the session (same account logged in from another browser: the topic responds 200 as a guest, without links) auth.logged_in makes it log in again once and re-read the topic; it remains to see live a double login in the log when the user logs in from the browser |
two search.php requests close together: the second contains «Non ti è permesso di utilizzare il sistema di ricerca» and 0 a.topictitle; the page viewforum.php?f=440 produces 25 topics and 49 eD2k links in 69 s; tests TestDDUnlimitedLogsInAgainWhenTheForumDropsTheSession and TestIndexSkipsTopicsOfAnotherSeason; the TV list contains 6,521 a.postlink-local links |
| DDUnlimited coverage | review on 2026-10-28 of the 26 titles missing in Gextto: eD2k only for 9-1-1, Dark Matter, FBI, FBI: International; 0 for Scrubs S02, New Tricks, I misteri di Murdoch, Walker, Strike. Causes measured on 2026-10-28: (1) New Tricks and Murdoch are not in the TV list t=61463, so they go through search.php (fixed on 2026-10-29: they are there, on page 2 of 3, and Silo, Scrubs, Walker and Strike on page 3; the engine read only page 1, from # to H, and sent all series from I to Z to flood control. Now it follows «Prossimo»: «Silo» S03 live 30 eD2k files in 17 s without search.php, TestIndexFollowsTheNextPageOfAList); (2) the search.php flood control responds 200 with «Al momento non ti è permesso fare ricerche»; (3) the same account logged in from another place drops the session. Since 2026-10-28 search.cache: 6h, search.blocked (visible error instead of silent 0 results), a new login also from the search page and no topics from other seasons. Live after the upgrade (04:10–06:52): 222 DDUnlimited searches, 37 ok, 185 errors; 166 were flood control, but 20 were the «Nessun argomento o messaggio con questo criterio di ricerca» page and 1 «le seguenti parole sono state ignorate», taken as refusals because they use the same #message p box: now blocked.contains: "non ti è permesso". Gextto's free searches for the missing titles («I misteri di Murdoch S13E01», «… S13») sent the marker to search.php with terms=all and always gave «Nessun argomento»: now the request uses query.keywords_title (title without the marker) and the season/episode filters read the full query. Interval measured on 2026-10-28 at 07:40 with searches for real words (invented or overly common words do not count for the forum): accepted at 58 s from the previous one, refused at 55 s, accepted at 70 s; a refusal does not restart the count (the 3 concurrent ones at 06:30:45 pass because the forum checks the time of the last search before updating it). Hence search.interval: 65s with a background queue and cache: 12h: the searches of a Gextto cycle without a turn no longer go to the site but into the queue (at most 55 per hour), and the next cycle reads them from the cache. Tried live on 2026-10-28 with bursts of 6 concurrent searches: no forum refusals after the fixes (single lane with the interval measured from the previous response, estimate never below zero after a restart); with an isolated probe 4 queued searches started at 09:04:33, 09:05:39, 09:06:46 and 09:07:52, all accepted. Still open: (a) in the service, after 5.5 minutes only 1 of the 5 queued searches was in the cache and one (Meteorologia) never got there: the background worker did not write to the history. Since 2026-10-28 every send writes a search row (TestDeferredSearchSendIsRecordedInHistory): in the burst of 6 searches at 09:38, in the queue three sends were accepted at 65 s (09:53:33, 09:55:18, 09:56:28) and the next two refused (09:58:02, 09:59:20), so the cause of «never arrived» is the forum refusal, not a separate lane; with two attempts the page was discarded during the block, now the worker retries at most twice with a pause of four intervals (about 4m20s) before spending another turn (TestDDUnlimitedBackgroundSendRetriesPastABurstBlock), so as not to hammer the forum; it remains to measure over two Gextto cycles how many searches are «ok» from the cache compared with the 37 out of 222 before; (b) «Murdoch Mysteries» (the English title, Sonarr's) gives 0 because the forum uses the Italian title; (c) coverage retry on 28/10: Scrubs S02 two ok searches (127.8 s and 4.6 s) with 0 results, so flood is not involved and the search.php fallback finds no topics; Walker S01 refused by flood at 10:14 (84 s); Strike S01 one ok search (115.9 s) with 1 result. The manual tests stop here to avoid risking the account: the application queue covers the other items; (d) «Murdoch Mysteries»: evaluated, not done. indexarr has no TVDB/TMDB client or alternative-title mechanism; adding one requires API keys and another flood turn for each variant, while Gextto already has the «I misteri di Murdoch» alias and can send it as a separate query. The item stays open until it is decided whether the cost is worth the coverage |
TestDDUnlimitedSearchCacheFloodControlAndGuestSearch (refusal, no results, marker removed), TestDDUnlimitedFloodIntervalQueuesTheSearchesWithoutASlot, TestKeywordsTitleDropsTheEpisodeMarker, TestDropTopicsOfAnotherSeason; live: in the DDUnlimited indexer history no «search refused by the site: Nessun argomento…» error and the queries for the missing titles without S13E01; count select status,count(*) from indexer_history where indexer_id=51 and started_at > … (the «canceled» ones are the queued searches) |
| files without resolution | the …ITA.DLMux.x264-UBi.mkv files do not state the resolution. Since 2026-10-28 (Gextto 1.1.2060) Gextto takes them as «🆘 ultima risorsa» when a missing episode has no copy in the profile; it remains to evaluate whether indexarr should report the topic's resolution in the title |
Gextto probe of 2026-10-28: FBI.International.3x01.June.ITA.DLMux.x264-UBi.mkv → lastresort=true, the other 38 English copies discarded; live: «🆘» row in Gextto's log |
| seeders refresh | since 2026-10-28 SeedersCandidates only selects protocol = 'torrent' rows: eD2k/Usenet releases have no swarm and the refresh redid a title search on DDUnlimited (flood control). It remains to check in the log that the refresh no longer touches the DDUnlimited source |
TestSeedersCandidatesSkipReleasesWithoutSwarm; live: no DDUnlimited search.php request from the seeders job after the upgrade |
| deferred search queue | since 2026-10-29 (6cb397f) the queue is saved in indexer_pending_searches (migration 21) after every change, the page being sent included; Close (also at shutdown) keeps the saved copy and the next process resumes it at startup; pages older than search.cache are dropped. Before: 43 of 374 DDUnlimited deferred searches in three days were lost at one of 22 restarts. Still open: a resume seen live (a restart while the table holds a queue) |
TestDDUnlimitedDeferredQueueSurvivesARestart, TestDDUnlimitedResumeDropsStalePages, TestPendingSearchesRoundTrip; live: select indexer_id,json_array_length(queue_json) from indexer_pending_searches, then restart and look for «indexer: resumed pending searches» in the journal and the queue going back to empty |
| Item | What to watch |
|---|---|
| infohash recovery | until 29/10 the job opened MirCrew topics in the background (download.before: it thanked about 10 topics per run on the account, 120 downloads from jobs in 48 hours) and Smartfeed topics with the feed connector (173 «pending topic» errors since 28/10). Since 29/10 it skips them: first run after the upgrade attempted=40 recovered=39 failed=1 skipped=295 (before 21-41 failed out of 60) and no download rows on MirCrew and Smartfeed. Evidence: TestEnrichNeverThanksATopicOrOpensAnotherIndexersReference; live select indexer_id,count(*) from indexer_history where kind='download' and app='' and indexer_id in (15,50) and started_at > <deploy> group by 1 must remain empty |
| pause after a flood refusal | on 29/10 DDUnlimited refused all searches from 02:06 to 03:29, one every 5.5 minutes. Now the pause doubles at each consecutive refusal (4, 8, 16, 32 intervals) and a live search during the pause is queued without touching the site. Check in the history that consecutive refusals are spaced further and further apart and that no live search waits more than a minute for a refusal. Evidence: TestSearchRefusalPauseDoublesUpToTheCap, TestLiveSearchDuringARefusalPauseIsQueuedWithoutTouchingTheSite; select started_at,status,latency_ms from indexer_history where indexer_id=51 and kind='search' and status<>'ok' order by id desc
|
torrentgalaxy, torrentgalaxyclone
|
since 2026-10-28 at 21:27 torrentgalaxy.one responds NXDOMAIN (also on 1.1.1.1): the 13 per-uploader sources and the clone failed on every run (176 errored clone searches in 12 hours) with a request failed without a cause. Since 2026-10-29 the connector moves to the next mirror in meta.urls when a domain disappears (TestConnectorMovesToTheNextMirrorWhenTheDomainIsGone), torrentgalaxy.yaml has the torrentgalaxy.info mirror (same page: 50 tgxtablerow rows on /get-posts/user:ppb1/) and the error names the cause (request failed: no such host). Watch that the run rows of the TorrentGalaxy sources return ok: select status,count(*) from indexer_history where indexer_id between 16 and 28 and kind='run' and started_at > <deploy> group by 1. If .one comes back, the connector stays on the mirror as long as this one responds; since 29/10 the cycle is circular (if .info dies it goes back to .one) and it also triggers on Cloudflare «origin down» pages (502, 504, 52x, 530): TestConnectorGoesAroundTheMirrorsWhenTheOriginIsDown. Since 29/10 a source on a working mirror no longer shows as faulty: each address has its own breaker (<slug>@<host>), the indexer's records the outcome of the whole run and triggers only if all fail (TestDeadAddressDoesNotOpenTheIndexerBreaker, TestCircleSkipsAnAddressInHostBackoff), the run sample keeps the mirror's response (TestRunSampleKeepsTheMirrorThatAnswered), the indexer page shows «in use: » and the catalog's «Prova» tries all addresses (TestCatalogProbeTriesTheMirrors). torrentgalaxy.info is now the first address in both definitions. The TorrentGalaxy RSS feeds configured inside Gextto do not go through indexarr and do not have this cycle
|
| catalog mirrors | review on 29/10 of the 28 addresses of the 13 definitions with the most urls: limetorrents.zone had become a betting site (removed), torrentgalaxy.one is still NXDOMAIN (now second behind .info in the clone), solidtorrents.eu added to Bitsearch (same search, 24 results for «ubuntu» like bitsearch.eu). Open: (a) the official mirrors of 1337x (1337x.to, .st, x1337x.ws/.eu) and of Kickass (kickass.ws, katcr.to, kickasstorrent.cr) respond only with the Cloudflare check and have not been compared with the page in use (the check via FlareSolverr is denied by the permission check); moreover 1337x.to uses a search path different from 1337x.tube (/search/<q>/1/ versus /search/?q=), so as a mirror it gives no results; (b) thepiratebay.org is not a mirror of apibay.org (/q.php redirects to the HTML home); (c) family connectors (unit3d, nexusphp, xbtit…) have a single address, but no active source uses them |
iptorrents |
the session is tied to the browser (Cookie + User-Agent) and expires: the Import cookie button reads the computer's Firefox profile with the browser and refreshes it (one-time token, /pair); search.blocked recognizes the login page and the search fails with «the IPTorrents session cookie has expired» instead of giving 0 results. The columns depend on the site profile (Torrents per page 100, Show files count on, Category column Icons): if the layout changes, the definition must be re-read. |
torrentleech session |
in the 24 hours up to 29/10, 239 failures out of 594 queries: 110 searches in 10 minutes (28/10 13:47-13:57) with «invalid character '<'» (HTML login page instead of JSON) and 130 background downloads (infohash recovery, in groups of 10 from 10:00 on 28/10 to 01:00 on 29/10) with «no download target», which ended only after the 03:00 restart. The site drops the session before refresh_after: 6h. Since 29/10 auth.logged_in (logout link) makes it log in again once and re-read; a JSON response always counts as a valid session. Watch that error groups do not come back: select status,substr(error,1,60),count(*) from indexer_history where indexer_id=6 and started_at > <deploy> group by 1,2
|
mircrew health query |
the periodic health job reports health query "Reacher" returned 0 items, want at least 1 while normal searches work (live: 4 warnings, last on 29/10 15:34). Check whether the site's search page no longer returns “Reacher” for the health query or the query needs changing in health.query. |
torrentby |
uses meta.insecure_tls: true because the server does not send the Let's Encrypt intermediate YE1. If the chain becomes complete again, remove the flag (and the badge) |
u3c3 |
the search depends on the site's fixed search2 token: if it changes, the search returns the home page instead of the results |
rutracker |
the search goes through a FlareSolverr session: if the site stops responding even to the browser, the definition must be marked degradata
|
| Item | What remains open | Evidence |
|---|---|---|
| per-channel notifications | events are global: every configured channel receives all enabled events. An event × channel matrix like Prowlarr's is missing. | the UI has a single block of event checkboxes; internal/store/settings.go has no channels/events table |
| SMTP | supports STARTTLS, not implicit TLS on port 465. | test TestSMTP... and comment in internal/notify/channels.go
|
| manual live search | shows at most 50 rows and hides normal pagination; indexers that time out continue in the background and require a reload to see the results. |
internal/web/live_search.go, TestLiveSearch...
|
| per-indexer client | the client is chosen per protocol (torrent/usenet/eD2k), not per individual indexer; priority/round-robin among clients of the same protocol is missing. |
store.DownloadClientForProtocol; the indexer form has no client field |
| named *arr profiles | the profile is per application (RSS, automatic/interactive search, min seeders, categories), not a reusable profile with a name like in Prowlarr. |
applications schema and /applications/{id}/edit form |
| native Usenet | the generic Newznab path is complete, but the catalog has no native definitions for individual Usenet sites. |
internal/catalog/index.json: 0 verified usenet entries, 1 draft |
| ilDraGoNeRo redirect workaround | since 2026-10-29 (9c9c163) the transport applies the cookies each redirect sets to the next hop and the connector stores the cookies of every hop, so a phpBB login answered with a 302 no longer lands on the guest index. ildragonegro still posts an invalid redirect (the workaround that made phpBB answer 200): it can go back to the login page's own redirect field, but that path has not been tried live |
TestFormLoginFollowsARedirectWithTheNewSession fails without the fix with «login failed: HTTP 200», the same symptom measured on ilDraGoNeRo; TestTransportRedirectAppliesTheCookiesItSets. Live after the upgrade on 2026-10-29 18:12: fresh-session Test ok on TorrentLeech (login 403 ms, 100 items) and ilDraGoNeRo (login 4972 ms, 15 items). To close: switch the definition to the extracted redirect, Test the indexer, check mode=logout on the page after login |
| cookie as a login alternative | since 2026-10-29 every form-login definition run by the engine (TorrentLeech, MirCrew, DDUnlimited, ilDraGoNeRo, example-html) gets an optional session cookie: either username and password or the cookie is enough, the cookie wins when both are set and, when the site drops its session, the connector signs in with username and password (without them the search fails with «the session cookie pasted from the browser has expired»). Since 2026-10-29 (9c9c163) MirCrew has auth.logged_in too: live, after the upgrade, 3 searches (Reacher 50, The Last of Us 30, Silo 50 rows) sent 6 search.php requests and no extra login through FlareSolverr, so its search page carries the logout link. Still open: (a) the nexusphp, torrenttrader and xbtit family connectors do their own login and do not read the cookie, so they are not offered it; (b) not yet tried live with a real browser cookie |
TestPastedCookieReplacesTheLogin, TestExpiredPastedCookieFallsBackToTheLogin, TestFormLoginOffersTheCookieAsAlternative, TestPastedCookieIsEnoughOnTheOverview; `docker logs --since 15m flaresolverr |
| live search texts | the Settings label «Search indexers live on a cache miss» and its help «Off by default» contradict the code: the default is on (DefaultSettings, TorznabLiveSearch: true) and the fan-out runs on every request with a query, not only on a cache miss (internal/torznabapi/server.go:419). The README was corrected on 2026-10-29; the UI text in the 7 languages still says the old thing |
settings.liveSearch and settings.liveSearchHelp in internal/i18n/locales/*.json; verify with the Settings → Advanced page |
| system installer | since 30/10 ./install.sh --system writes /etc/systemd/system/<name>.service, creates the service account when missing and installs /usr/local/bin/indexarr. Only the dry run was exercised on this host (no passwordless sudo), so a real system install and uninstall are still to try. |
sudo ./install.sh --system --dry-run prints the unit; live: sudo ./install.sh --system --name indexarr-test --data-dir /var/lib/indexarr-test --listen 127.0.0.1:18788, then sudo ./install.sh --system --name indexarr-test --uninstall
|
| SOCKS4 | IPv4 destinations only; SOCKS4a resolves and validates the name locally instead of delegating DNS to the proxy. | internal/engine/socks4_test.go |
| shutdown with an active request |
http.Server.Shutdown waits 15 s; a long import, backup or export still running makes it return context deadline exceeded, and the process closes anyway. The client loses the response without a translated message. Measured on 29/10 at 16:15, 16:17 and 18:13: three WARN msg="HTTP shutdown" error="context deadline exceeded". |
cmd/indexarr/main.go shutdown block; live grep 'HTTP shutdown' data/logs/indexarr.log
|
| notification script | arguments are space-separated with quote support, without shell expansion or variables. |
internal/notify/channels.go, script test |
| grab digest on shutdown | the grab burst is collected in memory for 8 s; a restart inside that window loses the pending grab-success notification. A flush on shutdown is still missing. |
internal/notify/notify.go (DispatchAsync, flushGrab); test TestGrabBatchIsFlushedAsOneEvent
|
| FlareSolverr orphans of removed definitions | since 30/10 the global reconcile closes every session whose ownership prefix is known — the default indexarr- namespace and the name_prefix of the stored definitions — 30 s after start and every two minutes. Open: a definition with a custom name_prefix removed from the store while indexarr is stopped leaves its session behind after the restart, because the prefix is not persisted; two indexarr instances sharing one FlareSolverr also close each other's sessions, as gextto already does. |
internal/indexer/indexer.go (ReconcileSessions, seedSessionPrefixes), internal/engine/definition_session.go (SessionRegistry.ReconcileSessions); TestReconcileSessionsClosesOrphansFromAPreviousRun, TestSessionRegistryReconcileClosesOnlyOwnedOrphans; live: leave a session named indexarr-test-000000 in FlareSolverr, start indexarr, after ~40 s sessions.list must not contain it |
| copy link on old downloads | since 30/10 the Download tab copies the magnet, eD2k link or .torrent link of a grab, and every new magnet delivery is stored on the release (releases.magnet). Open: grabs recorded before the change whose listing carried only a sealed reference have no stored link (the ilDraGoNeRo grab of 29/10 is one), so their chip stays a plain label; recovering it would re-run the site's grab step (on ilDraGoNeRo it thanks the forum post again), which must not happen from a statistics click. |
internal/store/useful.go (ListGrabs), internal/torznabapi/server.go (SetReleaseMagnet on a magnet grab), internal/web/logs_section.go (grabCopyLink); TestLogsDownloadsSourceFilterAndCopyLinks, TestDownloadLinkStoresTheResolvedMagnet, TestListGrabsCarriesTheReleaseLink; live: grab a magnet release, then /activity?tab=downloads&window=all must show a clickable magnet chip |
| Queue | Sources |
|---|---|
| Public to write | 0 |
| Public blocked / dead | 12 / 3 |
| Public drafts | 12 |
| Semi-private to try | 57 |
| Private to try | 439 |
How to re-check the numbers: go generate ./internal/catalog and then
docs/CATALOG.md (the "Numbers as of 2026-10-29" table) plus the maintenance
view /indexers/new?queue=1, which shows the queue composition and the reason
for each blocked row.
indexarr
Guides
APIs
Sources
Operations
Project