[X] My Assistant

Are we allowed to implement paging as a frontend browser extension function ourself?

I ask for this explicitly since such a paging function will create a larger amount of request per user, by automatically clicking prev/next buttom, thus generating 1 request per page skipped

There is a (quite strict/low) rate limit in place so it's probably fine 🤔

This post has been edited by FabulousCupcake: Dec 1 2022, 12:34

Are we allowed to implement paging as a frontend browser extension function ourself?

I ask for this explicitly since such a paging function will create a larger amount of request per user, by automatically clicking prev/next buttom, thus generating 1 request per page skipped

That user script already exist and was linked in this thread few times. You might also catch auto ban if you spam too many requests, i think somebody mentioned that.

This post has been edited by Keratos: Dec 2 2022, 01:03

I search
C100 female:"big breasts$"
Found about 359 results.

then
C100 female:"big breasts$" -language:translated$
Found about 359 results.

The translated ones are all removed but why the results number is the same?

I search
C100 female:"big breasts$"
Found about 359 results.

then
C100 female:"big breasts$" -language:translated$
Found about 359 results.

The translated ones are all removed but why the results number is the same?

https://forums.e-hentai.org/index.php?showtopic=262235

favnote searches in Favorites do not seem to support "_" characters. If my favnote is purple_hair and I type favnote:purple_hair or favnote:"purple_hair", it doesn't seem to find anything.

Is that expected behavior, or is it something that can be fixed/has a workaround?

favnote searches in Favorites do not seem to support "_" characters. If my favnote is purple_hair and I type favnote:purple_hair or favnote:"purple_hair", it doesn't seem to find anything.

Is that expected behavior, or is it something that can be fixed/has a workaround?

That's basically the same issue we had with some usernames, and it should basically have the same fix. I'll look into it.

Exclusions aren't accounted for if the result is an estimate (i.e. it says "about").

It doesn't always say "about".

uploader:Neko500
Found 590 results.

uploader:Neko500 -o:scanmark
Found 590 results.

But it removed the 20 with both.

It doesn't always say "about".

Hm, right. It should be forcing an "about", but search counts when using exclusions are approximate unless it's all on one page.

I'm not an expert, just a casual user, but doesn't Paheal use a similar tagging system? When it concerns search queries and results the user-facing systems of the two sites are strikingly similar, yet their backend solution seems to scale a lot better to millions of results and can still give exact counts.

Paheal shows more results per page, has more tags in their lists, more results, numbered paged results, exact result counts even for results for search inclusions AND exclusions. How are they able to do that?

PS: Sorry if this question has been asked already, but I tried searching and couldn't find any mentions of it.

This post has been edited by Ofunniku: Dec 4 2022, 23:10

I'm not an expert, just a casual user, but doesn't Paheal use a similar tagging system? When it concerns search queries and results the user-facing systems of the two sites are strikingly similar, yet their backend solution seems to scale a lot better to millions of results and can still give exact counts.

As has been pointed out repeatedly, the big difference between boorus and EH is that boorus do not have to deal with hybrid title/tag searches, only tags alone. Which is comparatively much easier to handle. As has also been pointed out repeatedly, while Gelbooru provides pagination for the full range, you cannot actually navigate more than 20000 results (that is images, not pages) deep into navigation regardless of whether you are searching or not, at least not without a paid account.

Incidentally, Paheal seems to cut you off at page 500, so basically the same as Gelbooru.

Would it be possible to support gid seek?
I know it can be done easily by custom scripts, but it might be helpful if it's official.

Would it be possible to support gid seek?
I know it can be done easily by custom scripts, but it might be helpful if it's official.

Uh, you mean like this?

GID Searching

You can now use the gid: search qualifier to search (publicly visible) galleries by Gallery ID. If you search a GID that has been replaced, it will list the current gallery instead.

