-
-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Release? #1246
Comments
I truly wouldn't mind having a tester for this version given there has been a bunch of internal changes. As for getting the latest version, you can always use the nightly version. On there, if you truly want to help testing out the latest feature, JavaScript sources (which might be a little buggy), you'd have to enable it manually in your The full release will be made when all issues in milestone 5.6.0 are completely finished. As far as I know, the remaining ones are:
|
The nightly link isn't working or do you want me to setup the compilation environment and make the build? It has been over 4 years that I have last worked on any desktop application... |
My bad, I updated the link: |
Images from rule34.paheal.net start out in a small size (Image Detail Window), almost the same size as a credit card placed at its longest at the vertical. Only when they are downloaded fully, do they revert to the default view. |
The release stutters more now. Like on each page load it goes unresponsive for a small period. The pause during page change in an ongoing download is also more pronounced. But somehow the overall flow feels a lot smoother as long as you don't click in the app during those pauses which then sticks that non responsive mark on it momentarily. I don't know about your implementation but last time when I developed a Steam like gaming client in C++ and Delphi, I had devised a successful solution. After months of research and experimentation, I had made the UI go in a separate thread with a queue of UI updates managed by another thread. The queue had nodes with locks, lock expiry time and some status flags to deal with race and error conditions. Only then was our app responsive enough to simulate an internet like environment over LAN with games like Warcraft 3 with its frequent sub-second keep alive packets to many peers/clients through 4 separate interfaces. The UI was also completely, hardware accelerated 3D. Unrelated scenario, I understand but shows the benefits in the responsive department. |
Well the non responsive behavior is really difficult to deal with, while browsing and batch downloading, one does inadvertently make a click and windows being merciless, closes the program. Also I repeatedly receive this warning while batch downloading: |
After further tests, the non responsive behavior occurs right after it downloads a page. In the response processing phase. I guess? Somehow now its always going into that state on page change and finally windows closes the program (now it doesn't take a click to do it). Also seemingly its not respecting existing files and md5 existence. I have done batch downloads of a group of tags back to back and every time it downloaded the same files again. As if, those files do not exist. I have verified the above behaviors with the release version:
|
Pixiv support pleaseand with the support of the injection of the Gif |
Indeed, that's what happens when Grabber does not know the image dimensions when opening the image window. When it knows it, it will scale the thumbnail to the full size, to have a "blurry" image until the image is loaded. I pushed a fix to the JS model to parse the width and height with the RSS source.
How long are those "freezes"? I also noticed them, but they maxed out at 2s, very rarely longer than that. Does this only happen with JavaScript sources enabled or also when it's disabled? You can change this setting in your
Yes, it's very likely that those freezes occur when parsing the results.
What do you mean "smoother"?
Doesn't Windows ask you whether you want to wait or kill the program in those cases? Then you could tell him to wait.
You can safely ignore them. Those warnings used to be hidden, I simply decided to add them to the log with this update, as they should be.
I can't reproduce on the latest nightly version. Maybe I fixed it as I worked on that part of the program in the last few days. Otherwise, do you use the "multiple files" feature? (that is, one image saved in two locations on save, for example for each "artist" tag).
See issue #738. |
And I have mostly tested on rule34 and gelbooru, other I only tested in the browser. |
So the issues below only appear after about 3-4 hours of constant usage:
The following issue occurs after Grabber survives (:P) 6-7 hours of use:
When the above happens, its best to restart grabber as that indicates that a crash is imminent. These all seem to be memory related issues. |
Ok I found the origin of this problem, it was a stupid mistake on my part when copy/pasting something. The fix was pushed two weeks ago: 35dceef. It's indeed totally unrelated to JavaScript sources.
Well, that's good to know then 😄
If possible, because I could not reproduce this. |
Please don't mind but the latest release was on October 29 and April's end is approaching... almost 6 months. When can we expect the boatload of fixes on develop to come to the release channel?
If you want a tester, I can volunteer?
The text was updated successfully, but these errors were encountered: