Getting Timed-Out Whenever I Try To See Explicit Images In My Favourites

As it says in the title, I keep getting timed-out whenever I try to check how many explicit-rated images I have in my Favourites. This strikes me as odd since:

*I don't get timed-out whenever I check fav:Canadabro followed by either rating:safe or rating:questionable.
**The same goes for the search status:x (active, pending, deleted, etc.)
*I can check fav:x (any user) and rating:explicit without getting timed-out

Since I am a member, I have a database timeout of 3 seconds. I find it strange that it takes more than 3 seconds to check the explicit images I favourited for organizing and checking how many I have. Does anyone have any ideas as to how this problem might have come to be and how it can be fixed?

I thank you in advance for reading this post!

You have only 21 rated Explicit, but I don't see why it would time out, unless the actual search page doesn't exist in which case there'd probably be a 404 error but I don't see how it all works. Maybe it works by removing posts? That's the only thing I can think of that's even possible...

That's another thing I find strange about it. While I most likely have safe-rated images in the quadruple digits and questionable images in arguably the triple in my favourites, I know I do not have many explicit-rated images in my favourites, yet I get timed-out when I try to check them. I have been steadily removing deleted posts from my favourites, but I replace them with newer posts. It's a bit boggling to me.

I'm able to execute the query, but I have a longer timeout. It feels like it's taking about 5 seconds to complete (Danbooru doesn't report database execution time anywhere, does it?)

I am not an expert on databases or optimization, but I wonder if the limited number of results is actually the cause. With rating:safe it quickly finds a full page of results - and presumably stops execution right there. With rating:explicit it needs to keep searching through every favorite (every post?) until it reaches the end, since there isn't even a full page of results.

If so, you could temporarily fix this by just favoriting a lot more rating:e posts. It might make the db query stop sooner. I'd say it's worth a try.

If that is the case, qaz, then Wiimeiser would not be able to see the search results for fav:Canadabro+rating:explicit since he would be timed-out as well. It seems that the results may vary from person-to-person. This is becoming curiouser and curiouser...

It took 6 seconds to complete for me.

Not really sure what the cause is (other than the fact that only 0.2% of your 10,000 favorites are explicit, resulting in scanning a large number of posts for a small number of results), but if you want to try a temporary workaround, you can lower your limit, like so: fav:canadabro rating:e limit:3. Should be a bit faster, if more annoying to browse.

Canadabro said:

If that is the case, qaz, then Wiimeiser would not be able to see the search results for fav:Canadabro+rating:explicit since he would be timed-out as well. It seems that the results may vary from person-to-person. This is becoming curiouser and curiouser...

Not necessarily. He could have done a search on /counts/posts.json to get the number of posts. That responds in 0.2 seconds for me, so even a basic member could do it.

Or maybe he just got lucky and the query completed in less than 3 seconds for him even though it normally takes longer. It wouldn't be that strange for a query to take different amounts of time at different times of day, such as if the server was under less load sometimes than others.

Alternative workaround: Try ordering by something else, like so: fav:canadabro rating:e order:score

Actually, I figured it out by a process of elimination, I counted the number of Safe and Questionable pots based on (Pages-1)X20+Number on last page, which gave me 1 page + 1 post left over, or 21. Just some math.

Toks said:
> workarounds

Just a reminder: these won't work for basic member because of 2 tags search limit.

richie said:

Just a reminder: these won't work for basic member because of 2 tags search limit.

fav:canadabro rating:e limit:3 will still work. The limit metatag doesn't count when calculating that limit.

But you're right that fav:canadabro rating:e order:score won't. Forgot about that.