Inclusion gid: terms cannot be combined with keyword searches or used in watch mode. This does not apply to exclusion terms. If used for exclusion, it will not exclude any galleries that replaced the provided GID.

You can specify multiple gid: terms in the same query for an implicit OR search.

This search mode will show both normal and expunged galleries. Default tag, language and uploader filters are automatically disabled for these searches.

Uh, you mean like this?

Not this, just replacing the gid in next/prev with a custom one.

Not finding the exact gallery, but searching from a specific gid.

This post has been edited by aklfhl: Dec 5 2022, 17:10

Not this, just replacing the gid in next/prev with a custom one.

Not finding the exact gallery, but searching from a specific gid.

Not sure why you would even need some UI to do that since you can easily just change the number in the URL.

Not sure why you would even need some UI to do that since you can easily just change the number in the URL.

Yes, but shouldn't manually modifying the URL be avoided?
I mean I don't really need this, as I said, it could be done easily with custom scripts.
Just think it might be helpful for some users.

Since we already have the jump/seek buttons and textbox, the only thing we need to do is parse inputs that don't contain d/w/m/y as gids and pass them to next/prev.

Nice, thank you!
BTW, I just noticed it will still return the next page instead of the current page if the jump time is out of bounds, is this intended?
Oh nvm I guess the server doesn't know "the current page" if it's not the front page, and returning the next page is better than returning the front page.

This post has been edited by aklfhl: Dec 5 2022, 20:32

Since we already have the jump/seek buttons and textbox, the only thing we need to do is parse inputs that don't contain d/w/m/y as gids and pass them to next/prev.

I mean, it doesn't even need any backend code, it's just three lines of javascript. Not sure how useful it'll be, but sure, why not.

Incidentally, Paheal seems to cut you off at page 500, so basically the same as Gelbooru.

Idk what you mean, I just did a search and got over 5000 pages for a big tag. I think whatever you tested it with just has about 500 pages of results.

Idk what you mean, I just did a search and got over 5000 pages for a big tag. I think whatever you tested it with just has about 500 pages of results.

I wasn't searching for anything, but I get the 500-page cutoff both with a blank "search" and with a popular tag. Could be an account requirement thing, and not that it really matters, but if you click the "Last" link at the bottom, does it take you anywhere past page 500? Because, if you cut off the plebs and only let privileged accounts do it, then yeah, it's obviously more feasible to support it.

[rule34.paheal.net] https://rule34.paheal.net/post/list/naruto/501

Error
Only 500 pages of results are searchable - if you want to find older results, use more specific search terms

Got it, thanks.

New update:

A new result range indicator + range jump mechanism has been added. The range indicator will let you see roughly where you are in a search result and how much of it is found on the current page, while the range jump mechanism will let you jump an approximate number of percent into a search result. Range jumping is done by clicking on the range indicator bar.

This mechanism is almost, but not quite, entirely unlike pages. While it has a fleeting similarity, don't expect it to behave exactly like them.

Most importantly, the range indicator uses various internal statistics to work with basically zero overhead; it does not actually generate pagination for the full search result. This means you should for example not expect the displayed number of pips for each page (or pages per pip for large results) to be fully consistent across the entire range. While it does to a large degree correct for variations in usage over time, there will still be unpredictable natural variations (clusters and gaps) in the distribution of results. This especially applies to comment searches, which cannot make use of any precomputed statistics.

The range indicator is only available for normal searches; that is, not for favorites, watched tags, or in gid/file searches. Favorites will be revisited at a later date, as part of a larger rework of the favorite system.

Other Changes:

- Added the Jump postfix "g" for GID jumps. Using this with any GID (Gallery ID) will jump to the position in the search result with this gallery as the first (or last) result on the page. (If the gallery does not exist in the search result, it will still work, the gallery just won't be there.)

- Added a new setting to disable the new range indicator to the settings.

- Corrected a rare edge case where the search UI would act as if a search had no more results even if it did.