New Release?

[brazenvoid]

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?

[Bionus]

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 settings.ini file by adding a enableJsModels=true line just after [General].

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:

• Empty names bug in "save as..." Dialog for Zerochan images #925
• Add support for JavaScript sources #1175 (not all sources have been converted yet, and some parts are still in the XML files)
• Favorite Counter Notification Icon #1060 (the current counter is pretty ugly)
• New Release? #1246 (small freeze when parsing pages)

[brazenvoid]

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...

[Bionus]

My bad, I updated the link:
https://github.com/Bionus/imgbrd-grabber/releases/tag/nightly

[brazenvoid]

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.

[brazenvoid]

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.

[brazenvoid]

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:
[Warning] [Qt][default] QCoreApplication::postEvent: Unexpected null receiver

[brazenvoid]

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:

• The processing of server response is almost instantaneous so there is almost no time for the app to go into an unresponsive state.
• The same group of tags gets completely skipped over correctly as existing files are skipped.

[akasintel]

Pixiv support please

and with the support of the injection of the Gif

[Bionus]

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.

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.

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.

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.

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 settings.ini file in the [General] category, with enableJsModels=true to enable them and enableJsModels=false to disable them.

After further tests, the non responsive behavior occurs right after it downloads a page. In the response processing phase. I guess?

Yes, it's very likely that those freezes occur when parsing the results.

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.

What do you mean "smoother"?

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.

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).

Doesn't Windows ask you whether you want to wait or kill the program in those cases? Then you could tell him to wait.

Also I repeatedly receive this warning while batch downloading:
[Warning] [Qt][default] QCoreApplication::postEvent: Unexpected null receiver

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.

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 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).

---

Pixiv support please

See issue #738.

[brazenvoid]

• Sometimes the freeze is about 10-15 seconds but sometimes it just gets stuck in it for a quite a while till windows closes it.
• So there are three possibilities when freezing occurs. One is that you wait it out and it resumes downloading. Second is that it does not resume and in about a minute windows closes the app without giving the option to wait (Maybe its specific windows 10). Third is that you get frustrated and do a bunch of clicks, windows then throws that wait dialog.
• Well smoother meaning that the browser seemed smooth in loading and displaying images and there were no placement issues. Like in the release version, I sometimes go to a page and an image (the last one in a random row) starts to play roulette with the first position in the row below.
• I will do specific tests again with and without JS sources for the freezes. I don't remember the setup when I tested before.
• I will also try to reproduce that existing images thing.

And I have mostly tested on rule34 and gelbooru, other I only tested in the browser.

[brazenvoid]

So the issues below only appear after about 3-4 hours of constant usage:

• The save function in the preview window should wait for the file to get downloaded but for some reason it stops doing that. It just saves the image and stops the download when the "save" or "save and close" buttons get clicked. Thus image gets downloaded partially.
• Grabber might start micro-freezing when doing bulk downloads. Only way to resolve this is to clear the log immediately. Does not happen, if the log tab is disabled. Happens on release version too. In fact, frequently clearing the log can make the app much less susceptible to crashing.
• If you change pages and a media is being downloaded in a preview window, it gets interrupted.

The following issue occurs after Grabber survives (:P) 6-7 hours of use:

• The preview window first randomly stops showing preview especially for bigger images then completely stops showing the previews. It might recover for some time but will relapse eventually. This behavior can happen earlier too, if higher resolution images are browsed.

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.

[Bionus]

Sometimes the freeze is about 10-15 seconds but sometimes it just gets stuck in it for a quite a while till windows closes it.

So there are three possibilities when freezing occurs. One is that you wait it out and it resumes downloading. Second is that it does not resume and in about a minute windows closes the app without giving the option to wait (Maybe its specific windows 10). Third is that you get frustrated and do a bunch of clicks, windows then throws that wait dialog.

I will do specific tests again with and without JS sources for the freezes. I don't remember the setup when I tested before.

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 smoother meaning that the browser seemed smooth in loading and displaying images and there were no placement issues. Like in the release version, I sometimes go to a page and an image (the last one in a random row) starts to play roulette with the first position in the row below.

Well, that's good to know then 😄
I indeed did a bunch of changes to the layout, so some issues might have been fixed.

I will also try to reproduce that existing images thing.

If possible, because I could not reproduce this.