- Mar 15, 2020
- 1,985
- 1,978
- 360
MeAndTheDevil
Newbie
- Apr 15, 2025
- 39
- 28
- 57
- Oct 1, 2020
- 1,611
- 1,126
- 327
- Mar 7, 2019
- 1,591
- 1,441
- 459
i assume you mean from bottom to top of the images that are visible on screen (as opposed to loading iimages that are not visible)? this is just a side effect of how it is implemented. the intention is for images to be loaded only when shown, but since images take time to load they are inserted at the beginning of the list when they are first shown, so that if you happen to scroll, the newly shown images take precedence in the queue of images to load, and images that were shown previously stay behind in the queue since they may now be off screen; and because of that, since images are drawn top left to bottom right, and each image being shown is inserted at the beginning of the queue, they end up with the last drawn image (the furthest bottom right image) being first in the queue. effectively, images are added to the queue in the inverse order that they are drawn. but still, its only visible images that this happens to, so it shouldnt make much difference usually. if you have the "preload nearby images" option enabled, then this is made a bit worse because the same concept applies of the furthest bottom right image being first in queue to load, but it also considers an extra screen length's off screen of images to queue loading, so effectively it starts first loading images that are not visible when initially shown.
this happens basically everywhere in the tool, in grid and kanban view too, but im guessing you use list mode so you didnt notice until now.
its not intended, but it is expected. it is what it is. not gonna change the behavior on the python version, but i hope to come up with a better scheme for deciding strategically the order to load images in for the C rewrite (something like not using a persistent queue, instead each frame seeing which images were on screen but not loaded, and trying to load those in order of file size (so as many images can be loaded as fast as possible initially), then by the time the next frame is drawn clear the queue and repeat so images no longer on screen dont stay in the queue; this is just an idea for now though).
- Mar 7, 2019
- 1,591
- 1,441
- 459
i think you got those the wrong way round.
by default, it will only try loading images that are visible, the fact it does this from bottom right to top left of what is visible on screen is an unintended side effect of the way i implemented it.
with the "unload off-screen" option you can decide if they should be unloaded when no longer visible.
with the "preload nearby images" option you can make it try to also load images that are not visible, and due to the fact they are loaded bottom right to top left this can unfortunately mean it considers loading the ones off screen before the ones visible, within the bounds of what the "preload nearby images" option considers valid for loading.
no, the way "preload nearby images" works is tied into "unload off-screen". what "preload nearby images" does is make the range of images that is considered "on screen" larger than it actually is, considering ones up to a window height above/below and a window width right/left of where the window ends. this means that it will try loading these images regardless of the other image options, and that "unload off-screen" will only consider unloading ones outside the bounds of "on screen" which may be the actual window size, or triple that if "preload nearby images" is enabled.
yeah i do want to make it a bit better in the C rewrite. what "unload off-screen" and "preload nearby images" will be mostly the same, but i hope to make image loading overall more intuitive. something like still prioritizing actually on-screen images before preloading nearby off-screen ones if "preload nearby images" is enabled, and (if compression is enabled) compressing images in the background as soon as it notices they are not compressed rather than when they are shown.
- Oct 1, 2020
- 1,611
- 1,126
- 327
Correct me if I'm wrong, but didn't you once explain to me, the bottom-right to top-left loading order was intentional? So that when you scrolled down, images would already be loaded, instead of having to wait until they showed? You even pointed me to the old code where it still loaded them top to bottom. Mind you, this was way before the two mentioned options got added.
Which is why I suggested this, even though the loading order wouldn't change, the ones currently off-screen would still be loaded faster than without it enabled because the 'range' is smaller.
Last edited:
- Mar 7, 2019
- 1,591
- 1,441
- 459
hm maybe i did add an afterthought excuse for why its "better" like "hey it kinda works out because if you want to scroll, the bottom row is what will be the top row after scrolling so it appears to load faster", now that you mention it i vaguely remember saying something to that effect, but yeah originally the behavior was not intentional.
as i said in reply to gab, i dont think i will keep this behavior in the c rewrite, i think i will optimize for loading as many as fast as possible, so loading in order of file size (among those visible on screen, and all the other logic with the 2 other options) should mean they appear to load faster
- Oct 1, 2020
- 1,611
- 1,126
- 327
Does the F95Checker update-checks mod topics less often than game ones?
I've already updated my mod's original topic-post several times the last 3-4 days, but the checker still shows the messed up updated-date and wrong version number.
https://f95zone.to/threads/the-null-hypothesis-tnhuxmod-v0-8b1-12-freddygonzo.262923/
No idea how this works, but if the update-frequency is also dependent on popularity then I guess I see the next update next year or so.
I could correct some entries if I did something what the checker can't read correctly.
I've already updated my mod's original topic-post several times the last 3-4 days, but the checker still shows the messed up updated-date and wrong version number.
https://f95zone.to/threads/the-null-hypothesis-tnhuxmod-v0-8b1-12-freddygonzo.262923/
No idea how this works, but if the update-frequency is also dependent on popularity then I guess I see the next update next year or so.
I could correct some entries if I did something what the checker can't read correctly.
Last edited:
- Mar 7, 2019
- 1,591
- 1,441
- 459
the github readme explains this in detail. the OP in this thread is outdated, i keep putting it off and forgetting to update it. you fall into this category:Does the F95Checker update-checks mod topics less often than game ones?
I've already updated my mod's original topic-post several times the last 3-4 days, but the checker still shows the messed up updated-date and wrong version number.
https://f95zone.to/threads/the-null-hypothesis-tnhuxmod-v0-8b1-12-freddygonzo.262923/
No idea how this works, but if the update-frequency is also dependent on popularity then I guess I see the next update next year or so.
I could correct some entries if I did something what the checker can't read correctly.
i checked the state of the redis cache on the server manually, it had:
LAST_CACHED: 1752934710 (2025-07-19T14:18:30+00:00)
EXPIRE_TIME: 1753107510 (2025-07-21T14:18:30+00:00)
and in fact, when i tried getting the info via the api a few minutes ago the api noticed that the expire time had passed and it checked it again, it is currently up to date. it now has:
LAST_CACHED: 1753111493 (2025-07-21T15:24:53+00:00)
EXPIRE_TIME: 1753284293 (2025-07-23T15:24:53+00:00)
just doing a normal refresh with the tool will make the api update the data if it has expired. for other threads tracked by latest updates, which is what typically is more time sensitive, they are detected within a few minutes and data expires as soon as these changes are detected.
Hi there, this tool is fantastic and I use it frequently, thanks so much for putting it together. Unfortunately, as of yesterday I get hit with a rate limit whenever I try to import my watched threads, is there any way to fix this or do I have to sift through my watched threads to find the ones not currently in the app and add them manually? Hopefully the former because the latter would really suck given how many threads there are lol.
- Oct 1, 2020
- 1,611
- 1,126
- 327
I just tried this myself, and while doing so I see a message flashing bottom-right "Waiting for F95zone ratelimit...". Meaning, the app takes the rate limit into account, resulting in all of my watched threads getting imported.
Are you on the latest beta?
I'm on 11.0.3. What happens for me is that it gets stuck forever at a certain percentage and then just fails and tells me I've been rate limited, but yes I also see the message in the bottom right. A similar problem happens for refreshing, but it just stops at 100% and when I cancel it everything pops up as if it worked.
- Oct 1, 2020
- 1,611
- 1,126
- 327
Go to WillyJL's
You must be registered to see the links
Actions page (linked), even if you don't have an account you can use a google account as OAuth login, download the latest beta build 1647 and try that one.Too bad you can't specify the filter options from the "Watched threads" page in the checker directly. (WillyJL? Idea for the C Version? Unread, Last Updated and Sort by seems to be the most useful to limit the number of pulled threads if it does indeed cause a hard forum rate limit. Same with the F95 Bookmarks, pulling the labels wouldn't be necessary, since the user will know which labels he/she applied. They would simply need to enter each label one at a time.
Maybe even a better idea to ask Sam if they can't add a link export feature to those pages
)
Last edited:
TheSidewinder
Well-Known Member
- Mar 31, 2020
- 1,756
- 3,284
- 468
1647 == 11.0.3, I have the same version and am seeing the same behavior.
(EDIT: Whoops, no it isn't, 1647 is 11.1 ... my bad.)
Sometimes the refresh completes and the "ratelimit" message goes away, and anything new does pop up by itself in a separate window.
But other times it just sits there with the ratelimit message in bottom right, with the window in top right all Red, saying 100% After a full minute or two I get impatient (imagine that, lol) and I click the red window to cancel it. But when I do that, anything new does pop up in a window, too.
This isn't life-ruining, it's just a very minor annoyance. I can deal with it. I just thought I'd add to the reports of this happening. Not sure anything can be done about it since the site has to limit this (and I understand why).
(EDIT: Whoops, no it isn't, 1647 is 11.1 ... my bad.)
Sometimes the refresh completes and the "ratelimit" message goes away, and anything new does pop up by itself in a separate window.
But other times it just sits there with the ratelimit message in bottom right, with the window in top right all Red, saying 100% After a full minute or two I get impatient (imagine that, lol) and I click the red window to cancel it. But when I do that, anything new does pop up in a window, too.
This isn't life-ruining, it's just a very minor annoyance. I can deal with it. I just thought I'd add to the reports of this happening. Not sure anything can be done about it since the site has to limit this (and I understand why).
Last edited:
- Mar 7, 2019
- 1,591
- 1,441
- 459
both these issues are related to the same thing. f95checker does handle forum rate limits as much as it can:
- sends at most 1 request every 2 seconds to f95zone (xenforo requests)
- if one of these returns a ratelimit error, it waits 5 seconds then retries
- each time it fails again, it waits 5 seconds longer than the previous try
- tries at most 10 times
so basically it tries, then retries after 5s, then after 10s, then 15s, 20s, 25s, 30s... at the end its been basically 2 minutes without it getting past the ratelimit, so it gives up.
unfortunately, from what i understood by trial end error back when implementing this, the forum ratelimits are "dumb"/basic, its not a per-user ratelimit, its just how much traffic the server is getting in general. so during busy hours of the day it can just be nearly impossible to get through, and the best thing the tool can do is give up and you wait a few minutes or a few hours.
EDIT: about this: Sam is it intentional that rate limits are for overall traffic instead of per-user? if not intentional, sounds like a typical case of reverse proxy using the local / proxy address to handle ratelimiting, might need to check the X-Forwarded-For header instead (or whatever other header the reverse proxy uses) to get the correct ip address to ratelimit by
EDIT: anyway, as a workaround for the refresh not finishing, you can disable notifications checking; thats what it does at 100%, its checking notifications, which have to go through f95zone, if you disable them the refresh will only use the f95checker cache api and never ratelimit. watched threads and bookmarks unfortunately still need to go through f95zone.
Last edited:
- Mar 7, 2019
- 1,591
- 1,441
- 459
So it seems like there's no workaround for importing watched threads? Unlike just refreshing, I can't get this one to work at all. If not then thanks anyway, the tool is still amazing otherwise. I'm still a bit confused why this is happening now though, as it never used to happen even like last week.
Last edited:
- Mar 7, 2019
- 1,591
- 1,441
- 459
re-read my in-depth explanation please. in particular this part:
just so happens that this week is more busy then last week i guess. its out of my and your control.
- Oct 1, 2020
- 1,611
- 1,126
- 327
Uh... no, it isn't, that should be 11.1 beta...
but beside that... if you get the same with build 1647 then hopefully Sam will make it possible to export the links, given that it's out of WillyJL's control that might still be the best option to prevent taxing the forum database. I just didn't get the same behavior, guess I must have tried during a quieter period.
Last edited: