I sometimes browse ancient comics in thumbnail mode within Dopus just to see the first image, usually that is the cover one.
This works pretty well unless the images are inside another drawers(s), then nothing is rendered. Is there a way to bypass this? I mean make Dopus look inside these folders and choose an image to show?
Another minor thing it seems rar5 is not currently supported.
Thanks for reading!
Extraction is supported, for creating an archive a WinRAR installation is needed.
Thanks for answering Ixp,
Tho I see no relation between this "minor" issue (Dopus not creating thumbnails for rar5 archives while it does for rar4) and your answer, but I may be wrong.
For the record I have winrar installed
I use this tool to generate comic thumbnails. It works with multiple nested directories inside the archives, and it looks better than the Opus thumbnail that has a shadow on the left edge.
Downloaded and installed, but i do not see any diffencence.
Do i have to set any settings to activate it?
Thanks
RAR5 .CBR files should work fine as long as Use UnRar.dll instead of 7z.dll for decompression is on under Preferences / Zip & Other Archives / Archive and VFS Plugins / RAR.
(It is on by default if you're using the current version of Opus, so you would have to have turned it off for it to be off.)
In the next update, it'll work even if you have turned it off. (But I don't think there's any reason to turn off that option these days.)
Opus will look in the sub-folder for the comic book cover/thumbnail, provided there is nothing but a single folder at the top level:
// For comic books, use the (alphabetically) first image file (usually the cover) as the one and only thumbnail.
...
// At the root of the archive, there is just one folder and no files. Look in that folder instead of the root.
If you have multiple folders at the top-level of the archive and the cover image is in a random sub-folder, then the plugin won't look through all of them to find it. Same if there are non-image files at the top-level; it won't look for images in a child folder. The logic is just there to handle the common case where archive tools put the entire contents within a sub-folder of the archive.
(Maybe this needs too be changed due to the junk metadata that archive tools on OS X often spam into archives? Which extra files/folders are in your archives that are causing the problems?)
Thanks for the explanation, I handled to solve the rar5 issue, while I had UnRar.dll instead of 7z.dll for decompression already turned on, I've got the CBR VFS plugin off and the .cbr extension configured inside the RAR VFS, erasing the extension from this latter and activating/entering the file extension on the first did the job.
Regarding the multiple/nested folders I've encountered two types, the one you mentioned about OSX, that creates a folder _MACOSX with with junk images inside, and a second subfolder with the real images.
And the second type is just a nested folder with the images in it.
The second type should work already. Is it not working for you?
Morning, did a bit of testing and along the OS X already mentioned, below are some other possibilities blocking thumbnail display:
Top level .txt / .xml (some comic readers may add to archives like comicrack) while images are inside a folder
test.cbr
. /folder/image.jpg
./text.xml
And the two you explained in your first post that are also pretty common.
test.cbr
./folder/image.jpg
./folder/test.cbr
./folder/folder/image.jpg
Thanks! Those should all work in the next version (12.10.2 beta).
If you find any that still don't work, let us know.
The following is a request.
Sometimes the first image is not the cover but just an image with some info about the scan that normally has less than 100/75kb.
I wonder if it is feasible to add a configuration to skip that first image whose size is less than xx (user configurable) amount of Kb.
If this is too much hassle then don't bother this is my anal personality pushing in 
The real cover might be a small image and that would then skip the real cover in a lot of cases.
I think if someone has put an image in the file which is a screenshot of some text about how the file was made, and they've named it so it's the first image in the archive, then whoever made it should be talked to and convinced not to do that anymore as it's asking for trouble. 
I would rename the file to the end of the list, and then everything is fine.
cough cough!! renaming!! by hand!! 
