Explorer become unstable about darkthumbs HOT 19 CLOSED

Look stable now, thanks a lot !

from darkthumbs.

DarkThumbs V1.1 release should address these issues.

from darkthumbs.

I have a hypothesis, from examining the source and @Bostwickenator comment. I'm not in a position to test.

I believe it is the use of the [C]T2A macro which is causing the problem:

std::string name;

name = CT2A(_z.GetItemName());

if (name.compare(rootfile) == 0) {

The T2A() macros allocate the string on the stack which is automatically released when the stack is unwound. Because the use of T2A() is inside of a loop, the stack might not be unwound for a while!

The code shown above is inside a loop iterating over the filenames in the EPUB file. If (e.g.) the EPUB archive contains a lot of files and the target "rootfile" is physically near the end of the archive file list, a lot of T2A() calls accumulate.

To make things worse, if the target file is not found in the above loop, a second loop is executed in the same stack context! The second loop iterates over the archive file list, looking for a "cover" file:

std::string imgFilename(T2A(_z.GetItemName()));

if (imgFilename.find("cover") != std::string::npos)

[Also, unless I mis-read the code, this second loop doesn't short-circuit, so even if a "cover" image is found right away, the loop continues to check all the other files in the archive.]

If my hypothesis is correct, I see two options to address the T2A problem:

1. Put the loop contents [not the loop, the guts] inside a function. Then the T2A() call per file will be auto-freed and no stack overflow.
2. Stop trying to use std::string / strcmp and perform LPWSTR comparisons like the ZIP/RAR code.

The same issue may also be found in GetEpubTitle.

from darkthumbs.

Fixes for a "V1.1" in progress.

from darkthumbs.

Haven't experienced this issue myself. Though I have felt explorer a little laggy dealing with Epubs. This is to be expected. It's extracting cover photos from inside zip files. It's slow. Probably your pc or hard drive is too slow?

from darkthumbs.

Hi
Thanks for your answer. My computer is i7, 16gb Ram, SSD drive. I don't think that is a slow PC ;-) Everything works well with cbr and cbz files who are the same kind of file. Again, it doesn't freeze during the process itself but few minutes after.

from darkthumbs.

Well. That's good to know it's not the pc. I am then unsure of the exact issue. Can you run process explorer or resource monitor and see what's causing the spike so we can troubleshoot?

from darkthumbs.

The processor run between 1 and 5%. The explorer is "sleeping" (processor 0%) but completely frozen.

from darkthumbs.

Hello same issues with folders containing lot of epub (contrary to @lepatachou, I'm using Windows 10 x64 1909, french version too), explorer become unstable not immediately but few seconds / minutes after entering in folder with some epubs.

I switched back to original version CBXShell 4.6.2 of T800 author. Sadly this version takes the first image found and doesn't follow correctly epub format's logic to extract the right cover but at least it does not make my system unresponsive.

Hope a solution will be found, otherwise there is a hope the MS Power Toys will handle it in the future : microsoft/PowerToys#2229

from darkthumbs.

I'm having the same issue as well it's interesting that rendering the thumbnails completes correctly and then as @s-kocher described it crashes explorer later. My guess is some handles not being disposed of correctly. I'll have a look into this when I have a bit of spare time to do a debug build.

from darkthumbs.

What seems to be the issue, is not folder containing lots of epubs. I have folders with literally 25,000 of them and it does not crash. What it crashes on, are ePubs with LOTS of FILES inside them. The parser is trying to grep through tens of thousands of lines of code and ends up crashing before it is able to find the actual cover image.

I would say you will find the culprit is either one or a select few of books causing the crashes. DarkThumbs can be switched on and off without restarting so if you want to experiment. Split the folders into 3-4 folders and see which one crashes explorer. Then repeat till you find the offensive files.

Hopefully Bostwickenator is able to find something, otherwise, for working 99% of the time, for me it is close enough.

from darkthumbs.

So I did some debugging, about 8 hours of trying to locate the problem in all honesty. There is a stack overflow happening. This is when too many bytes of local variables are allocated. The ZIP file itself should be getting loaded into heap space but as you say something about large files is exhausting the memory budget. It's quite confusing.

from darkthumbs.

So, I don't know what he is using to extract the zip files, but I am unsure why it is being so complicated. Using simple commands in 7zip for example, he could be reading the file content.opf (like this https://superuser.com/questions/462788/read-the-contents-of-a-zipped-file-without-extraction) then grepping through it for the line that contains id="cover" then extracting the filename from the line, for example cover.jpeg <item href="cover.jpeg" id="cover" media-type="image/jpeg"/> pointing the thumbs file to that file. I am unsure why he is loading the entire zip file into memory. Unfortunately I am not proficient in python...

from darkthumbs.

Same for me

from darkthumbs.

I have a hypothesis, from examining the source and @Bostwickenator comment. I'm not in a position to test.

So, unfortunately. I have no idea how to code C. The dev DarkKnight was hired by me a year ago to take the old CBXShell which had not been updated in years and make it work for ePubs. I had him make this repo so people could use it. However, he has not made edits in a while. In his defense, he has gone above and beyond what I paid him for, so, I do not expect him to do much more.

If someone is interested in forking or making a new repo. Feel free to take over the project and make it yours.

from darkthumbs.

Can anyone suggest what would be considered an epub "with a large number of files"? 100 files? 200?

Does anyone have an example of one of these large epubs?

from darkthumbs.

https://mega.nz/file/4cswAKJS#YCdzIwQjO5Erp2KA_EoJvOpHwiJ1KJCt3RVOlCTVsAg

edit: I am unsure where the line between works and breaks DarkThumbs. However, I know these files. Always break it. Crash explorer.

from darkthumbs.

Thank you for those!

As one of those epub archives contains over 10,000 (!!!) files, I suspect that is the killer. There are two others with over 5,000 files. They'll certainly exercise DarkThumbs!

[In my own collection the largest archive only had 600 files ...]

from darkthumbs.

lol I have had VERY few files crash DT. It is slow at times, but most the time it just cranks its way through it after being slow af lol.
Those files though... Insta crash. SO many files. But.. I downloaded them directly overdrive. so they are retail. Not some mashup from rando.

from darkthumbs.