Who likes manga?

Fix two… Tick!

Just got a status update from PlingStore. With 429 distinct downloads, Manga is more popular than Zap Ultimate. ;-)

I liked it so much, I downloaded 428 copies!

Nota: the archive of the 0.48b is corrupted, both on Store and your website.

Must be a problem with the original archive. How strange.

I think when I get home, I’ll version bump it to 0.49, because I haven’t had much luck getting 0.48 out! :-/

And it does not work any more :) I suspect there is a blacklisting system when you try to download a whole Manga in library (or something else).

I suspect there is a blacklisting system when you try to download a whole Manga in library (or something else).

Thank you. You’ve given me a reason for a 0.49 release. ;-)

This new version (!Store, auto-updater, and my private server) now does a ten second hold-off between fetching each image. It’s annoying and slow to do that, but perhaps better to look like a human than a machine.
My one is half way through chapter two (of three) of Harmony. Chosen semi-randomly (it’s short enough to test, and Harmony was name of the bitchy clueless vampire in Buffy), so I hope it’ll be worth reading!

Edit: Successfully downloaded 78 images (three chapters) in about 18 minutes.

Version 0.50 is available from the usual places.

0.50  2020/09/05

      Fixed the problem that would cause crashes upon
      trying to parse the main mange index at startup.
      [was because the huge wodge of script at the
       page start was overflowing the buffer because
       1024+terminator won't fit into 1024 bytes!]
      
      The problem didn't happen immediately as the
      script today is slightly different to how it was
      on the 1st. I don't know if this is work on the
      Mangareader site, or something Cloudflare does
      (as I suspect it filters the HTML to make this
      mess)...

      Now correctly handles manga with no description.
      
      Fixed genre parsing.
      
      Fixed thumbnail image fetching. Some references
      began with "https://", while others only began
      with "//".
      Yes, I was smart enough to look for the 's' in
      https, just in case they go http again... ;-)
      
      What's New should now work, but note that it is
      unclear if "new" entries will work correctly (as
      there currently aren't any!).

      Added some additional code for the manga updates
      I've seen in the update history that start to
      count from 1, but don't mark the manga as new.
      So now Manga will.
       
      Suggestions now working.
      
      And to round off the functionality, Search is
      operational. So we're back to where we were
      before the Cloudflare change.
      Finally. ;-)
      
      If you want to try tweaking the holdoff delay,
      you can set the system variable:
        Manga$HoldOffDelay
      If the value is less than 20, it is assumed to
      be seconds. Otherwise, it is centiseconds.
      Thus:
        Set Manga$HoldOffDelay 5
      and:
        Set Manga$HoldOffDelay 500
      are identical.
      The delay is read once when starting up the
      manga download operation.
      A quick test indicates that six seconds works...

I probably should have worked outside today.

Oh well. Too late.

I’m sure you’ll appreciate this more than yet another photo of where brambles used to be. ;-)

Now to go sit outside with a bottle of raspberry Yop and watch the sun set.

I just downloaded !Manga version 0.5 and it complains: unable to load AcornHTTP version 1.04.

I am running Risc OS Direct.

Where can i get the newest Acorn HTTP?

Where can i get the newest Acorn HTTP?

It is in the Nightly Beta HardDisc4 download

It may be best to upgrade !Boot to acquire other required components.

