Comic Earth Star - only retrieving 19 pages per chapter

[hakuneko-user]

From: HakuNeko User

Version: 6.1.7@c15c4e

Manga chapters retrieved from Comic Earth Star (e.g. chapters from https://www.comic-earthstar.jp/detail/megane/) end up cut off after 19 pages in the download as well as preview. Accessing the website directly using a browser or in HakuNeko works without issues.

What has been done?

☑ Read the Quick Start Guide: https://git.io/hakuneko-quickstart ☑ Tried Troubleshooting: https://git.io/hakuneko-troubleshooting ☑ Done Website Interaction: https://git.io/hakuneko-websiteinteraction ☑ Searched for Similar Issues: https://git.io/hakuneko-issuesearch

[ghost]

this happens because the current Publus connector relies on the viewer's cached pages to generate its page list, which for this site is capped at 20. i don't know how important this cache is for other sites, so i'm personally not going to mess with the script, but for anyone interested, manually generating the page URLs based off a template URL (e.g. "https://storage.comic-earthstar.jp/data/(seriesname)/(seriesname)(chapternum)/item/xhtml/p-(XXX|cover).xhtml/0.jpeg") given the chapter length would work much better for at least this site as here the encryption method is very simple and only relies on said URLs. i've tested this on the website and it seems to work fine.

[ronny1982]

Branch can be found here: https://github.com/ronny1982/hakuneko/commits/publus

Current problem is that it breaks other publus based websites

[ghost]

the other connectors using Publus i found were: -Gangan Online -MangaPlus -Comic Boost all of them excluding Comic Boost don't seem to use Publus anymore, nor on a quick look could i find an older chapter that used Publus on them, so i assume Comic Boost is the one you're talking about.

Comic Boost uses search params to associate a chapter's viewer session with accesses to a chapter's pages, and as a result, rejects requests to pages without valid params. these are found in the config license file (the configuration variable in the code). i don't know if these params are unique to Boost, but to keep things generic, it would honestly probably be easier to steal the params from the first page in the NFBR variable's cache and just append them to the page URLs taken from the config _pack.json file (which must also be accessed with the aforementioned search params).