It's a bug introduced in 1.7.0.
It will be fixed in the next release.

This warning ("Could not understand cookie header") is triggered by the cookies created by the Synology interface in your browser. It can be safely ignored (and I should probably remove it).

Share all you want ! The plugable theme feature has been implemented so that people can do exactly what you did. :)

Very nice theme by the way.

Ubooquity is not supposed to depend on the number of files that are scanned (at least not enough to cause memory problems).

Increasing the memory dedicated to Ubooquity is indeed an adequate workaround, although not a definitive solution (if a bug has to be found and fixed).

Lots of questions here, I'll try not to forget anything. :)

• Broken link of the Synology package: unfortunately I merely added a link to the forum thread in the F.A.Q. I am not in contact with the author of the package. The most efficient thing to do would probably be for you to ask him directly on the Synology forum. 
  According to his signature, the packages he made are available on the following repository: https://synopackages.welike.technology/
  Might be worth a try...
• Problems with CBR files: Ubooquity uses a third-party library (called Junrar) to access images contained in RAR (cbr) files. The lib has not evolved for years and I don't have the skills to fix it. So improvements to the way Ubooquity manages cbr files is highly unlikely.
  But to be honest I never understood why people thought it would be a good idea to package comics in RAR files rather than in Zip files. Personally I convert all the cbr files I get to cbz files as a matter of principle.
• OPDS: You don't like the web interface ? ;) The only application supporting streaming with OPDS is an Android one: Challenger Comics Viewer. That's because the OPDS standard is not made for streaming and we add to extend it. The good news is we wrote specifications for this (very small) extension. So every developper of a comics reading application is free to add streaming support with immediate compatibility with Ubooquity.

Files informations are written to the database after every file during the scan. So even if you abruptly stop the scan, what has already been scanned is not lost.
Of course Ubooquity will have to check the files names and modification date the next time a scan is launched, but it is very, very fast (the time consumming operations are the thumbnail extraction and generation as well as the metadata extraction when they exist).
As for the scan period, it does not really matter for the initial scan as a new scan won't be launched until the first one is finished.

Now you can launch multiple Ubooquity instances as long as:

• they are launched in different folders
• they run on different ports

But it would be interesting to understand why the scan fails at some point.
Do you see any error in the log file when the scan stops ?