You’ll find AcornHTTP in the nightly beta Harddisc4 (zip: https://www.riscosopen.org/zipfiles/platform/common/HardDisc4.zip?1600581365). Rummage around, I think it is :Boot → Resources → :System → 310 → Modules → Network → URL or something like that.
You’ll also need the latest AcornSSL. That one will be in the 350 part.
And probably the newest cert data would be good too. :Boot → Resources → :Internet → Files. Or something. It’s called CertData.

Writing this on my phone, so I have used : to mean ! (as in :System) because of Textile…

Thank you. Now it works !

Well, it looks like mangareader.net has died a death. It’s been saying Temporary problem, Please try again in few minutes. for a few weeks now (and returning 404s in Manga because the subpages no longer exist).

Well, that’s it. No more manga. :-(

It was good while it lasted…

As I recall, I looked up manga back when you first mentioned it and noted a pay-per-read type thing. This connected?

On the other hand, you might like to give v0.53 a whirl. The updater will notify you, or you can fetch it from http://heyrick.ddns.net/manga/

It is not on Store because it should be considered alpha quality at this point. However, it “works for me”.

Some points to note:

• It’ll need a little over 10MiB to get going now.
• Because it’s using mangahere.cc as a source.
• Which means that rather than ~4500 manga, you have about thirty thousand (nominally, I’ve found a few 404s)

Also:

• It is SLOW to fetch and process the manga list as it has to chunder through around 4MiB rather than ~300KiB! It only does it every 24 hours.
• There’s a few seconds pause when Manga starts, it’s building up a menu structure with thirty thousand entries. ;-)
• The menu listings are a god-awful unsorted mess. That’s how it is in the original file. Sorting that would require significant code rewrites to extract the data for each “section”, sort it, then copy it back. It’s slow enough already…

And:

• “Add to library” is completely untested. I’m hungry, so going to brew up some pasta rather than rummage around in any more code. However, see the note below.
• There’s no What’s New, Suggestions, or Search. These will come at some unspecified future date. Given how the site returns information, it’ll be a little bit… complicated.
• I have moved “Alternate name” and “Reading direction” out of the selection window because the site does not provide this information.
• The menus no longer add a ‘*’ to titles to mark those that are complete, because this information isn’t available until reading the manga information.

Ergo Proxy is a 404, however I have read a bit of Anne Freaks, Elfen Lied, and Ghost Only (the latter picked because it was right by the mouse pointer in the ‘g’ section).

• Because of how the internal references work, items in your history may be shown as being available because the title matches up with the title as it appears in mangahere. Note, however, that the chapter organisation may not match up with how the previous site organised things.

• This should be kept in mind if updating/refreshing entries in your library – that things may be differently organised. For example, my Azumi is 256 chapters, and the one on mangahere is 275. Is this because the latter is more up to date, or because of differences in organisation? I don’t yet know…

Have fun.

0.53 works fine for me!

I didn’t think the download/index took that long, really.

And yes wow so many more titles!!!!

And they are organized very differently, indeed! (Big O was 6 chapters of ~200 pages on mangareader, scans of the VIZ collections. mangahere has the individual issues as chapters!)

Hi Rick,

Thanks for the new version 0.53.

It Aborts on ARMX6 RISC OS 5.29 (3rd Nov 2020)

Internal error, trap while in trap handler: Internal Error:abort on data transfer at &FC1674BC, pc=FC1674BC:registers at 00021B04

*where &FC1674BC
Address &FC1674BC is at offset &0003208C in module ‘SharedCLibrary’
*

If I re run it I get:

Unable to create file to receive requested data – can not fetch file.

Unable to fetch list of available manga, will look at at your library.

You library is empty, there is nothing to read, Sorry

Hope this helps.

Doug, can you rerun it with Debugger set up to make an annotated dump so I can see how it got to mucking up in CLib?
https://www.riscosopen.org/wiki/documentation/show/Debugger%20Exception%20Dumps

When does it abort – when fetching the big list?

Unable to create file to receive requested data – can not fetch file.

That’s usually because it crashed during fetch with the file left open. Closing it manually should fix that, but…

Also, IIRC it is running out of stack space, so perhaps try giving it a larger slot, see if that helps? Try 16384k.

can you rerun it with Debugger set up to make an annotated dump

Done and sent along with Manga scrap contents.

abort – when fetching the big list?

Yes I believe as the fetch is obscured by the Abort handler window.

Try 16384k

Sorry doesn’t sort the issue out and I had tried increasing it before.

Hopefully you have enough information but if not let me know and I see what other information I can send.

Take care..New Independence day 20th January 21 :-)

