Skip to content

[Feature] KOReader/OPDS catalog download should honor the configured download_file_pattern (currently hardcoded to "Title - Author") #569

Description

@Lomig

What's your idea?

When books are downloaded through the 2.x KOReader sync plugin (the KOReader OPDS catalog endpoint), the saved file is always named Title - Author.epub, ignoring the Download file pattern configured in Settings (download_file_pattern, e.g. <{authors:sort} - ><{language} - >{title}).

The web Download button respects that pattern, but the KOReader/OPDS catalog path does not — so books synced straight to the device don't follow my configured naming scheme, and naming ends up inconsistent depending on how a book was fetched.

Could the KOReader catalog download apply download_file_pattern (the same as the web download), falling back to the current Title - Author when no pattern is set?

What problem does it solve?

Consistent, user-controlled filenames on the e-reader for books pulled via the KOReader plugin, matching the pattern already used everywhere else. Filenames are cosmetic for binary/hash matching, but they matter for on-device organization and for anyone relying on filename-based matching.

Anything else? (optional)

Heads-up: I'm not a JS/TS developer, so I may be misreading the code — please treat the pointer below as a lead rather than a diagnosis.

The relevant spot looks like dist/modules/koreader/koreader-catalog.service.js, whose download handler builds the name with a hardcoded helper instead of the configured pattern:

downloadFilename(detail, fileId, format) {
    const title  = detail.title ?? (basename(detail.folderPath) || `book-${detail.id}`);
    const author = detail.authors[0]?.name;
    const base   = [title, author].filter(Boolean).join(' - ');   // -> "Title - Author"
    ...
}

It sets Content-Disposition from this and never reads download_file_pattern — grepping modules/koreader and modules/opds shows no reference to the pattern; only modules/app-settings reads the setting. Reusing the same pattern-rendering the web download uses (with a fallback to the current behaviour) would make the two paths consistent.

Want to help?

I could try to suggest a change, but I'm not well versed in JavaScript/TypeScript best practices, so I can't promise the code would be up to your quality standards.

Before submitting

  • I've searched existing issues and this hasn't been requested yet.

Version: 2.1.0, self-hosted (ghcr.io/bookorbit/bookorbit:latest).

Metadata

Metadata

Assignees

No one assigned

    Labels

    releasedIssue or PR is included in a released version.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions