Kobo sync stopped working #1300
Gitwhut
started this conversation in
Issue Triage
Replies: 2 comments
-
|
I've got some problems syncing one Kobo (Clara 2E) to Grimmory as well, probably because it's running a newer version than my other Kobo (Libra H20). The Kobo Clara doesn't sync, just saying "Sync failed, try again later". I feel this may be an issue related to this pull request in the CWA repository. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
The kobo init service sometimes does not respond as expected. I have seen this, and given the responses are slightly different I think I have a path forward to correct. Opened #1500 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
What went wrong?
Kobo sync stopped working. The Kobo device successfully hits /v1/initialization and gets a 200 response, but the response is incomplete - it only contains 2658 bytes and is missing critical resource URLs like library_sync, library_metadata, library_book, and reading_state. Because those URLs are missing, the Kobo never makes any further calls beyond initialization, so no books ever sync to the device.
Meanwhile, an identical request made via curl to the same /v1/initialization endpoint returns the full 11728-byte response with all library URLs correctly populated. Same URL, same token, same Traefik route, but the Kobo gets a stripped-down response and curl gets the full one.
The Grimmory log shows WARN o.b.s.kobo.KoboInitializationService : Unexpected response from Kobo /v1/initialization, fallback to noproxy every time the Kobo hits the endpoint, even with "Forward to Rakuten Kobo Store" turned OFF in admin settings.
How can we reproduce it?
I verified via tcpdump between Traefik and the Grimmory container that the Kobo's request headers are identical to curl's (Host, X-Forwarded-Host, X-Forwarded-Proto, X-Forwarded-Port, User-Agent). Same Authorization Bearer behavior - curl gets 11728 bytes whether the Bearer header is present or not. HTTP/1.1 vs HTTP/2 also makes no difference (tested with curl --http1.1).
Toggling "Forward to Rakuten Kobo Store" off changes the response size from 2956 to 2658 bytes but does not include the missing library URLs.
Regenerating the sync token and re-pairing the Kobo did not help - same noproxy fallback occurs against the new token.
What Build of Grimmory are you on?
Stable
Your setup
Screenshots or error messages (optional)
Grimmory log:
WARN 1 --- [booklore-api] [mcat-handler-85] o.b.s.kobo.KoboInitializationService : Unexpected response from Kobo /v1/initialization, fallback to noproxy
Traefik access log showing the response size discrepancy:
From Kobo (HTTP/1.1):
<KOBO_IP> ... "GET /api/kobo//v1/initialization HTTP/1.1" 200 2658
From curl on same LAN (HTTP/2):
curl -s "https://<GRIMMORY_HOST>/api/kobo//v1/initialization" | wc -c
Returns: 11728
Kobo's [OneStoreServices] after sync — missing endpoints:
api_endpoint=https://<GRIMMORY_HOST>/api/kobo/
image_host=https://<GRIMMORY_HOST>
image_url_template=https://<GRIMMORY_HOST>/api/kobo//v1/books/.../image.jpg
library_sync, library_metadata, library_book, reading_state — all absent
Curl's full response includes those endpoints correctly:
"library_sync": "https://<GRIMMORY_HOST>/api/kobo//v1/library/sync"
"library_metadata": "https://<GRIMMORY_HOST>/api/kobo//v1/library/{Ids}/metadata"
"library_book": "https://<GRIMMORY_HOST>/api/kobo//v1/user/library/books/{LibraryItemId}"
"reading_state": "https://<GRIMMORY_HOST>/api/kobo//v1/library/{Ids}/state"
Before submitting
Beta Was this translation helpful? Give feedback.
All reactions