Okay, I’ve been working with Doug’s help using builds that log output to DADebug, and it appears to be screwing up at the _kernel_swi() call to URL_ReadData (I’ve just given him a link that outputs even more debug info, to see if it can be narrowed down and to confirm this for certain).

The known knowns at the moment:

• it works on my Pi (RISC OS 5.23)
  Update1: just installed last night’s version of 5.29 and updated AcornSSL (which isn’t used, it’s an HTTP site), URL/AcornHTTP not changed from my versions. Works okay on my Pi2…
  Update2: Since I’m now running a high vector build, just checked and… no pain encountered in loading, fetching/parsing the big list, choosing YuruCamp, and getting it up on the screen.

• it works for Willard (on what machine / OS?)

• it doesn’t work for Doug on an ARMX6 (5.29)

Does anybody have any results (works/fails) to add? Particularly if you’re using the same OS version and/or hardware?

Test re run with latest Run/Runimage and output sent to Rick.

I did spot I was running Christian Ludlam’s AcornURI 1.05 so tried it with the lastest 0.27 official build as well with the same effect.

As noted in the email, (Acorn)URI != (Acorn)URL. ;-)

Looking at the log file, it appears that the URL fetcher is cycling until the point where it has data to return (http code 200) and then it blows up.

The strange thing is that this part of the code wasn’t changed in the conversion. It is using a different fetching method (regular http) but that’s out of my control. I just tell the URL module what I want and it goes and gets it…

Oh sorry, original (ARM7) pi2 , riscos 5.28, no special changes.

I thought I’d test it for you, ARMX6, RO5.29. Attempting to run it gives “unable to load URL version 0.28 or later”.

Edit:

I have now added the updated modules from the 5.28 hard disc image. The update I did to 5.29 previously followed R-Comp’s path, so I’m not sure why they were missed.

!Manga now runs.

Version 0.54 is available. The updater will notify you, or you can fetch it from http://heyrick.ddns.net/manga/

Various tweaks to see about getting it working on Doug’s machine (though he reports it works on one and fails on two, so I’m wondering if there’s some sort of interaction with something already loaded – one to watch…).

• The fetch chunk size has been increased to 4KiB (was 1KiB). This was originally done in order to give 4KiB of space to write a 1KiB chunk into in case the URL fetcher was somehow overrunning, but when this didn’t seem to make any difference, I just switched the chunk size to 4KiB. Should mean fewer SWI calls to fetch stuff, though it’s debatable whether or not you’ll notice any actual difference in download speed.

• In practicing what I preach (see the StubsG thread), I have examined every single sprintf, strcat, and strcpy. In all cases where the string being manipulated was not known to fit (already truncated or fixed length constant), the calls were changed to use snprint, strncat, and strncpy to build in better prevention of errant buffer overruns.

• I tried the Library download, and MangaHere quickly rejected all further fetches. Yet NetSurf carried on working. A little test showed that quitting and reloading AcornHTTP got things working again (briefly). Which suggested to me that MangaHere’s anti-leech “protection” worked by using some sort of session cookie.
  So now Manga will wipe all mangahere cookies after every fetch while downloading to the library.
  The unexpected benefit? It so fully defeats their anti-leech protection that I don’t even need to bother with the holdoff delays any more. So Manga will now run as fast as it can run.
  Consequently, I downloaded all of Anne Freaks this afternoon – 24 chapters totalling 721 pages – in about forty minutes. ;-)

• Noticed the “Add to library?” prompt was embedded rather than in Messages. Fixed.

• This version built without parser debugging since it appears to work correctly.

• Changed !Run to report if CLib is too old, but not attempt to RMLoad a newer one. I know everybody does it, but they shouldn’t. ☺

• MangaLib → fixed EnumLib to correctly read the manga title…was reading the alternate name by mistake, which was often (but not always) a copy of the title; MangaHere does not provide alternate names.
  Also added a reference to the download source, though this is not so useful in the case of MangaReader.

Have fun!