Bug in XY thumbnail memory management

[admin]

OK, should be fixed in next version.

[klownboy]

Thanks Don. I haven't seen any of the issues noted in the first post since v14.50.0206.
Ken

[klownboy]

Hi Don, I have noticed something that wasn't the case before the memory management changes even with the earlier fix. Now, if you are in the folder for which you've created thumbs, you can't delete the associated "dbits " file. That never was the case, even though the thumbs displayed in the current folder properly, the "dbits" file itself could be deleted. To duplicate, if you make a thumbs for a folder (fresh creation), move away to another folder and come back to the original folder in which you've made the thumbs, the "dbits" file can't be deleted. I'm doing it by script, but if you note thecreated thumbnails file in <xythumbs> and then try to delete it you can not while in the folder. Even if you create new thumbs in the 2nd folder visited, when you return to the original folder the "dbits" file for that original folder can't be deleted. I could see not being able to delete the file if the file was open in the Info Panel Hex viewer, but the displayed thumbs in memory never prevented the deletion of the dbits file.
Thanks,
Ken

[admin]

Yep, that's caused by the way it is done now. Data are streamed live from the dbits file. So it is open while the thumbs are shown.

[klownboy]

Thank Don, I'll have to recognize that in my ThumbnailMaintenance script in some way. I imagine I'll have to make sure the user is not in the folder in which they're deleting the associated thumbnail database. I can't see that it should affect the refreshing or building of thumbnails in any way. Thanks.
Ken

[klownboy]

Hi again Don, I've been trying to build into the Thumbnail Maintenance script the issue we discussed above, in that the dbits file can not be deleted if you currently residing in that folder viewing those thumbs. I found the problem goes beyond that however. I been testing and working on the script to take the user out of the folder and even change views as well. What I found is, it doesn't matter, I still can not delete the "dbits" for the folder even after moving out of the folder and/or changing the view. Forget the script, even manually you can't do it.

In your last post it made sense,that with the new memory management you couldn't delete the "dbits" file in use. As you said, it's open while the thumbs are shown. Well it's staying open (in memory) and not permitting deletion even after moving out and no longer viewing those thumbs. So something definitely not right...staying in memory long after use. Thanks.
Ken

[admin]

The last used data stream is kept open to allow you to quickly go back to that last thumbnails view. It's a "smart" optimization I took the freedom to implement.

[klownboy]

I finding though that it's keeping more than just the last one in memory though there doesn't seem to be consistency. From testing, I found 2 or 3 dbits files that can't be deleted (until a restart). Sorry for asking, but are you sure all is right with the process of releasing memory on one set of thumbs after viewing another?

[admin]

Are you caching thumbs or not?

[klownboy]

Yes, definitely caching with SuperFast off.

[admin]

If you show thumbs in both panes it will be 2 open dbits files, but not 3. 3 would be a bug.

[klownboy]

So as far as revising a script, what in your mind should I be able to do theoretically, provided there are no bugs, to be able to delete that cache? Say for example, if a user is in a folder which has thumbs, and they mark/select from the database of dat2/dbit files caches for deletion, and one of the selections happens to be their current folder, what can I do to ensure the cache for the folder is deleted? Right now I have checks built-in to see if any of the folders selected in the database is the also the current folder and also check the thumbnail size selected for that folder is the same. If the current folder and a selection match, I get the user out of that folder, do a refresh and attempt the deletion. It wasn't working earlier but possibly it was the second pane business.

I didn't have the 2nd pane open earlier while testing. But, would it matter if it was closed but the last folder viewed was in a thumbnail mode? Usually my 2nd pane is never left in a thumbnail mode (i.e., I have pane 2 set for my first tab which the root of C: drive and in the "List" viewing mode). I'll keep testing additional scenarios.
Thanks,
Ken

[admin]

OK, I don't have too much time to spend on this, but I quickly added a small undocumented scripting command that removes all thumbs from the current list and closes the related cache files:

Code: Select all

unthumb;

Check it out in the next beta...

[nerdweed]

Wow.
That's a smart idea. Best of both worlds.

[klownboy]

That is great idea. Thanks Don. I assume that would be list of folders as opposed to image files since thumbs for image files would not necessarily make up the entire cache. As you know, each pair of cache files (dbits and dat2) are per "folder" at a particular thumb size. Any chance I would be able to pass a separated string of folders to it. It would be better for scripting since the folders may be obtained via an "inputselect".

By the way today I don't seem to be having an issue deleting the cache files after moving out of the folder and refreshing. Though I didn't think so, since I rarely use the 2nd pane, maybe the 2nd pane was the culprit. Who knows. Thanks again.