Mokuro: Read Japanese manga with selectable text inside a browser

Japanese Language Resources
626

There’s a couple of separate issues in the post above, they are all distinct ones, so I’ll try to respond to them one by one.

First of all, you’re not using the mokuro fork, you’re using the mokuro-bridge, both of them can run separarely from one another and the mokuro fork is the one that’s responsible for the 4x speedup compared to the kha-white’s one:

But you’re using the bridge, which is responsible for speeding up the connections and autouploading your manga to remote sources:

They both serve different purposes and they can both work in tandem with one another!

I’m glad you’re using the 0.6.0 version, that’s the newest one i’ve published, I’ve had a few changes on my drive, so I tried pushing them to GitHub (0.7.4) and also to PyPI so that you can download it with pip, but the behavior won’t change much between versions, let’s tackle the issues one by one then!

Funnily enough, this is a guardrail I introduced by myself, not to allow for manga to be scraped outside of the Users directory so that it wouldn’t be able to linger in directories where it’s hard to track it down:
_LOCAL_INGEST_ROOTS = [Path.home(), /tmp, /private/tmp, /var/folders, /private/var/folders]
I do understand the usecase of wanting to scrape manga to different directories like the root of a second drive though, so that one has been loosened:

This is not a 403 from the bridge, it’s a 403 from Bookwalker.jp, you can see it because of this header on the request:

x-bwdd-fetch-proxy: mokuro-bridge

and the reason why you’re getting a 403 from Bookwalker and not the bridge is that you’re pinging the wrong port, 62646 instead of 62642 - the accelerated 48 posts are later down the list of ports, they’re not directly adjacent to the port of the app

That looks like firewall running, it could be Windows Defender connected through the browser that blocks the interaction, but you can test whether it is or it isn’t by running both http://127.0.0.1:62642/health with curl and with the browser and finding out where does the link break :eyes:

I have a few CLI scripts for downloading manga from multiple different domains and a lot of userscripts for different sources, but before releasing them, I need to do a proper accessibility audit, because some things that are a bit easier to understand to me don’t come the same way for the others, I’ll keep that in mind :crossed_fingers:

627

Thank you SO much for taking the time to go through all of that! I can’t believe I was pinging the wrong port - what an idiot hahaha. When I ping 62642 it gives me a 404 not found, both in command line + in browser. As part of my troubleshooting I had tried to allow the port through my firewall (both ways) and have even tried turning it completely off but this still doesn’t seem to make a difference.

Running /health gives me exactly the same output in browser and in the command line:

image
image940×390 16.8 KB

Nothing looks obviously wrong here to me so not sure if this is illuminating or not.

Regardless I’ve been able to run your fork of mokuro on a local folder thanks to what you mentioned, so hooray!!! At least I can do it the long way round. I’m on desktop and my C drive is by far the smallest so I don’t keep much on there. I checked the docs this morning and I can see there’s been an update to the bridge + the docs do also mention this… I promise I did read through everything about 100 times but if it’s not a new addition it’s possible I missed it. I do actually work as a data analyst (though not with servers/python, I use R) and thought I was pretty fly with a computer but clearly not.