KoReader Sync Support

[cjrezz]

As a small ereader with no backlight, many use it as an on the go ereader with a larger backlit ereader for reading at home. Koreader reading progress sync would be a very helpful feature to have the reading progress sync between your at home ereader and your on the go ereader.

There was a bit of discussion on the relative simplicity of how Koreader sync works on another custom firmware post on reddit here:
https://www.reddit.com/r/xteinkereader/comments/1pmo1rz/comment/nu2w25w/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

[Fi4DkseUie73kfo9d]

This would be my number one request as well, even if not automatic, being able to push sync progress to KOReader would make this the perfect on the go ereader.

[itsthisjustin]

I implemented it in a way where you see "Sync Progress" at the top of the chapter select in an epub. You can click that, connect to wifi, and choose to sync TO or FROM koreader. It tells you the progress locally and the progress on the sync server as well. I think in the future a periodic "connect to my wifi and sync" thing could happen but for now it's manual

[itsthisjustin]

I also want this for being able to use my Kindle as a main reader and swapping back and forth. I may try to bring both features to the firmware in one go if possible.

[Fi4DkseUie73kfo9d]

Yep, exactly the same reason this would be my number one request. Being able to swap with my jailbroken Kindle and the X4 easily would be amazing. Thank you!

[itsthisjustin]

This is done and just pending merge: #232

[Fi4DkseUie73kfo9d]

Dude! That was fast! Thank you so much!

[cjrezz]

Wow! Amazing! Thank you!! - CJ

…

On Sat, Jan 3, 2026, 20:56 Justin Mitchell ***@***.***> wrote: This is done and just pending merge: #232 <#232> — Reply to this email directly, view it on GitHub <#61 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANI2QDRI63KNP3P2BTKTOYT4FCMRTAVCNFSM6AAAAACPQBUWZSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNBQGMYDQNQ> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[cjrezz]

Yeah this is going to be a game changer! Thank you! - CJ

…

On Sun, Jan 4, 2026, 00:09 Justin Mitchell ***@***.***> wrote: I implemented it in a way where you see "Sync Progress" at the top of the chapter select in an epub. You can click that, connect to wifi, and choose to sync TO or FROM koreader. It tells you the progress locally and the progress on the sync server as well. I think in the future a periodic "connect to my wifi and sync" thing could happen but for now it's manual — Reply to this email directly, view it on GitHub <#61 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANI2QDSYFINSV66RYBISIXD4FDDCTAVCNFSM6AAAAACPQBUWZSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNBQGM3DIMA> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[osteotek]

#232 is merged

[cjrezz]

Koreader sync support is working now but it's a little cumbersome to quickly sync progress. Would it be possible to make a shortcut for long pressing the power button to initiate sync progress?

[iandchasse]

I don't own an X4, but I was looking into KOSync and I took note of issue #581 and other reddit comments complaints about lack of proper syncing beyond chapter level. I referenced in my comment on that issue:

The way KOSync works is that the exact index of document/chapter/paragraph/text is preserved and sent like a string of text. This string of text is related to how KOReader caches book locations. Since crosspoint caches its books in a different (and more memory conscious) way, these locations are not preserved.

The chapters (sections), however, are the same for all KOReader books. So crosspoint takes the string for the chapter and sends it to KOSync, but because it only contains data for recent chapter, and not the paragraph/text offset, its point within the chapter is not preserved.

This can be fixed in 2 ways:

• crosspoint caches it’s books in a way that can keep better track of its paragraph/div/text/etc elements, then maybe it can be mapped to somehow

• KOReader adds support to estimate a location in a chapter based on the progress variable that it receives instead of just using the exact text location (crosspoint preserves that variable, but KOReader doesn’t use it, in preference for the location string)

Both projects are open source, soooo anything’s possible

Given that koreader is lua and easily modifiable, I looked at their function here under the 'syncToProgress' method here:

