Your comments
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.
I'm afraid this feature will not be implemented before a little while, a lot of bug fixes and core features enhancements to do first.
I have not put much thoughts in the way I'll implement it yet, but the reader integration in the OPDS feeds simply consists in providing the OPDS client with a template link to get comic images.
So when server-sync is implemented, it will very probably work the same whether you open comics through the usual web page or through the OPDS feed.
I have not put much thoughts in the way I'll implement it yet, but the reader integration in the OPDS feeds simply consists in providing the OPDS client with a template link to get comic images.
So when server-sync is implemented, it will very probably work the same whether you open comics through the usual web page or through the OPDS feed.
Customer support service by UserEcho
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.