From ef129fdc482296a3364690118fcf2c1aad0fe899 Mon Sep 17 00:00:00 2001 From: John O'Keefe Date: Sun, 7 Jun 2026 00:04:28 -0400 Subject: [PATCH] fix(progress): omit epubcfi for paging documents (cbz/pdf/djvu) collectBookData put getLastProgress() directly into the epubcfi field for every document. For paging documents (has_pages == true: PDF, CBZ, CBR, CB7, CBT, DjVu) that value is the current page as a *number*, so the payload carried "epubcfi": 5 (a JSON number). The server types KOReaderBookProgress.Epubcfi as *string, and the strict JSON binder rejected it with a 400 ("cannot unmarshal number into ... epububcfi of type string"), which the plugin surfaced as the misleading "Failed to push progress. Check your network connection." Reflowable EPUBs were unaffected because CREngine returns an xpointer string. Only set epubcfi for rolling (reflowable) documents. Paging documents carry their position in the numeric page/total_pages fields, which the server already treats as the canonical locator for fixed-layout/comic formats. The pull path already falls back to progress.page, so restore keeps working. --- main.lua | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/main.lua b/main.lua index cfb463d..0ff4e71 100644 --- a/main.lua +++ b/main.lua @@ -785,7 +785,6 @@ function Bookhoard:collectBookData() title = title, authors = authors, percentage = percentage, - epubcfi = progress, context_text = context_text, page = page, total_pages = total_pages, @@ -796,6 +795,15 @@ function Bookhoard:collectBookData() }, } + -- epubcfi (a CREngine xpointer) is only meaningful for reflowable (rolling) + -- documents. Paging docs (PDF/comics/DjVu) carry their position in + -- page/total_pages; a bare page number here would be a JSON number into a + -- server *string field and fail the bind. Reflowable EPUBs are always + -- rolling, so they keep sending the xpointer exactly as before. + if not self.ui.document.info.has_pages then + book_data.epubcfi = progress + end + return book_data end