Manga Reader Feedback/Bugs


  • Premium Member

    @chocolatkey Android 5.1.1


  • Premium Member

    @Raitoiro Are you on a Samsung SM-N910C or a Samsung SM-J320FN (or neither)? Helps me narrow down the error report


  • Premium Member

    Trying to read Faerie Apartment:

    https://j-novel.club/mc/error/9500/UmVxdWVzdCBmYWlsZWQgd2l0aCBzdGF0dXMgY29kZSA0MDA%3D

    Ascendance of a Bookworm:

    [removed for potential leakage of personal info]

    Both are Windows, Firefox, Noscript and all other addons disabled.


  • Premium Member

    @dtta said in Manga Reader Feedback/Bugs:

    Trying to read Faerie Apartment:

    https://j-novel.club/mc/error/9500/UmVxdWVzdCBmYWlsZWQgd2l0aCBzdGF0dXMgY29kZSA0MDA%3D

    Ascendance of a Bookworm:

    [removed for potential leakage of personal info]

    Both are Windows, Firefox, Noscript and all other addons disabled.

    Thanks, that's probably specific to your ISP if it persists. It basically means our main server and manga server think you have different IP address versions, which shouldn't happen because they're both behind cloudflare, and I thought I had fixed this.. I'll be looking in to it


  • Premium Member

    Interesting! Chrome works fine, so I'm curious what Firefox does that Chrome doesn't! Oh well, not a big deal in general for me, but yeah.


  • Premium Member

    @chocolatkey I'm on SM-J320FN, and i didn't do the upgrade to the Samsung internet app, because it was worst than the base one. Btw i don't have issue using the manga reader when i use chrome.


  • Premium Member

    @Raitoiro I'm going to have to make this bug low-priority. It looks like it has to due with some features not supported by older browsers. Besides you, there's someone on Linux with Chrome 38 who's getting this error. Chrome 38 was released in 2014 and is not supported anymore. Maybe if I can find that version somewhere, I could figure out what the issue is, since the error is too vague, but higher-priority bugs/features come first


  • Premium Member

    @chocolatkey Yeah seem logic, and it work when i use chrome so it's really not a pressing issue.



    • fwiw it also doesn't work on AOSP browser that came with my Linage 13 (android 6) ROM.
    • Got ipv6/ipv4 error more than once (maybe at like 10% rate which is still certainly too much for a production app), maybe move them to the same sub domain if it's not too hard.
    • For jpeg you'd want tiles to be aligned to 8x8 grid (or 16x16 if taking subsampled chroma into account, although it's tricky to do precise stuff with resampled chroma anyway) for better efficiency.
    • Progress for novels is stored as a fraction (in 0–1 range) but for manga it's page number. I can only see drawbacks in that: being different from novels may mean more code to support both cases, in the chapters list in app or other lists it will be more informative to have "100% read"/"70% read", not "12 pages read"/"21 pages read" (note that 12 pages could be 100% and 21 pages could be 70%, admittedly, you can always convert if you have total page count), pulling number of people who read the chapter is just counting 1s in database if you store it as fraction.

  • Premium Member

    @_08 You certainly investigated I must say

    • Could I have your device model so I can narrow down the error in the reporting service?
    • Someone else reported the ipv4/6 error as well, and I am not yet sure why it is still happening considering both servers are now routing through cloudflare. It might be that the nginx build on the (old) production server is simply somehow prioritizing ipv4 addresses over ipv6 addresses it is passing to the backend, because both ipv6 and ipv4 clients work fine, it seems to be happening when you have both an ipv4 and ipv6 address. I am definitely looking in to this one.
    • The tile mixing is a long story, basically to save efficiently AND avoid color bleeding into neighboring tiles you need to save the jpgs 4:4:4 but golang's standard jpeg compression lib for some reason I cannot fathom will only let you save 4:4:2. There are multiple issues on the golang GitHub repo raised about this, and they were not really answered. So to save 4:4:4 I would have to use cgo, and cgo makes things difficult in various ways etc. etc. It's a long story, and something I'll probably be changing around in the future.
    • Quarkboy's decision was to have manga and novel logic completely separate on the backend, so there's a lot of "duplicate" code in that regard anyway. It doesn't really matter if it's stored as a percentage or page number in the backend really, just matters what it's when displayed as (2/24 pages can be converted into a percentage). I chose to use pages numbers because #1 I find them nicer to store vs. floating point, and #2 because manga are fixed layout publications. With reflowable novel text, there are no page numbers because it depends on the size of your device. Manga will always have page numbers, and unless a mistake is made during the uploading, page #X will always be page #X


  • @chocolatkey

    • Kindle HDX 8.9", 2013 version.
    • I don't think nginx has any say in it, if it gets a packet from ipv6 it responds on ipv6, if it gets it from v4 it responds on v4 (besides, nginx's ability to work with probably doesn't matter once you put it behind cloudflare). Also https://en.wikipedia.org/wiki/Happy_Eyeballs
    • I was talking mostly about 8x8 which is easier to do than chroma stuff
    • ok, though at this point page count has to be requested separately for each chapter which is bad for making lists

  • Premium Member

    Hey, I have some feedback: I like this reader!

    It doesn't load the last few pages in Bookworm on an iPad, but it must be the canvas memory issue. Also, I'd like it if in the future we could toggle a setting to advance page by page instead of mimicking a book and advancing two pages at the same time.

    EDIT: Huh, no, I didn't mean to quote _08, how do I remove the reference?


  • Premium Member

    @nosgoroth I just had Quarkboy deploy the iOS fix. Could you try again and see if that fixed it? All others I have asked have reported it resolving the issue.
    As for page-by-page, do you mean the single page mode? The button for that is in the bottom right corner, along with the vertical/horizontal toggle


  • Premium Member

    @chocolatkey Nice, I tested it and now all pages load properly; prefetch seems to be super fast too, I can't catch it loading a page. There are two issues that I can see though:

    What I meant by advancing by a single page is just use the same double-page view, but advance by a single one when pressing an arrow key, so it would display [21], then [32], then [43]. I'm seeing now that you have double page spreads as two separate images, so it might do weird things to the layout.

    Yeah, I know, I'll go charge my iPad now.

    EDIT: I forgot to say, it's iOS 12.1.


  • Premium Member

    Chrome has chroma bleed issues even when the DRM blocks are aligned to a 16x16 grid. Curiously enough, on the exact same image file, Photoshop doesn't.

    My guess is that Photoshop does chroma scaling on a per-macroblock basis while Chrome does the chroma scaling on a per-image basis.

    Now that I think about it, though, since the DRM blocks overlap by 16 pixels on all sides, can't the chroma bleed issues be ignored by simply discarding the outer 8 pixels of every DRM block?



  • @guspaz

    guess is that Photoshop does chroma scaling on a per-macroblock

    Or it does shitty (nearest neighbour) scaling, which is awfully common.

    Now that I think about it, though, since the DRM blocks overlap by 16 pixels on all sides, can't the chroma bleed issues be ignored by simply discarding the outer 8 pixels of every DRM block?

    Yes but there will be some bleed when subsampling chroma to encode it to 4:2:0, causing tiny bit of efficiency drop. Again, that chroma stuff hardly matters for largerly grayscale manga so just aligning to 8x8 seems fine (not aligning is hardly an issue and you can put it on the bottom of priority list, it's just something I needed to point out because it shouldn't be hard to change).


  • Premium Member

    @Guspaz something I haven't tried yet is bleeding issue when canvas smoothing option is disabled (which I recently disabled on the reader). I don't have high hopes but could go well.

    @_08 Yeah it's definitely not top on the priority list, but it's there. First gotta get the interface working well. "page count has to be requested separately for each chapter which is bad for making lists" you mean like querying the API yourself?

    @Nosgoroth I get it now, you mean like with JNC's novel reader. I'll add that to the feature list for the "advanced settings" menu I plan on adding later on. As for the iOS scrolling, that is only an issue on iOS and something I need to work out. And as for the text alignment I though I had fixed it... will investigate



  • @chocolatkey said in Manga Reader Feedback/Bugs:

    you mean like querying the API yourself?

    I mean right now mobile apps show the progress novel progress when you look at list of parts (like what this guy wanted). It just requests all of progress and metadata for all parts (at once) to do that. Unless I missed something, if you try to do the same and get % for multiple manga chapters (again "30 pages read" isn't what the guy in linked thread needed for instance) you'll have to request page count for each chapter separately (though it's easy to fix by adding page count property to chapter's metadata).


  • Premium Member

    @_08 I get what you mean now. To be honest, I haven't thought that far yet. Due to its nature, the manga backend is currently completely separate from the main JNC backend, and that kind of info is separate. I could have the page count be updated by the angular interface itself, but that's not a very pretty solution. As Sam's said in previous threads I see you were in, the next task after manga integration is frontend redesign and backend revamp, and during that, the manga part is definitely going to be combined so that you don't need to inefficiently call multiple APIs. As for how that progress indication is going to work for the app, since I'm not responsible for that part of development, I'll just be heeding the calls of the mobile dev(s), so if they say "add" x field in the meantime, I'll add it


  • Translators

    @chocolatkey To be frank, unlike novels, don't see much point in showing progress within a chapter for manga chapters. The auto resume should be sufficient. So maybe just "unread", "partially read" and "read" indications will be perfectly fine.