Your comments
Just so you know, I have not forgotten this issue. I just chose to rewrite the online reader from scratch to manage user defined sizing and double page auto-split. Work in progres...
I don't know much about CPU performances, but I guess the ARM CPU of the Pi 2 is not as fast as the Atom you were using before.
I will have to do a few tests on my own Raspberry Pi (an "A" version, the slowest that exists, so I should be able to reproduce the problem easily) to determine which step is the most CPU intensive (extraction or page resizing). I also have plans to allow direct file download in the online reader (without conversion): combined with native extraction tool, the performance boost could be quite noticeable.
I will have to do a few tests on my own Raspberry Pi (an "A" version, the slowest that exists, so I should be able to reproduce the problem easily) to determine which step is the most CPU intensive (extraction or page resizing). I also have plans to allow direct file download in the online reader (without conversion): combined with native extraction tool, the performance boost could be quite noticeable.
Since you have the problem in the Pi browser itself, I suppose network congestion is not its cause. Two lengthy steps remain: extraction from the archive and resizing/reencoding.
Extraction can be slowed down by file system (are your comics hosted on the Pi memory card or on a network drive ?) and by CPU.
Resizing/reencoding rely only on CPU.
The CPU load of 25/50% is probably because only one of the cores is used to unzip or resize the image. So having a 25% load means a 100% utilization of a single core.
I'm guessing performances were fine even for big pages on your previous device, right ? What kind of machine was it (more specifically what kind of CPU) ?
Extraction can be slowed down by file system (are your comics hosted on the Pi memory card or on a network drive ?) and by CPU.
Resizing/reencoding rely only on CPU.
The CPU load of 25/50% is probably because only one of the cores is used to unzip or resize the image. So having a 25% load means a 100% utilization of a single core.
I'm guessing performances were fine even for big pages on your previous device, right ? What kind of machine was it (more specifically what kind of CPU) ?
There is probably a memory leak in the code doing the scan. I'll investigate someday, but finding the root cause can take time.
In the meantime you can either relaunch the scan after each crash (not a very satisfying solution but once the initial scan is finished, you should not have the problem ever again) or give Ubooquity more memory to work with.
In the meantime you can either relaunch the scan after each crash (not a very satisfying solution but once the initial scan is finished, you should not have the problem ever again) or give Ubooquity more memory to work with.
You're right, it's not implemented.
I'll add it to my bug list.
I'll add it to my bug list.
Customer support service by UserEcho
Configuration would look like that for instance:
{issue #} - {comic title}and display:Not exactly what you requested (the title would still be displayed as a single string of characters) but more flexible in my opnion.