[X] My Assistant

Report a search engine bug:
keywords contains both English and Japanese won't work correctly.
The old search has a option to search title only to avoid this issue, now it's gone.
There is an example keywords "JK退魔部", retuen nothing now.

Should be fixed now; the problem was it attempted to parse it as a tag, but found it to be too short. It should now run those kinds of terms as title-only.

You mean just the total sum of favorites across all categories? It's trivial to calculate, so I might add a readout for it when I get around to doing a planned overhaul on the favorite system. Eventually.
No.
Probably not. I'll look into the possibility of adding some sort of positional hint, but anything exact would almost certainly be really wonky and unreliable. (It always was fairly misleading, at least with filtering enabled.)

Yes, just the total sum would be nice

results count while searching inside favorites -> hmm, very sad

some sort of position while navigating -> even if position isn't exact, it would be great to know where we are inside the search, like 10%, 15% or 95%, it doesn't need to be exact.




Another question, currently you are using background scripts|routines to get the "Found about XX,XXX results." ?
You run a select count(*) query, store that query inside an index and then print it on the search page for that tag?
This is the reason why we currently don't have the count while doing a search by multiple tags?

Another question, currently you are using background scripts|routines to get the "Found about XX,XXX results." ?
You run a select count(*) query, store that query inside an index and then print it on the search page for that tag?
This is the reason why we currently don't have the count while doing a search by multiple tags?

It's derived from various sources of information that are either pre-computed or can be cheaply derived from the index dynamically. For example, it knows how many galleries is tagged with each tag, and how many uploads each uploader has, so if you just search for a tag or an uploader, it will show this count.

But there are limits to how far you can stretch this information with any reasonable degree of accuracy. For example, it doesn't know the degree any two (or more) tags overlap, so even if it knows there are 17381 hits for tag1 and 32814 hits for tag2, all it knows for sure is that there are less than 17381 hits for tag1 + tag2 together, and there could even be zero if there is no overlap. And even if an uploader has a lot of uploads, and a tag has a lot of hits, if said uploader has no interest in said tag, there can still be zero hits of uploader + tag.

Right now it's pretty conservative in what situations it provides an estimate, but this is something I plan to do a bit more work on, since there are complex cases where it should be able to manage a fairly good guess.

Probably not. I'll look into the possibility of adding some sort of positional hint, but anything exact would almost certainly be really wonky and unreliable. (It always was fairly misleading, at least with filtering enabled.)

I think even just a vague idea like roughly 50% through even if it's actually like 48.6% through is more than enough.

I'd still take just a % through the total history of the site. I get it wouldn't work well for stuff like searching something like Genshin parody since it came out only recently, but knowing the last results show up at like 20% through the site's history gives some placement perspective.

This post has been edited by blastech: Nov 7 2022, 20:20

I'm getting a couple odd behaviors / possible bugs. I was hoping Tenboro could have a look.

1) Often times when I input a search, like simply "futanari" into the search box, the first page of results looks like this [i.imgur.com] https://i.imgur.com/sCJJ92B.jpeg , and I have to click Next to go to the actual first page of results. This doesn't strike me as intended, is it?

2) Searching for certain tags or partial strings with no category selected, it returns zero results. Normally, no categories selected would default to matching all categories, but it's not doing that. Like, going on the front page, typing "hayate" (expecting to find Hayate no Gokotu results), hitting run, you get zero results. Same if you input parody:"hayate no gotoku$". But like we saw above, inputting "futanari" and no category selected does return results.

Never mind, it seems these behaviors only show up when the compactsearch userscript is enabled.

This post has been edited by Zinbieel: Nov 7 2022, 20:33

The new jump/seek tool is a great help, but pages had a second role - an understanding of where you were in a search. Page 50 is 3 pages after page 47, 6 pages before page 56, page 2 is 1,954 pages ahead of page 1,955, etc. When your database has something like 200,000 pages, THAT'S REALLY HANDY.

The large jumps problem was solved with the Seek tool, but the orienteering problem, so to speak, has yet to be answered.

I think having important dates on the page shown obviously, though definitely a patch over the lack of real pagination, could work. Maybe have them under the navigation buttons - the oldest date on the page under Prev, the newest date on the page under Next, the oldest and latest results under the last and first buttons, and the last jump point under the Jump button. You'd only need to provide 5 dates for this system to work, you wouldn't have to update all the pages if a new result is included, and it would give at least a basic sense of location.

There's also the 'Scrobbler' implemented a while ago - a bar that shows your progress through the results. Simply implementing that with some additional server-side supports - say, having it be between the first and last GIDs of the search rather than the first and last GIDs on the site - would create another useful orienteering tool, showing your progress through the search the way pagination does. Combining the seek tool with the Scrobbler has been powerful in my experience, so having a better-supported version would almost eliminate the need for page numbers.

I'd still take just a % through the total history of the site. I get it wouldn't work well for stuff like searching something like Genshin parody since it came out only recently, but knowing the last results show up at like 20% through the site's history gives some placement perspective.

There's also the 'Scrobbler' implemented a while ago - a bar that shows your progress through the results. Simply implementing that with some additional server-side supports - say, having it be between the first and last GIDs of the search rather than the first and last GIDs on the site - would create another useful orienteering tool, showing your progress through the search the way pagination does. Combining the seek tool with the Scrobbler has been powerful in my experience, so having a better-supported version would almost eliminate the need for page numbers.

I have been thinking about displaying some sort of "progress bar" like that script you mention; the search engine already knows the GID ranges for tags, titles and uploader, so it could probably already estimate the rough position you're at in the full result set with reasonable accuracy - far better than a userscript could at any rate. So if it estimates that the current page starts ~17% and ends ~21% into the full result, it could show something like

|--------==--------------------------------------|

except with CSS rather than ASCII art. Though I don't really have a clear idea of exactly how/where the readout would be to avoid it seeming cluttered.

Though I want to take another look at the indexing to see if I can store a per-tag histogram without adding any notable overhead, as well as get the gallery timestamps fixed, and I need to fully deploy the update before I can do that, so it won't be right away.

I don't understand programming at all but the first thing that comes to my monkey brain would be a system that counts how many times you have clicked "next".
"You have pressed next X times on this tab"

I have been thinking about displaying some sort of "progress bar" like that script you mention; the search engine already knows the GID ranges for tags, titles and uploader, so it could probably already estimate the rough position you're at in the full result set with reasonable accuracy - far better than a userscript could at any rate. So if it estimates that the current page starts ~17% and ends ~21% into the full result, it could show something like

|--------==--------------------------------------|

I gotta say, if you made it like a tiny little race car or something I'd be clicking Next/Prev just to see it move.

@Tenboro Is it possible to keep pagination just for favorites?

This is just convoluted pagination turned 90 degrees on its side and dressed up. Please Just implement something to actually browse the pages instead of having to guess what date the smut your browsing is uploaded. My favorite new sad panda feature is clicking back to 2020 trying to get 20 pages away from page 1 of the search, and only getting 2.

This post has been edited by sithlordgore: Nov 8 2022, 01:23

I have been thinking about displaying some sort of "progress bar" like that script you mention; the search engine already knows the GID ranges for tags, titles and uploader, so it could probably already estimate the rough position you're at in the full result set with reasonable accuracy - far better than a userscript could at any rate. So if it estimates that the current page starts ~17% and ends ~21% into the full result, it could show something like

|--------==--------------------------------------|

except with CSS rather than ASCII art. Though I don't really have a clear idea of exactly how/where the readout would be to avoid it seeming cluttered.

That would be very helpful. Segment the bar by fixed values that may or may not correlate to pages or just be 5% each and allow them to be clickable - that would be a good replacement to the page selector.

Some observations over the last few days after using the site without pagination / mostly thinking out loud:

- The yearning for pagination is the strongest when I am searching a single artist tag (or really anything that results in reasonably small result number, probably ~300 or ~6 "pages" since I have it set to display 50 per page).
-- In such small number of results, the GID-range scrobbler (the one I made) does not help a lot.
-- A simple "You have pressed next X times" tracker would actually suffice/help greatly in this case.
-- I imagine Tenboro's progress bar idea will help a lot in this case too.
-- This also kinda makes me question my own assumption(s) on how the current search engine works: how expensive is it to search for a tag that spans over e.g. 2M gid to show 50 results in a page?
--- If it's cheap, could pagination perhaps be shown conditionally when the result count is under say, 10 pages?

- Conversely, when the result count is large or when searching with somewhat generic tag filters, I don't miss the pagination. I either just hit next or use date-based search. The GID-range scrobbler is kinda handy in this case.

- The GID-range scrobbler (that I wrote) the other day has several large problems
-- Spanning over ~2.4M gid on 800 pixels, each pixel represents about 3000 GID. When each page can only display max 100 results, it becomes almost meaningless (and this will only get worse as more galleries are uploaded).
-- Assuming that isn't a problem (e.g. because the set filter results in a smaller total), the information shown is also not particularly accurate (and thus impacts the usefulness) since the "density" over GID is dynamic; there could be a lot of results in a given gid range and then very little or nothing in another: how to tell if there are still a lot/a few results left? I'm hopeful to hear that there's a better way to do this on the server side.

