Your comments
Interesting note: ePub is based on a zip container the same as CBZ, so if the epub has one big image per page and the image filenames are numbered sensibly, you can open the ePub as a CBZ and it'll work fine.
Since it's rather unpredictable how an ePub will render on 10 different devices, ePub authors usually avoid anything fancy like mixing image and text elements like they might do in a PDF comic (eg. using real text to do a letters page). So in my experience it's reasonably safe to assume the ePub will be just a bunch of full-page images. My app actually claims support for 'ePub' even though it simply treats it as another name for 'CBZ', and I don't remember every having a problem with one.
Bo: Try just renaming your ePubs to CBZ.
Since it's rather unpredictable how an ePub will render on 10 different devices, ePub authors usually avoid anything fancy like mixing image and text elements like they might do in a PDF comic (eg. using real text to do a letters page). So in my experience it's reasonably safe to assume the ePub will be just a bunch of full-page images. My app actually claims support for 'ePub' even though it simply treats it as another name for 'CBZ', and I don't remember every having a problem with one.
Bo: Try just renaming your ePubs to CBZ.
Just to chime in here: If you're gonna pre-extract images, you might consider preprocessing them at the same time (resizing, transcoding) and caching the result. Then when a request came in you could stream the raw file to the web-server instead of having to read the entire thing, process it, encode it, and *then* start transferring it.
I guess you could also just skip image processing completely and pipe the unzip output straight to the web-server (if the API allows it) - it'd be cleaner and simpler and I'm guessing just as fast, although it would also mean clients would potentially get sent images in weird formats or large sizes. But web-browsers and comic-readers are built to deal with those in any case so IMHO it's not a deal-breaker.
I guess you could also just skip image processing completely and pipe the unzip output straight to the web-server (if the API allows it) - it'd be cleaner and simpler and I'm guessing just as fast, although it would also mean clients would potentially get sent images in weird formats or large sizes. But web-browsers and comic-readers are built to deal with those in any case so IMHO it's not a deal-breaker.
It actually does try to cache up to 7 pages ahead and 3 behind your current page. But if each page is taking 20 seconds to load, it's not gonna get very far with that...
For the speed issue, you should be aware that a badly-compressed CBR can be death for performance - if 'solid' mode is enabled, the whole thing is compressed as a single blob, which means that if you want to get page 100, you first have to decompress pages 1-99 to get to it. You can normally spot this when reading gets slower and slower the further you get through the comic. Chunky deals with these by unzipping and rezipping them when you import them, which is why some comics take longer to import than others.
Dunno if that's the issue though.
For the speed issue, you should be aware that a badly-compressed CBR can be death for performance - if 'solid' mode is enabled, the whole thing is compressed as a single blob, which means that if you want to get page 100, you first have to decompress pages 1-99 to get to it. You can normally spot this when reading gets slower and slower the further you get through the comic. Chunky deals with these by unzipping and rezipping them when you import them, which is why some comics take longer to import than others.
Dunno if that's the issue though.
Aaaaah gotcha.
I'm out of my own area of expertise, but out of interest, are the comics CBZs or CBRs?
I'm out of my own area of expertise, but out of interest, are the comics CBZs or CBRs?
Do you have a lot of comics in your library? Chunky has to fetch them in small batches which slows things down if there are a lot - you might improve matters if you organise them into folders and browse by folder.
Sweet! Thanks
Honestly if I was starting the app now there'd be proper support for remote libraries, but it'd be a ton of work to add at this point. Probably the best I can manage is what I do for ComicStreamer - show the web UI, but detect when you tap a comic and open it in the native reader. It's planned, but it might be a while.
Glad you like it btw :)
(and apologies for going OT, Tom, not intentional)
Glad you like it btw :)
(and apologies for going OT, Tom, not intentional)
Hi Super,
The address you need to enter isn't the same as for the web-interface - it's shown in the Ubooquity in Advanced Settings when you select 'enable OPDS', it'll be something like '192.168.0.123:2202/opds-comics/' (and make sure you have OPDS actually enabled while you're there)
The address you need to enter isn't the same as for the web-interface - it's shown in the Ubooquity in Advanced Settings when you select 'enable OPDS', it'll be something like '192.168.0.123:2202/opds-comics/' (and make sure you have OPDS actually enabled while you're there)
Beautiful...will add support for the next update, probably within a month or so.
Customer support service by UserEcho
Cheers