function KOSync:syncToProgress(progress)
    logger.dbg("KOSync: [Sync] progress to", progress)
    if self.ui.document.info.has_pages then
        self.ui:handleEvent(Event:new("GotoPage", tonumber(progress)))
    else
        self.ui:handleEvent(Event:new("GotoXPointer", progress))
    end
end

Those events link back to some helper functions they have in this file, and if you just simply re-write the 'syncToProgress' function to use "GotoPercent" (or onGotoPercent) instead of the "GotoXPointer" event, it will do so. Only thing is that the percentage variable that is typically something like '0.2484' to represent 24.84% sort of gets overlooked here, because I can only sync to 24.84 if I give it 24.84, as shown here

{'progress': '/body/DocFragment[9]', 'device_id': 'koreader_poll_script_id', 'document': 'f5b5d697677dbba3334520f41acae4da', 'device': 'koreader_poll_script', 'timestamp': 1769742139, 'percentage': 24.84}

Passing 0.2484 just rounds to 0. There's probably a reason for that in the intermediate operation.

Anyways, this is a hacky fix, and it's really only useful for these use-cases (syncing to KO from a non-KO device), so I'm not exactly sure if this could ever fly in the koreader repo, but for xt users it could be a good tradeoff to swap their files (and update the KOSync from xt side to push 0.XXXX * 100 instead of 0.XXXX, because that value is thrown out anyways as far as I know).

If you want to try it, you just have to change the contents of '\koreader\plugins\kosync.koplugin\main.lua' and change the syncToProgress function to:

function KOSync:syncToProgress(progress, percentage)
    logger.dbg("KOSync: [Sync] progress to", progress)
    if self.ui.document.info.has_pages then
        self.ui:handleEvent(Event:new("GotoPage", tonumber(progress)))
    else
        --self.ui:handleEvent(Event:new("GotoXPointer", progress))
		self.ui:handleEvent(Event:new("GotoPercent", percentage))
    end
end

and all instances of self:syncToProgress(body.progress) to self:syncToProgress(body.progress, body.percentage)

Let me know what you think @itsthisjustin @daveallie @osteotek

[itsthisjustin]

So I no longer round down the percentages. I believe the issue is just how koreader does page calculation. We don't store a character level map of the books for our spine indices like they do.

[iandchasse]

So I no longer round down the percentages. I believe the issue is just how koreader does page calculation. We don't store a character level map of the books for our spine indices like they do.

Sorry for any confusion, the code referenced here is entirely on koreader’s side. I have no xteink to test with, I’m just sending push/pulls with a python script and testing with a Linux build of koreader

[DaniPhii]

As of CrossPoint v0.16.0, when I upload my reading progress from my X4 to my KOSync instance, I won't be able to get my progress back when retrieving it from my X4 again; I will only get to the first page of the chapter I'm currently at, so I think this fix would also need to be implemented in CrossPoint. As I understood this is a harder bug to solve given the limited resources on the X4, I thought of improving controls to quickly jump to the desired page after syncing the progress (see #615).

[iandchasse]

To follow up, I notice that KOReader calculates its progress variable (at least in the book status, I think it's the same in other parts of the code) like this:

local read_percentage = self.ui:getCurrentPage() / self.total_pages

Meaning KO essentially pre-calculates how many rendered pages are left. So the method of basing percentage on Crosspoint's side on readBytes/totalBytes wouldn't quite work. Obtaining a roughly equivalent percentage value on Crosspoint's side could maybe be done if the entire book was indexed in advance of syncing, thereby getting the current page and total pages as KOReader calculates it above. This would probably have some error depending on image frequency.

When I get access to crosspoint, I will do some experimenting if it isn't already figured out by then

[iandchasse]

To follow up on this and the impending PR #783 that syncs crosspoint progress by % instead of chapter, you should be able to achieve two way syncing by modifying a single KOReader file on whatever device you choose by navigating to the file at:

koreader/plugins/kosync.koplugin/main.lua

And changing this function:

function KOSync:syncToProgress(progress)
    logger.dbg("KOSync: [Sync] progress to", progress)
    if self.ui.document.info.has_pages then
        self.ui:handleEvent(Event:new("GotoPage", tonumber(progress)))
    else
        self.ui:handleEvent(Event:new("GotoXPointer", progress))
    end
end

to

function KOSync:syncToProgress(progress, percentage, device_id)
    logger.dbg("KOSync: [Sync] progress to", progress)
    if self.ui.document.info.has_pages then
        self.ui:handleEvent(Event:new("GotoPage", tonumber(progress)))
    else
        -- special case that executes only if the sync was done by crosspoint
        -- all other devices will sync as normal
		if device_id == "crosspoint-reader" then
			self.ui:handleEvent(Event:new("GotoPercent", percentage))
        else
			self.ui:handleEvent(Event:new("GotoXPointer", progress))
    end
end

and all instances of

self:syncToProgress(body.progress)

to

self:syncToProgress(body.progress, body.percentage, body.device_id)

It would probably work, though I can't test it at this moment. It is possible it may not need the * 100, in the GotoPercent call, but in my previous testing it wouldn't work unless the percentage was expressed as XX.XX% instead of 0.XXXX. @osteotek @jpirnay, if you feel comfortable, try it out.

[osteotek]

while it might work, we can't ask users to modify Koreder code for sync to work... It's possible to generate correct xpointer on crosspoint side, just complicated

[iandchasse]

Yeah, it's more for me and others to try if they want. KOReader being written in lua, as well as the relevant changes only being 1 file, makes it something that would be quick to try for most people who want the feature quicker.

[iandchasse]

Just to update, my reply above works! Here is the actual function necessary:

function KOSync:syncToProgress(progress, percentage, device_id)
    logger.dbg("KOSync: [Sync] progress to", progress)
    if self.ui.document.info.has_pages then
        self.ui:handleEvent(Event:new("GotoPage", tonumber(progress)))
    else
        if device_id == "crosspoint-reader" then
            self.ui:handleEvent(Event:new("GotoPercent", percentage * 100))
        else
            self.ui:handleEvent(Event:new("GotoXPointer", progress))
        end
    end
end

[DaniPhii]

I tried to disable the native plugin in KOReader and add a modified version of the same plugin, modifying the plugin's name to avoid conflicts. I couldn't make it work, though. I'll try again tomorrow if I have a chance, as I must have made a silly mistake, or maybe this is not achievable and I must compile the KOReader app to make it work as expected.

[iandchasse]

I tried to disable the native plugin in KOReader and add a modified version of the same plugin, modifying the plugin's name to avoid conflicts. I couldn't make it work, though. I'll try again tomorrow if I have a chance, as I must have made a silly mistake, or maybe this is not achievable and I must compile the KOReader app to make it work as expected.

Not sure on this front, you don't need to compile anything though, you would just need to edit the lua file itself on the already installed plugin. YMMV

[DaniPhii]

Not sure on this front, you don't need to compile anything though, you would just need to edit the lua file itself on the already installed plugin. YMMV

The plugin isn't in the koreader directory in the internal storage of the Android devices I installed it in. Maybe I'm not looking into the correct place? I thought the KOSync plugin was part of the app itself. 🤔

[ImSoRight]

Could you create a KOReader patch that makes the necessary changes? That would be much more user friendly, and it would work on Android devices as well.

[m0ne]

Hey guys, thanks for the code, I applied it and sync works great now. One small thing: since my Kindle and the xteink x4 have different screen sizes (and therefore a different amount of text per “page”), the synced reading position ends up being about one page off between the two devices. I assume aligning the exact page across both would be significantly more involved.

[iandchasse]

Hey guys, thanks for the code, I applied it and sync works great now. One small thing: since my Kindle and the xteink x4 have different screen sizes (and therefore a different amount of text per “page”), the synced reading position ends up being about one page off between the two devices. I assume aligning the exact page across both would be significantly more involved.

Yes. One of two things would need to change for more accurate sync

• Crosspoint uses 'current page' / 'total pages' for percentage calculation instead of using cumulative text size. This would make the error a bit better for books with a lot of whitespace/formatting that would get skipped in crosspoint. You'd need to index the entire book to get the 'total pages' number, which would be a pain. This would still require the fix on KOReader's end, and would still have a small amount of error.
• Crosspoint would need to do a one-off re-traversing of the raw xhtml, seek the text/postion in the chapter, and extract the index of sentence/text to make an "XPath" that would be compatible with KOReader. This would probably produce a small delay before sync completes, and the code would be a bit complex. This would allow for 1:1 syncing from crosspoint -> KO, but the method of seeking the XPath would need to be done on crosspoint's end as well to make it 1:1 for KO -> crosspoint. Maybe down the line...

[m0ne]

Thanks for the detailed input.
• I think the book gets indexed on first open anyway (there’s already a preprocessing step before you can read), so deriving total pages there might be doable, making this option quite viable.
• The XPath idea is very cool, but I doubt KOReader would take on that much device-specific sync logic for one firmware/device.

[osteotek]

Thanks for the detailed input. • I think the book gets indexed on first open anyway (there’s already a preprocessing step before you can read), so deriving total pages there might be doable, making this option quite viable.

Only first chapter gets "indexed" not the whole book. Actually calling it indexing is misleading, there is no indexing happening, it's more of a rendering text

[m0ne]

Oh, that’s unfortunate 😔 Do we have any estimate of how computationally intensive this would be?

[jpirnay]

Hey guys, thanks for the code, I applied it and sync works great now. One small thing: since my Kindle and the xteink x4 have different screen sizes (and therefore a different amount of text per “page”), the synced reading position ends up being about one page off between the two devices. I assume aligning the exact page across both would be significantly more involved.

I am working on a better option, probably ready during the weekend (code is ready but needs testing with my 3 + x4 ebook readers):

KOReader Sync XPath Mapping

This note documents how CrossPoint maps reading positions to and from KOReader sync payloads.

Problem

CrossPoint internally stores position as:

• spineIndex (chapter index)
• pageNumber + totalPages

KOReader sync payload stores:

• progress (XPath-like location)
• percentage (overall progress)

A direct 1:1 mapping is not guaranteed because page layout differs between engines/devices.

Current Strategy

CrossPoint -> KOReader

Implemented in ProgressMapper::toKOReader.

1. Compute overall percentage from chapter/page.
2. Attempt to compute a real element-level XPath via ChapterXPathIndexer::findXPathForProgress.
3. If XPath extraction fails, fallback to synthetic chapter path:
   • /body/DocFragment[N]/body

KOReader -> CrossPoint

Implemented in ProgressMapper::toCrossPoint.

1. Attempt to parse DocFragment[N] from incoming XPath.
2. If valid, attempt XPath-to-offset mapping via ChapterXPathIndexer::findProgressForXPath.
3. Convert resolved intra-spine progress to page estimate.
4. If XPath path is invalid/unresolvable, fallback to percentage-based chapter/page estimation.

ChapterXPathIndexer Design

The module reparses one spine XHTML on demand using Expat and builds temporary anchors:

• anchor: <xpath, textOffset>
• textOffset counts non-whitespace bytes

Matching for reverse lookup:

1. exact path match
2. index-insensitive path match (div[2] vs div[3] tolerated)
3. ancestor fallback

If no match is found, caller must fallback to percentage.

Memory / Safety Constraints (ESP32-C3)

The implementation intentionally avoids full DOM storage.

• Parse one chapter only.
• Keep anchors in transient vectors only for duration of call.
• Free XML parser and chapter byte buffer on all success/failure paths.
• No persistent cache structures are introduced by this module.

Known Limitations

• Page number on reverse mapping is still an estimate (renderer differences).
• Image-only/low-text chapters may yield coarse anchors.
• Extremely malformed XHTML can force fallback behavior.

Operational Logging

ProgressMapper logs mapping source in reverse direction:

• xpath when XPath mapping path was used
• percentage when fallback path was used

It also logs exactness (exact=yes/no) for XPath matches.

[iandchasse]

@jpirnay Sounds like the goto solution for this, can’t wait to test it!

[DenisFanteria]

[m0ne]

Hi, probably not the right place, but you’ll want to check your Calibre “send” settings. Either:
• globally under Preferences → Sending books to devices, or
• per device in the device-specific configuration (where you can set the filename/template)

Make sure the same send template is used across all your devices. Otherwise KOReader sync (filename-based) won’t match books correctly.

[jpirnay]

PR #1217 is ready for review and even more relevant ready for testing. I teste hither and dither with the X4, a pocket book device running the latest koreader nightly, a kobo device as well a a jailbroken kindle both running koreader 2025-10

[jpirnay]

For those who have already integrated this PR in their local forks: I made a couple of updates over the last days as I was reading more books with edge-case-structures - things are looking good to me - the maximum deviation I encountered were two to three pages from your reading position.

[ChrisRomp]

This worked great for a bit. Unfortunately my X4 is crashing anytime I open a certain large ebook (a trilogy novel in one file) after pulling down remote progress. I see the "indexing" and then it will crash. I can post my crash logs to an open issue or PR if there's one recommended, if this isn't a known issue with large files.

[itsthisjustin]

This worked great for a bit. Unfortunately my X4 is crashing anytime I open a certain large ebook (a trilogy novel in one file) after pulling down remote progress. I see the "indexing" and then it will crash. I can post my crash logs to an open issue or PR if there's one recommended, if this isn't a known issue with large files.

Yes please post the logs. Here is fine tbh. You may also want to grab the latest nightly again as even more kosync stuff has been merged

[ChrisRomp]

I had updated to the nightly (master) rev again yesterday to verify it was still crashing. Here's the dump:

crash_report.txt

CrossPoint version: 1.2.0-dev-master-ba4a361

Panic reason: abort() was called at PC 0x4215b02d on core 0

Last logs:
[34954] [DBG] [SCT] Page 472 processed
[34992] [DBG] [SCT] Page 473 processed
[35012] [DBG] [SCT] Page 474 processed
[35053] [DBG] [SCT] Page 475 processed
[35066] [DBG] [SCT] Page 476 processed
[35101] [DBG] [SCT] Page 477 processed
[35135] [DBG] [SCT] Page 478 processed
[35167] [DBG] [SCT] Page 479 processed
[35207] [DBG] [SCT] Page 480 processed
[35232] [DBG] [SCT] Page 481 processed
[35253] [DBG] [SCT] Page 482 processed
[35295] [DBG] [SCT] Page 483 processed
[35321] [DBG] [SCT] Page 484 processed
[1] [DBG] [UI] Using Lyra theme
[23] [INF] [HW] Using cached device type: X4
[24] [INF] [MAIN] Hardware detect: X4


Stack memory:
0x3FCB45A0: 0x00000000 0x00000000 0x3FCB45B8 0x4038DED4 0x00000000 0x00000000 0x3FCA0030 0x3FC941B8 
0x3FCB45C0: 0x3FCB45CC 0x3FC941D4 0x3FCB45B8 0x35313234 0x64323062 0x00000000 0x726F6261 0x20292874 
0x3FCB45E0: 0x20736177 0x6C6C6163 0x61206465 0x43502074 0x34783020 0x62353132 0x20643230 0x63206E6F 
0x3FCB4600: 0x2065726F 0x00000030 0x3FCA0000 0xAC760A4B 0x0000E000 0x000001E5 0x3FCBE5A4 0x4215B030 
0x3FCB4620: 0x00007000 0x000001E5 0x3FCBE5A4 0x4215B07C 0x3FCBE5A4 0x000001E5 0x3FCBE5A4 0x4215B19E 
0x3FCB4640: 0x00007000 0x000001E5 0x4215BA8A 0x3C5716C0 0x00007000 0x000001E5 0x0000E000 0x4215B2E8 
0x3FCB4660: 0x00000000 0x42045F0C 0x3FCB4E5C 0x42046FCC 0x000001D0 0x00000000 0x42000000 0x3FCA8000 
0x3FCB4680: 0x3FCB4844 0x000001E5 0x3FCB4C6C 0x420475A4 0x3FCB4C6C 0x00000000 0x000001F7 0x43E80000 
0x3FCB46A0: 0x42000000 0x3FCB47E4 0x3FCB4844 0x42046006 0x3FCB46B8 0x0000000B 0x6F626F6B 0x3431312E 
0x3FCB46C0: 0x00312E34 0x3FCB47E4 0x3FCB01E5 0xAC760A4B 0x000001D0 0x00000000 0x42000000 0x00000000 
0x3FCB46E0: 0x00000000 0x000001F7 0x3FCB4C6C 0x42049532 0x3FCB5070 0x00000009 0x08C00000 0x3FCDFFA0 
0x3FCB4700: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
0x3FCB4720: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000001 0x00000000 0x00000000 
0x3FCB4740: 0x00000000 0x00000000 0x00000001 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 
0x3FCB4760: 0x00000001 0x00000000 0x00000001 0x00000000 0x00000001 0x3FB9999A 0x00000001 0x00000001 
0x3FCB4780: 0x00000001 0x00000000 0x00000001 0x00000001 0x00000001 0x00000001 0x00000001 0x00000000 
0x3FCB47A0: 0x00000004 0x00060000 0xC0380000 0x3FCA8000 0x3FCDC710 0x00000010 0x3FCDC710 0x4038C544 
0x3FCB47C0: 0x3FCA8530 0x00001800 0x3FCBE398 0x00000002 0x00000000 0x00000000 0x00000000 0x00000000 
0x3FCB47E0: 0x00000100 0x00000000 0x3FB9999A 0x00060001 0x00000000 0x3FCA8001 0x00000000 0x00000001 
0x3FCB4800: 0x00000000 0x4038C501 0x00000000 0x3F800001 0x00000000 0xBAAD5600 0x00000000 0x00000000 
0x3FCB4820: 0x00000000 0x4038C700 0x00000000 0x00000000 0x00000000 0x40380E00 0x00000000 0x00000000 
0x3FCB4840: 0x01F70000 0x00000000 0x00000000 0x00000000 0x00000000 0x002E0000 0x3FCA0101 0x00000200 
0x3FCB4860: 0x00000000 0x3FCBD63C 0x3FCC0B8E 0x00000000 0x00000000 0x3FCDFB39 0x3FCBDCEC 0x3FCB48A0 
0x3FCB4880: 0x3FCDFB39 0x3FCDFB38 0x3FCA8000 0x4201F05C 0x00000004 0x3FCB489C 0x00000000 0x3FCDFB39 
0x3FCB48A0: 0x6522B2CC 0xCD76A52D 0x4DDF06D7 0x0063DE8B 0x636FCDC0 0x63D3B811 0x4702054E 0xD53160B1 
0x3FCB48C0: 0x73616C63 0x00000073 0x3FCB48C5 0x3FCDFFA0 0x00000000 0x00000000 0x045B6315 0xAC760A4B 
0x3FCB48E0: 0x00000000 0x00000001 0x3FCBDCC4 0x4201F13E 0x3FCC0B99 0x3C1E92FC 0x3FCBD520 0x4201F590 
0x3FCB4900: 0x00000000 0x3FCB490C 0x00000002 0x3F005854 0x00000000 0x00000001 0x00000001 0x3FCB4924 
0x3FCB4920: 0x00000000 0x3C1E9200 0x3FCBD6C8 0x4201F590 0x3FCDD018 0x3FCDFB38 0x3FCBDC9C 0x3FCC0B9D 
0x3FCB4940: 0x3FCDFF60 0x3FCBD63C 0x3FCDFF6C 0x3C1E92FC 0x3FCDD018 0x00000000 0x3FCBD6C8 0x4201F5C6 
0x3FCB4960: 0x3FCDD018 0x00000000 0x00000000 0x42020436 0x3FCA8000 0x3FCBDC9C 0x3FCBD6C8 0x3FCDFF8C 
0x3FCB4980: 0x00000000 0x3FCB498C 0x00000000 0x77736E00 0x3FCBD748 0x72650000 0x00000073 0xAC760A4B 

[jpirnay]

This worked great for a bit. Unfortunately my X4 is crashing anytime I open a certain large ebook (a trilogy novel in one file) after pulling down remote progress. I see the "indexing" and then it will crash. I can post my crash logs to an open issue or PR if there's one recommended, if this isn't a known issue with large files.

Please post a bit more info about the problematic epub: file size, ideally the name, where to get it... So that we can recreate the issue

[SteadBytes]

I also got a crash when trying this out on nightly. Specifically, the crash occurred after selecting the "Sync Progress" menu option. The below log was dumped when doing so on an epub of "IBM and the Holocaust" by Edwin Black. It's 1.8MB and ~1200 pages on a Kobo Libra 2 - not sure how many pages total on the X4.

CrossPoint version: 1.2.0-dev+20fee84

Panic reason: assert failed: xTaskPriorityDisinherit tasks.c:5156 (pxTCB == pxCurrentTCBs[ 0 ])

Last logs:
[17] [INF] [HW] Using cached device type: X4
[17] [INF] [MAIN] Hardware detect: X4
[21] [INF] [HW] Using cached device type: X4
[22] [INF] [MAIN] Hardware detect: X4


Stack memory:
0x3FCB1460: 0x3FCA8000 0x3FCA1B68 0x3C574D38 0x4038E022 0x00000602 0x00000001 0x3FC94B20 0x3FC94240 
0x3FCB1480: 0x00000602 0x00000001 0x3FC94B20 0x36353135 0x3FCB1500 0x3FC94228 0x3C574D38 0x3FC94728 
0x3FCB14A0: 0x3C1B5122 0x3FC94238 0x3FCB148C 0x3FC9423C 0x3C1B53A0 0x3FC94240 0x00000000 0x00000000 
0x3FCB14C0: 0x40000000 0x65737361 0x66207472 0x656C6961 0x78203A64 0x6B736154 0x6F697250 0x79746972 
0x3FCB14E0: 0x69736944 0x7265686E 0x74207469 0x736B7361 0x353A632E 0x20363531 0x54787028 0x3D204243 
0x3FCB1500: 0x7870203D 0x72727543 0x54746E65 0x5B734243 0x5D203020 0x42000029 0x3FCB1590 0x3FC90E00 
0x3FCB1520: 0x3FCB1910 0x00000000 0x3FCB1C98 0x4038738C 0x00000000 0x00000000 0x3FCA959C 0x4038738C 
0x3FCB1540: 0x00000000 0x00000000 0x3FCA959C 0x403879EE 0xFA000000 0x00000003 0x000000FF 0x00000000 
0x3FCB1560: 0x3FCA8000 0x3FCA1B68 0x3FCB16EC 0x3FC948A0 0x3FCA8000 0x3FCA1B68 0x3FCB16EC 0x3FC948A0 
0x3FCB1580: 0x3C241884 0x00000001 0x3FC94B20 0x1C76B920 0x3C241884 0x00000002 0xFFFFFFFF 0x00000000 
0x3FCB15A0: 0x00000000 0x00000000 0x3FCB1F50 0x4038A0E0 0x00008860 0x00000000 0x3FCB1C98 0x4038738C 
0x3FCB15C0: 0x00000000 0x00000000 0x3FCB1C98 0x403879EE 0x0000014D 0x00000000 0x0000012C 0x00000000 
0x3FCB15E0: 0x0000014D 0x0000014D 0x3FCB1630 0x3FCB16EC 0x00000200 0x00000000 0x00000000 0x3FCB16EC 
0x3FCB1600: 0x00011FC0 0x3FC948D8 0x3FC94880 0x42000682 0x00011FC0 0x3FC948D8 0x3FC94B20 0x42006140 
0x3FCB1620: 0x00011FC0 0x3FC948D8 0x3FC94B20 0x4200682C 0x00000001 0x00000000 0x3FC948C8 0x42006872 
0x3FCB1640: 0x3FCA9554 0x0000005F 0x000927C0 0x3FC948D8 0x3FCA2000 0x00000000 0x3FC948C8 0x420068CA 
0x3FCB1660: 0x00000004 0x00000004 0x3FCB2C78 0x42004126 0x00000000 0x00000000 0x3FCA9530 0x40387F56 
0x3FCB1680: 0x3FCB6BF4 0x3FCB16F8 0x3FCB16F8 0x00000000 0x00000000 0x00000000 0x3FCA2000 0x00000000 
0x3FCB16A0: 0x000927C0 0x0000005F 0x00000039 0x3FCA2000 0x3FCB2AF8 0x3FCB2AD4 0x3FCB2AF8 0x4201CB44 
0x3FCB16C0: 0x00000000 0x3FCB6BA4 0x00000004 0x3FCB16EC 0x3C1A8EDC 0x3FCB1724 0x3FCB171C 0x4203CAB8 
0x3FCB16E0: 0x3C1AA75C 0x0000000C 0x3FCB1701 0x3FC9062C 0x3FCA8000 0x3FCB24E0 0x3FCB171C 0x42039B10 
0x3FCB1700: 0x3FCA8000 0x3FCA8000 0x3FCA8000 0x42039D8A 0x0000001C 0x3FCAD26C 0x4201BA6E 0x00000000 
0x3FCB1720: 0x0000FFFF 0x00010000 0xFFFF0020 0x00000000 0x00000000 0x3FCA2000 0x00001206 0x1C76B920 
0x3FCB1740: 0x3FCA8000 0x3FCA8000 0x3FCB69C8 0x4207B46C 0x3FCA8000 0x3FCB2A04 0x3FCA8560 0x40387F56 
0x3FCB1760: 0x00000001 0x3FCB2A0C 0x00040000 0x00000001 0x400391E6 0x00000006 0x00040000 0x00000000 
0x3FCB1780: 0x400391E6 0x00000000 0x3FCB1EBC 0x4038738C 0x00000000 0x00000000 0x3FCB1EBC 0x1C76B920 
0x3FCB17A0: 0x3FCB1814 0x00000000 0x00000083 0x3FC9091C 0x000927C0 0x3FCA2000 0x00001210 0x3FCA2000 
0x3FCB17C0: 0x3FCA8000 0x3FCA8000 0x3FCA1B50 0x4206E66A 0x00000001 0x00000001 0x00000000 0x421119F8 
0x3FCB17E0: 0x3FCB1814 0x00000000 0x3FCB23D4 0x4038738C 0x00000000 0x00000000 0x3FCB23D4 0x403879EE 
0x3FCB1800: 0x00000000 0x00000000 0x3FCB23D4 0x00000000 0x00000000 0x3FCA8000 0x00000014 0x420AA07C 
0x3FCB1820: 0x00000000 0x3FCA2000 0x00001210 0x1C76B920 0x00000002 0x00000000 0x3FCA2000 0x3FC9091C 
0x3FCB1840: 0x000927C0 0x3FCA2000 0x00001210 0x3FCA2000 0x3FCA8000 0x3FCA8000 0x3FCA2000 0x42099DB8 

[rigogsilva]

Not sure if this is a features people want but I like to have my books synced automatically. For example I have a kobo with koreader, and my x4, and I normally read the x4 in day light (due to not having a light), and my kobo at night.

I wanted them to sync without me having to manually remember that I have to push to remove and pull from remove.

I added a PR for it that I am testing locally and it is working well. PR #2756 for checking progress and a draft pr uploading progress PR #2760