- This sounds so silly but I also kinda miss the smaller numbers the old pagination had (for whatever reason 13 pages, 216 pages, or 1210 pages are easier to understand than e.g. 817 results, 10744 results, or 60512 results (though maybe I just need to get used to it))

This post has been edited by FabulousCupcake: Nov 8 2022, 01:26

Every other website in the world can handle proper pagination, but this one can't? How spaghetti is the code here? Almost no user has any idea when something was uploaded, or has any sort of mental index of the date they're looking for, so I have no idea why that was used as the 'solution' to being the one website in existence that can't do page numbers. When I'm going through a tag the most important information to me is 1) How many result there are (this is still present) and 2) How deep I am in the results (this is missing) which is incredibly important for navigation (How many pages have I gone through? Am I close to the end? Have I seen this page before? Did I miss what I'm looking for?) Without page numbers we lose every single bit of all of that context, which makes browsing a miserable experience.

I am never thinking, instead of any of that, "Well these are the results posted between August 2007 and December 2012 so I know my doujin should be on the third click of the next button!" because I have no clue when it was uploaded, and have no reasonable way of learning it (you certainly cannot rely on when it was released by the author to find it here) despite this being the mindset the new search engine is based on. People just do not think like that naturally, and the information is too obscure and unobtainable to be reasonably expected to adapt your thought process to it. Instead we are reduced to dumbly clicking on a next button with no idea how many times more we have to click it, no idea where we are in the results, and soon forgetting how many times we already have done so, if we want to navigate this site, and despite any update to how tags are handled, can be searched or how fast searching is (the 'good' changes,) they are massively overwhelmed by the sheer inconvenience of it.

This thread is long enough that I'm sure all of this has been brought up before, word by word, but by god does it damage my user experience enough that I had to say something at least, even if, for whatever reason, this apparently can't be repaired.

I also think a small text that says "you have pressed "Next" X time in your current tab" and "you have clicked "Prev" X time in your current tab" would be a great workaround for your problem and would please most people.
The biggest issue for me is not knowing how many pages i am on because i multi-tab when searching the new uploads.
With the old system i could get to 30+ pages of uploads of various parodies or original, western or not.

This update completely ruined the browsing... literally no way to jump to a page. Like... there's THOUSANDS of pages worth of material, and now the ONLY two options we have are "previous/next" and "first/last".

Literally no one who uses the site wants this change. It's garbage and makes browsing the site a nightmare now. I've never once felt the need to post in a forum here because I've felt like, ever since I discovered this site, that this was, like... the BEST hentai site out there. But this is almost as much as a downgrade to the website as Season 8 was to GoT. Smdh. (IMG:[invalid] style_emoticons/default/cry.gif)

Every other website in the world can handle proper pagination, but this one can't?

They can't, they just pretend they can, and hope their users never notice. Or they're too small, with too little data and they actually can.

For example, google, the largest website cannot handle it
Sorry, Google does not serve more than 1000 results for any query. (You asked for results starting from 200000.)

Guess you only ever get to see the latest 1000 galleries with this approach, but you wont be upset with that would you?

This post has been edited by Cipher-kun: Nov 8 2022, 05:47

can we have the option to switch back to page navigation please...?

You can provide page numbers for a small cost that works in most scenarios. The naive approach is to check if result size is below an acceptable limit and revert to a full search in those cases, but there is also another more resilient alternative.

1. When a search is first performed, search ahead by maybe 20 pages (for example's sake) to try and find the max page. For big queries this will not be exhaustive, but its okay, being able to take 20-page steps is still valuable. Now store the id of the first result (most recent upload), the last result, the result count, and the current result index in the address bar as metadata. Provide page numbers from 1 up to 20, depending on result count.

2. When a search is done with this metadata available, i.e. a page refresh or a navigation within the query, update the metadata. First you may optionally check for additions to the query by searching backwards up to a limit from the first id to find the new first id, and update the metadata. Secondly, either it's a page navigation, in which case it's trivial to update the metadata, or if it's another form of navigation (like jump to last result) then search both forwards and backwards to a limit. If the old first or last id is found, then the metadata can be calculated, otherwise it fails.

In any case of failure it's an option to use heuristics and accept inaccuracies, or to just revert to basic navigation without pages. Another caveat is that this will always provide inaccurate page data if uploads are removed while navigating a query. Also jumping to an arbitrary page will naturally not work. It's really just a way to provide a rough page count, page cursor, and navigation within the closest pages.

This post has been edited by emilemil1: Nov 8 2022, 06:23

I have like a hundred pages of favorites and now I need to click 'previous' button repeatedly for no goddamn reason.

To people who treat favorite button like a like button, it is your own fault. Thank for being my laughing stock

I literally don't know why this was even implemented.

IQ level of your users