Hi,

Can we please show the number of results near the search box? Thanks!

You can just estimate the post count vis the number of pages
At the default 75 per page 750 pages is just over 56k
Any count the site would be able to give would also be an estimate (page numbers are built on estimates)

donovan_dmc said:
You can just estimate the post count vis the number of pages
At the default 75 per page 750 pages is just over 56k
Any count the site would be able to give would also be an estimate (page numbers are built on estimates)

I know, but the mental math of multiplying page counts by 75 is burdensome. And it's not a precise value.

The exact result count is useful when debugging programs that claim to automate downloads.

It's also useful when exploring combinations of tags, as some tag clusters are more fruitful than others. But the individual tag counts shown in the list of tags search page isn't indicative of tag combination counts.

Would still like to see the total displayed on search results pages.

shellyg said:
The exact result count is useful when debugging programs that claim to automate downloads.

And exact counts are expensive to calculate
Our previous developer has said that if counts were provided, it would be rounded to discourage using it as an exit condition
https://github.com/e621ng/e621ng/issues/228

https://re621.app will provide an estimated count for you on posts page, it will be more accurate on the last page

While it isn't my decision to make I don't really ever see this being added

For manual multiplication you can change the limit to 100 and just multiply by 100: limit:100

I could make a userscript that makes the estimation for you, I'll just need some time to do the typey-typey.

Just loading the last page doesn't give the exact count?

alphamule said:
Just loading the last page doesn't give the exact count?

Some tags are just too populated for that

Here's a basic userscript, like I said I'd do. It'll put some big text above the search results.

Current known issues:

• Won't display if there's only one page
• Can't give an exact count
• Shows an incorrect number if currently browsing the last page

But should work fine in all other situations.

// ==UserScript==
// @name         e621 Results Display
// @namespace    http://tampermonkey.net/
// @version      2024-09-18
// @description  Shows a rough estimate of search results.
// @author       LendriMujina
// @match        https://e621.net/posts?*
// @icon         https://www.google.com/s2/favicons?sz=64&domain=e621.net
// @grant        none
// ==/UserScript==

(function() {
    'use strict';
    let postBox = document.querySelector("#posts-container");
    let resDisplay = document.createElement("h2");
    postBox.parentNode.insertBefore(resDisplay,postBox);
    let postList = document.querySelectorAll("#posts-container > article");
    let pageNumbers = document.querySelectorAll(".numbered-page");
    let lastPage = parseInt(pageNumbers[pageNumbers.length-1].firstChild.textContent);
    let postEstimate = postList.length * lastPage;
    resDisplay.innerHTML = "Search Results: Approx. " + postEstimate;
})();

lendrimujina said:
Here's a basic userscript, like I said I'd do. It'll put some big text above the search results.

Current known issues:

• Won't display if there's only one page
• Can't give an exact count
• Shows an incorrect number if currently browsing the last page

But should work fine in all other situations.

I would look into how re621 does this if I were you.
1. Get page count with parseInt($("li.current-page, li.numbered-page").last().text()) || 1
2. Get the number of posts per page with $("body").data().userPerPage
Multiply one by the other, which should give you a reasonable estimate.

You can also determine if the user is on the last page of results by checking if the number of posts present is less than the user's configured number of posts per page.
If that's the case, you can do something like ((lastPageNum - 1) * postsPerPage) + lastPagePostCount) to get an exact count.

cinder said:
I would look into how re621 does this if I were you.
1. Get page count with parseInt($("li.current-page, li.numbered-page").last().text()) || 1
2. Get the number of posts per page with $("body").data().userPerPage
Multiply one by the other, which should give you a reasonable estimate.

You can also determine if the user is on the last page of results by checking if the number of posts present is less than the user's configured number of posts per page.
If that's the case, you can do something like ((lastPageNum - 1) * postsPerPage) + lastPagePostCount) to get an exact count.

Well, what if there's say, exactly 750 posts, and you have it set to 50, 75, 150, or 250 (as examples)?

alphamule said:
Well, what if there's say, exactly 750 posts, and you have it set to 50, 75, 150, or 250 (as examples)?

Set it to 320 and you can get up to 240,000
Anything more than that and you should be counting from the posts export

alphamule said:
Well, what if there's say, exactly 750 posts, and you have it set to 50, 75, 150, or 250 (as examples)?

Actually, it would work just fine. It's just the whole "determine if the user is on the last page" part is inapplicable.
You can just use the formula everywhere: ((lastPageNum - 1) * postsPerPage) + lastPagePostCount.

Let's say that there are 250 posts per page, and the search returns exactly 750 results.
Substituting the values into the formula, you get the same output on every page: ((3 - 1) * 250)) + 250 = 750.

Now, if the search returns 749 results, then the estimate on the first two pages would be the same as above, and thus slightly inaccurate.
However, on the very last page, it would be correct: ((3 - 1) * 250) + 249 = 749.

I looked at re621's code, and it seems to be doing something a bit more funky.
It determines if the user is on the last page of the results from the paginator. If that is true, it uses the formula above to give an exact count.
On other pages, however, it instead uses something like this: ((lastPageNum - 1) * postsPerPage) + (postsPerPage / 2).

I believe this is an attempt to address the fact that the estimate can be up to (postsPerPage - 1) off.
Whether or not that is actually necessary is debatable.