Book lookup returns only audiobook editions, so the /ebook facade scope is always empty

[kukitch]

Book lookup returns only audiobook editions, so the /ebook facade scope is always empty. Every result across four titles comes back mediaType: audiobook / isEbook: false, in both the gr and hc dialects, on a fresh install with an Ebook metadata profile and an E-Book quality profile present.

Is ebook metadata expected to work today? I could not tell from the docs whether this is not-yet-implemented, a provider limitation, or something misconfigured on my side, and the answer changes whether I keep an ebook library pointed at Chaptarr at all.

Version

0.9.911.0, branch develop, docker chaptarr/chaptarr:latest on linux/arm64 (Apple M4, OrbStack). Fresh install, 2026-08-17.

What I measured

Same API key, GET /api/v1/book/lookup?term=..., result counts:

base URL	dune	the martian	educated	project hail mary
/readarr/gr/ebook	0	0	0	0
/readarr/hc/ebook	0	-	-	-
/ebook	0	-	-	-
/readarr/gr/audiobook	5	5	5	4
plain /api/v1	5	-	-	4

The plain endpoint appears to explain the empty scopes, term=dune:

'Dune (Dune, #1)'         mediaType: audiobook   editions: 1   isEbook: [False]
'Dune Messiah (Dune #2)'  mediaType: audiobook   editions: 1   isEbook: [False]
'Children of Dune (#3)'   mediaType: audiobook   editions: 1   isEbook: [False]

Every edition returned is an audiobook, so ServarrMediaTypeScopeMiddleware has nothing to scope to on the ebook side.

Configuration, in case it is mine

• Metadata profiles are the shipped defaults: Audiobook Default (profileType: 1), Ebook Default (profileType: 2), None.
• Quality profile E-Book allows Unknown Text, PDF, MOBI, EPUB, AZW3.
• Two typed root folders: folderType: 2 for ebooks, folderType: 1 for audiobooks. Both report accessible: true.

So the ebook side looks configured, which is why I suspect the metadata service rather than my setup. Happy to run anything else useful, or to move this to a discussion if it is a known limitation.

Separate, and possibly worth its own issue

The Readarr-compatibility shim looks unreachable for POST /author. ApplyFacadeAuthorSingleFields maps rootFolderPath -> ebookRootFolderPath and qualityProfileId -> ebookQualityProfileId in the action body, but the FluentValidation rules that reject a legacy-only payload run as an action filter first. A stock Readarr-shaped client posting to /readarr/gr/ebook/api/v1/author therefore gets a 400 with "At least one quality profile must be selected" plus Invalid Path: '{path}', and the mapping never executes. Verified against the facade route on the version above. I worked around it by sending the per-format keys directly. Say the word and I will open that separately.

Thanks for picking this project up after Readarr was retired, the audiobook side has been working well here.

[kukitch]

Follow-up with a symptom that may be the actual cause, found after filing.

GET /api/v1/search fails outright with Hardcover search failed, on every term I tried (dune, educated, project hail mary), same version 0.9.911.0:

{ "message": "Hardcover search failed" }

The log shows it throwing from the metadata proxy rather than from anything local:

NzbDrone.Core.Exceptions.NzbDroneClientException: Hardcover search failed
   at NzbDrone.Core.MetadataSource.BookInfo.BookInfoProxy.SearchForNewEntity(String title, String provider)
      in ./Chaptarr.Core/MetadataSource/BookInfo/BookInfoProxy.cs:line 2346
   at NzbDrone.Core.MetadataSource.BookInfo.BookInfoProxy.SearchForNewEntity(String title)
      in ./Chaptarr.Core/MetadataSource/BookInfo/BookInfoProxy.cs:line 2274

So the two metadata paths behave differently here:

path	result
goodreads (/readarr/gr/..., book/lookup)	works, but returns audiobook editions only
hardcover (/api/v1/search, /readarr/hc/...)	fails, or returns 0

If Hardcover is the source that carries ebook editions, that would explain the empty /ebook scope in the original report better than anything I suggested there: it may be one broken provider rather than a missing feature.

I also confirmed the mediaType query parameter behaves identically to the URL prefix, so this is not a routing question on my side:

/api/v1/book/lookup?term=dune                        -> 5 results, all mediaType: audiobook
/api/v1/book/lookup?term=dune&mediaType=ebook        -> 0 results
/api/v1/book/lookup?term=dune&mediaType=audiobook    -> 5 results

No Hardcover credential is configured anywhere in my instance, and I could not find a setting asking for one, so if that provider expects a token this may simply be an unconfigured-and-unreported state rather than an outage. Happy to test a fix or grab more logs.

[kukitch]

Correction to my own report, and it narrows this issue considerably. Ebook acquisition works fine. Only the metadata scope is empty. I should have tested the full path before filing.

With an author added using the shipped E-Book quality profile, an interactive release search returns ebook releases and accepts them:

Project Hail Mary by Andy Weir AZW3   quality=AZW3  4.6MB  117 seeders  rejected=false
Project Hail Mary by Andy Weir EPUB   quality=EPUB  9.4MB  386 seeders  rejected=false
Project Hail Mary by Andy Weir EPUB   quality=EPUB  9.4MB  129 seeders  rejected=false

Grabbing one imported cleanly to the ebook root:

/data/books/ebooks/Andy Weir/Project Hail Mary/Project Hail Mary by Andy Weir.epub

So EPUB and AZW3 parse correctly, the quality profile selects them correctly, and import files them under ebookRootFolderPath correctly. None of that is broken.

What remains is narrower than my title suggests: book/lookup returns editions tagged mediaType: audiobook regardless of format, so the /ebook facade scope and ?mediaType=ebook both return zero results. The practical effect is that a client cannot browse or search the ebook catalogue, but a book added through the plain API with an ebook quality profile behaves correctly all the way to disk.

Two things that might help narrow it further:

• The Hardcover search failed exception in my earlier comment still stands, and if Hardcover is the source carrying per-format editions that would explain the audiobook-only tagging.
• Every edition I have seen from the goodreads path has isEbook: false, including for books that clearly have ebook editions, so the tagging may be defaulting rather than being resolved per edition.

Apologies for the overclaim in the original title. Happy to retitle or close this in favour of a narrower one about edition media-type tagging, whichever is more useful to you.

[sebclark]

Reproduced on a second instance — 0.9.929, different account, long-established install: book/lookup?term=dune returns 5 results all mediaType: audiobook / isEbook: false, mediaType=ebook returns 0, and /api/v1/search returns the same Hardcover search failed. Same behaviour across two versions and two accounts points at the metadata service rather than local config — possibly related to the server-side upgrade work mentioned on Discord, if the Hardcover search path is part of what's being reworked.

[snapetech]

I traced this through the source and reproduced it against the 0.9.911.0 Docker image.

For term=dune I get:

• /api/v1/book/lookup -> 5 results, all mediaType: audiobook
• /api/v1/book/lookup?mediaType=ebook -> 0
• /readarr/gr/ebook/api/v1/book/lookup -> 0
• /readarr/gr/audiobook/api/v1/book/lookup -> 5
• /readarr/hc/ebook/api/v1/book/lookup -> 0
• /readarr/hc/audiobook/api/v1/book/lookup -> 5

The empty ebook response looks like a lookup bug in Chaptarr rather than a Seerr configuration problem:

1. BookLookupController.Search parses mediaType, but calls SearchForNewBook(term, null) without passing the requested type.
2. That path uses the legacy Goodreads autocomplete search.
3. CreateBookFromSearchResult creates a Book without setting MediaType.
4. Book.MediaType defaults to Audiobook.
5. The controller then applies Where(b => b.MediaType == requestedMediaType), which removes every result for an ebook request.

Relevant source: BookLookupController, SearchForNewBook, search-result mapping, and the Audiobook default.

This also appears separate from the /api/v1/search Hardcover error. That path requires a Hardcover token, and I did not treat the absence of one as proof that Hardcover itself lacks ebook data.

[snapetech]

I opened PR #114 with the small upstream fix.

It passes the requested mediaType from the lookup controller into the remote search mapper, so Goodreads text-search results keep the requested ebook/audiobook type before the controller filters them. Unscoped callers keep the current behavior.

The change is entirely in Chaptarr’s lookup contract and has no client-specific code. I ran the full Chaptarr core test project: 2,854 passed, plus a release build of the full solution.