[X] My Assistant

All information of deleted galleries disappeared from favorites, this change is horrible, is it copyright factor? Please stop this update, it's a disaster. (IMG:[invalid] style_emoticons/default/mad.gif)

All information of deleted galleries disappeared from favorites, this change is horrible, is it copyright factor? Please stop this update, it's a disaster. (IMG:[invalid] style_emoticons/default/mad.gif)

Honestly shocking how these changes made it through any kind of scrutiny. Like I understand that when you are deep in the tank it's easy to overlook common end user experiences but if you showed the new UI to any casual user you should have gotten noticeable pushback about the navigation changes.

I noticed that removed galleries are no longer showing up in favorites. I had a lot of galleries that were removed due to copyright but at least I could search them by tags and find them by name somewhere else. Now they are gone (IMG:[invalid] style_emoticons/default/sad.gif)

All information of deleted galleries disappeared from favorites, this change is horrible, is it copyright factor? Please stop this update, it's a disaster.

The removal of pagination is an issue for me too

I don't know how many pages i have inside of favourites and i don't understand why you removed pagination there, what kind of performance issue can be there?

I don't know how many galleries i have for a given search, yes i have an approx number, like 5000 so if i do the math 5000/25 = 200 pages, can't you calculate that with JS if your problem is performance? Indicating the number of pages and the position of current GID inside the search would help a lot, don't know tho what is doable with JS and what need to be done server side, but some indication of total of current position/pages is needed


As a programmer i understand that GID may sound as a reasonable upgrade, since as you say, now each "page" will be fixed as now you have the GID inside the url, but as a user, i need pagination
I need to know where i am in the current search, if i have 5000 results, i need to exactly know if i'm half the way or i'm at the end, you need to think about "something" that will replace the pagination, some sort of indicator that tells users where they are

"first prev next last" makes the user experience painful

Like 3x performance sure, sounds cool. More than 3x as useless navigation though?

I had bookmarks for various search results so I could methodically go through the galleries - how do you do that in the new system?

There's no way to determine a relative position in the results based on the url. GID is arbitrary given individualized filters within the results.

Is the intended design to just click 1100 times to find the page I was on before?
Engineer a vibe so every time I click Next it buzzes me and don't need to find the gallery I want?

honestly dogshit usability, please reconsider.

First time posting in this forum.

Please, bring back the page numbers and page selector. I use the thumbnails list and they only show 25 galleries.

I look at "female:futanari$" on search bar and, at the moment, there is more than 66,700 results. I use the thumbnail list and it only shows 25 on page, so do I look like I'm gonna keep clicking "next" to reach the 37,000 th thumb or the 56 th "page"? Hell no! I won't use the minimal list and keep hovering my mouse to see the thumbs, one of my hands is busy and the other one is using the arrow down key to scroll.

Do I look like I can remember every tag to write on search bar? Even if I could, there's some galleries people don't tag well. I won't spend hours on EH wiki, just to find the tag I was looking for!

Also bring back the option to include expunged gallery on general list, not to separate them! This is ridiculous!

This is also my first time ever posting on a forum.

The truth is a huge majority hates and is inconvenienced but this navigation change, no matter what arguments are made to reason with it. I cannot adapt to this because it it completely hinders me from navigating comfortably.

So, does it even makes sense in making it easier for the servers if i have to click "next page" 100 times to do what before i only need to click once?

In that case, it would be best if someone can update the wiki with GIDs corresponding to particular years and months. Or suggest an increment in GID that would correspond to "next 50 pages" (doesn't work with tag filtering though).

How about some manner of approximation using GID?

Bring back page selector. Someone decided to sabotage this site or what?
This change is beyond horrible. Please reconsider.

I don't care much how a collection of galleries is handled in the backend, but I do care very much about the ability to jump forward x amount of galleries. So remove pages if that gives you performance improvements, but for the love of god, please give us a 'Next (x times)' button.

I absolutely agree. Even with it's flaws, I believe the previous system was more user-friendly and easier to use than the new one.

Off hand seems like reversing how pages worked would have fixed the issues, and given improved performance. Make the oldest stuff page one and going forward add pages. This would make the results the same so the site would need only a single index for everything. With the newest pages being the new stuff being the highest number.

This post has been edited by whatever17: Nov 3 2022, 00:49

Please bring back the page numbering. It is impossible to use the site without it

So obviously there's a lot of stuff, but one error/issue I have is the check boxes for "search low-power tags" and "search expunged galleries". Before, I was able to check both of those boxes and I'd see those IN ADDITION to normal searches, so if a gallery was expunged I could see it with non-expunged galleries, and if a tag was low power due to whatever reason (like maybe only one page of pregnant or something) then I'd be able to check both boxes and see most of what I wanted.

Now though, those options EXCLUDE anything that isn't that option, so now if I wanted to see any recent galleries that was expunged as well as non-expunged uploads, I'd have to purposely search that tag normally, then re-search it with the option selected.

Please bring back the page selector

This update will be deployed in stages. If you still see the old search navigation with the page selector instead of the First/Prev/Next/Last links, you are still using the old version of the site. The update is expected to be fully deployed either today or tomorrow, unless any major issues are discovered.

--

This update is a complete rewrite of the gallery search engine, meaning that the usage and behavior of searches has changed in a number of more or less significant ways.

The most significant and visible fundamental change is that the internal segmenting of search results is now done by gallery ID (GID) ranges rather than "pages". While this means jumping to an arbitrary "page" in the result is no longer supported, this is arguably an improvement since you can now jump to an arbitrary GID instead. This also means each page of results will be fixed on the same set of galleries even if it is refreshed after new galleries are added. The page navigation has been reworked to reflect this.

This also fundamentally fixes a long-standing issue where going backwards in the results via the page navigation (as opposed to the browser back button) would often include results from the following page if you were using any form of filtering.

Overall, these changes allow for massive performance improvements (three orders of magnitude in some common cases) as well as significant new functionality (keep reading), and there are no longer any limits to how large a search result can be. Search terms that were previously capped to 100,000 results (like say "big breasts" which is tagged on 350K+ galleries) can now be browsed in their entirety.
OR Tag Searching

OR searching is now supported for tags. (Probably the most requested feature of all time.)

To use OR tag searching, prefix the keyword with ~

Example: ~yuri ~"females only" ~f:sole_female$

Specifically, if you have at least two keywords with the OR operator, the search will return all galleries that contain at least one of the tags in question. Using the OR operator will imply the tag: qualifier. If you use it with any other qualifier that isn't a tag namespace, the OR operator is ignored and the keyword will run as a standard AND search.

Using OR searching will "consume" one of the allowed inclusion search terms. If you only specify one OR term, it will be treated as an AND tag-only term. There are no specific limits to how many OR terms you can specify, though it will still be practically limited by the search string length cap. It will additionally bail if the overall OR search is matching more than 1000 tags internally, so consider using exact tags to allow for more terms.

Wildcards cannot be used for OR terms.
Exclude-Only Searching

You can now do exclude-only searches. (Probably the other most requested feature of all time.)

Example: -yaoi -m:footjob -"glory hole" -sole_male$ -title:"novel ai" -comment:pixiv -uploader:BigDickDave69

You can use up to 10 comment+favnote exclusion terms and 10 tag (or hybrid tag+name) exclusion terms in a search.

The gid, uploader, uploaduid and title qualifiers are not specifically limited for exclusions, though they will still be practically limited by the search string length cap.
Tag Watching

The time cutoff for the tag watching page has been significantly increased:

- For non-donators, the cutoff was increased from one week to at least one month. The exact cutoff depends on internal segmenting, the rate new galleries are added, and the total index count for your watched tags. It will generally be somewhere between one and six months.

- For donators (gold star+), there are no longer any cutoffs. In other words, you can browse and search watched tags back to the launch of the site if you want. Note however that searching for terms that have few matches in your watched tags may produce fewer than expected results per page.
UI => Search Syntax Changes

The "Search Gallery Name", "Search Gallery Tags" and "Search Gallery Description" checkboxes as well as the corresponding search checkboxes on the Favorite page have all been removed; this functionality is now part of the search syntax instead.

By default, each search term will be interpreted as a hybrid tag+title search, and will match the gallery name (both english/romaji and japanese) as well as the gallery tags.

To only match gallery names, prefix the term with the title: qualifier
* Example: title:keyword -title:"string of keywords"

To only match gallery tags, prefix the term with a tag namespace, or tag: for all namespaces, or use the exact tag operator $, or use the OR operator ~
* Example: f:"big breasts" tag:group -futanari$ ~twintails

To search uploader gallery comments, prefix the term with the comment: qualifier
* Example: comment:"insightful uploader musings" -comment:"less insightful ones"

Favorite searches only: To search favorite notes, prefix the term with the favnote: qualifier
* Example: favnote:"this is my favorite gallery" -favnote:"on the citadel"

Note that this means combined tag+name+comment/favnote search terms are no longer supported.
Search Parsing Changes

- When doing unquoted searches with unqualified short and/or non-indexable words (a, an, ai, to, the, and, so, on, and so on), as well as some common adjectives (small, big, huge, gigantic), they will now be automatically appended or combined with the following priority:

* If there is a non-qualified search term immediately following the short word, it will be combined with that one.

For example, searching for "a dick in a box" without quotes will be searched as "a dick" "in a box". Everyone's new favorite "ai generated" without quotes will be searched as if it had quotes.

* If there is a non-qualified search term immediately preceding the short word, it will be combined with that one.

For example, searching for "novel ai" without quotes will be searched as if it had quotes.

* If there are only short words, they will be combined into one quoted word if there is more than one.

For example, searching for "ex on the ox" without quotes will be searched as if it had quotes.

* If there is just one short word, or the short words are between qualified search terms, it will be searched as an exact tag. A warning is printed in this case.

For example, searching for "9s artist:a 2b" without quotes will be searched as "tag:9s$" "artist:a$" "tag:2b$"

To combine short words with a different priority, use quotes or underscores. ("word1 word2 word3" and word1_word2_word3 are equivalent.)

Note that there is a single two-character word "3d" that was specifically whitelisted for title searches, but it is not an indexable word for comment searches so it cannot be used for that.

- Support for single-character wildcarding was dropped, and the * wildcard can now only be used at the end of keywords. Title, comment and favnote searches are implicitly wildcarded for indexing reasons, so adding a wildcard will only affect tag searching.
Search Term Limits

Exclusions and inclusions now have separate limits. A query can have up to 5 name+tag inclusion terms, 10 name+tag exclusion terms, and 10 comment+favnote inclusion+exclusion terms.

For both inclusions and exclusions, uploader:, uploadid: and gid: terms aren't specifically limited, but would still be limited by the max length of the search string (200 chars).

For exclusions, title: terms are also not limited.
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.
Result Counting

For performance reasons, the search engine will no longer count the exact number of results in large result sets; instead result counts will usually be approximated based on various metrics. It will say "about" if the count is an estimate.

For complex multi-term searches with large result sets, it may not have enough information to give a reasonable estimate. In these cases, rather than showing a potentially wildly inaccurate one, it will just show "many". This only affects the count readout, navigation for these search results works the same as for smaller ones.

Smaller result sets (i.e. those that fit on one page) should return the exact count in all cases. Filtered galleries are included in this count, to match the behavior for estimates.

The page range filter, exclusion search terms and default language/uploader/tag filters will not generally be reflected in approximate result count estimates.

If you use the category, rating or torrent filters, it will use precomputed adjustment factors to correct the estimate. For some searches this estimate may be fairly inaccurate, say if you search for terms that are mostly applicable for specific categories then unselect other categories.

Result counts are not displayed in favorite searches or on the popular page. In the former case, it would only be able to display one for small result sets, and in the latter, it's all one page of results anyway. You can however still see the total for each favorite category.
Tag Search Behavior

- Tag searching now defaults to matching on word boundaries to reduce unwanted matches. In other words, searching for "tag:mana" will still match all tags that have "mana" as one of the words (like "secret of mana" [=> seiken densetsu] or "mana inuyama"), but it does not match "manabe", "manatsu", "manami" and so on. Searching for "tag:mana*" will restore the previous behavior.

- If there are too many tag matches for a term, it will now automatically rerun the term as an exact search instead of erroring out.

- Selecting "Search Low-Power Tags" will now only search low-power tags. This mode will also not do hybrid title/tag searches, so if a term is left unqualified (i.e. "big breasts") it will only search the tag. You can still search titles by using the title: qualifier.

- The "Search Downvoted Tags" option was removed.
Comment Search Behavior

Uploader comments and favorite notes are now searched using the comment: and favnote: qualifiers. favnote: is only available in favorite searches.

The way comments are indexed have been fundamentally changed, and there will be some subtle differences between normal text searches and favorite + exclusion-only text searches, since the former will usually use indexes while the latter do not.

Most notably, some otherwise-searchable common words (like "this" and "with") are not comment-searchable when the index is used but will be searchable when it is not. Also, when the index is used, words starting with these short words will not be matched unless you search for that exactly (like "with" and "withhold").

Furthermore, when the index is used it will only find word matches that start with the string, but when it's not it will also find matches that have the string as part of a word.

The index is only used for normal inclusion comment searches, but even for those it may not be used for some words and searches depending on various internal factors and thresholds, so you should not rely on this behavior.
Other Changes

- Various issues and limitations with favorite searches have been resolved. Searches in favorites should now behave the same as normal searches except for the noted comment/favnote search behavior.

- Exclusion searches for titles, tags (except for exact tags), comments and favnotes will now match any part of a word; i.e. -"laughter" will exclude "slaughter".

- Indexes are now generally updated immediately when the underlying data changes, which should reduce the delay until changes are reflected in searches. (Due to caching, there can still be some delay.)

- Whenever a gallery title has a mixed string of unicode and latin characters without any spaces or other breakable characters, like romaji漢字moreromaji, it would previously only be searchable with terms starting with "rom...", "漢字..." and "字mo..". It is now also searchable for "mor...".

- The "Your default filters removed..." message is now more consistent and specifically counts all galleries filtered by your default uploader, tag and language search filter settings. (When using both filters and exclusions and a gallery would have been removed by both, it is counted as an exclusion.)

- Selecting "Search Expunged Galleries" will now only search expunged galleries in normal searches. (File searches, GID searches and favorite searches will always display both normal and expunged galleries.)

- File searches can no longer be combined with keyword searches or other filters. This search mode will show both normal and expunged galleries. Default tag, language and uploader filters are now automatically disabled for these searches.

- Excessively narrow page range filters (min > 1000, max < 10, min/max > 0.8, min-max < 20) are no longer allowed.

- The max number of results per page is now 100. Paging Enlargement III was removed and will be refunded Soon™.
Known Issues/Quirks/Complaints/Workingasintendedisms

- You may sometimes see galleries appear out-of-order when going from one page to the next - in other words, going by the posted date, you would have expected the gallery to be on another page. This mostly applies to older galleries that predated the latest uploader update. This is because, prior to said update, a gallery could have been assigned a GID long before it was actually posted. This might eventually be addressed after a future redesign of the gallery metadata tables by renumbering galleries that are significantly out of order.

- If you are browsing from the end of a search results (backwards browsing mode) all the way to the start, the "last" page in the result (the one with the oldest results) will have a full page of results and the "first" page in the result (with the most recent ones) will have the remainder. This is working as intended.

- If you go backwards in a search result and get to the "first" page (with the most recent results), the "<< First" link will be lit up to flip back to the first page in forwards browsing mode even if there are no further pages and "< Prev" is disabled. This is working as intended.

- If you search for several AND inclusion tag terms (or hybrid title+tag terms), where every term has many results (~10K+) and some have a lot of results (~100K+), and there is a low degree of overlap between the tags, you may see fewer than expected results per page. You can usually use exact tags to avoid this.

- In general, "results per page" should be considered a target rather than a guarantee. For example, as an internal optimization, if a result page is at least 95% full after a search cycle, it may return with a couple of results "missing" instead of starting another search cycle (which can be expensive). This does not mean it's withholding results from you, you'll find them on the next page.

- "But $tool/$script needs the ability to access arbitrary pages in search results and/or accurate search result counts" is out of scope/wontfix. Update it to use the new gid-based navigation. And no, the old search engine was not "working just fine the way it was", it was failing on an ever-increasing number of searches due to running out of RAM when building results and badly needed a fundamental redesign to cope with the ever-increasing size of the index.
This is likely the most complicated update in the site's history, so there will probably be bugs and other subtle behavioral changes. Please don't hestiate to ask whether something is intentional if it's not noted in these patch notes.

All information of deleted galleries disappeared from favorites, this change is horrible, is it copyright factor? Please stop this update, it's a disaster. mad.gif (IMG:[invalid] style_emoticons/default/cry.gif)

First time posting.
You hav deleted a base feature, please bring back the page selector, the site right now is unmanageable.

honestly i'd prefer dealing with performance issues if it meant having the the page numbers back, this is a downgrade imo. not as bad as sankaku's bs, but i really hate this

So, does it even makes sense in making it easier for the servers if i have to click "next page" 100 times to do what before i only need to click once?

This is exactly the problem with removing page numbers. If I want to search for something that I don't recall the name of but was posted a long time ago, but also not from 2007 or whatever, then there's going to be a lot of clicking involved without page links to click on. Even a simple "halfway new/halfway old" button that drops you in between your current page and either the latest or oldest page would be infinitely better than removing this important function entirely.