[X] My Assistant

Is there a chance this gets fixed anytime soon?
I'm currently massively editing my favorite notes, so I could probably use "-" over "_" from now on.
It would still be a significant bother to edit "_" to "-" on all my past favorite notes, so I'd rather not do it if this is planned to get fixed soon.

I expect it will get fixed for the next update.

Considering the answer, I assume this feature will not be released anytime soon (like in the next year), if ever at all. Is that correct?

That's generally the case for things that go on the "maybe list", yeah.

(IMG:[invalid] style_emoticons/default/biggrin.gif) updated very nice

I love the new little "page indicator" nubs!

i saw that too and i was wondering what the hell dude why is it just the dumb circles and not numbers i want numbers back thats way easier and its still on the page for the doujins so why is it only there and not on the main site where we browse for everything? Though its still a step up to the crappy update that made me not use the site for a while i just want to see numbers again and the circles dont help my autism.

This post has been edited by billyhatcher643: Dec 16 2022, 08:40

i saw that too and i was wondering what the hell dude why is it just the dumb circles and not numbers i want numbers back thats way easier and its still on the page for the doujins so why is it only there and not on the main site where we browse for everything? Though its still a step up to the crappy update that made me not use the site for a while i just want to see numbers again and the circles dont help my autism.

Wdym "on the page for the doujins"?
The pagenumber addressing system is gone, forever.
And it's explained why dozens of times in the thread - unless you can't read.

I was going to ask for page selector but judging by the replies it seems to have been removed for good.
This site used to be so good man. See ya fellas around hope you enjoy Christmas.

This site used to be so good man.

The good old days are overrated.

New update:

***

The search engine will now attempt to give a ballpark estimate for result counts in all standard searches except for searches with inclusive comment terms. The estimate is based on internal stats, index sampling, and a history of the span of results found on each page.

The new estimator is primarily used for complex queries where all terms have many hits, where it would previously only say "many". It is also used whenever a page range filter is set, and for index searches when several categories are unselected.

For any query that has not been searched recently, the initial estimate will usually be a vague and conservative lower bound (like "thousands" or "10,000+"). A more precise estimate may be provided when enough samples have been collected.

It generally prefers to under-estimate rather than over-estimate the count. As such, it should generally be interpreted as "probably more than".

The accuracy for the estimate depends on the accuracy of the range map used by the range indicator, and the same caveats apply. Complex searches with non-dependent terms will generally be less accurate.

Note the estimate can fluctuate a bit as you go between pages. This is expected.

Other Changes:

- Fixed some issues with underscores in favorite searches. Similar to username searches, spaces and underscores should now be equivalent for all favorite search usage.

- You can now use favnote:* or -favnote:* to filter favorites with any favorite note.

- Several caching issues were found with the setting to exclude namespaces by default when searching. A fix would be complicated and essentially make searches uncacheable for everyone using it, and since it's only used by a small fraction of a percent of visitors and a lot of people seem to be confused about what it does, this setting has been disabled for now. It will likely be reintroduced in a slightly different form in the future.

- Some fully updated but less than bleeding edge browsers were having issues with the javascript generated by the javascript optimizer we now use. This optimization now targets an older level of compatibility, which should fix this issue.

***

Let me know if you encounter any search queries where the settled estimate is *vastly* inaccurate - that is, off by more than 50% or so.

--

Edit: Corrected an issue where the count cache didn't distinguish between expunged and non-expunged for non-indexed searches, added an improvement to how the index is sampled to improve accuracy when unselecting categories or using pagerange / torrent / rating filters, and fixed an issue where result counts could be massively overestimated when using uploader searching.

First surprised with the UI change but after reading the reasoning I totally understand and agree. I didn’t know that page indexing costed a lot of processing. I find it a well considered good solution.

People who complain about it have yet to experience how it feels to get incomplete results out of search engines. Or they didn’t know the reasoning behind it like processing-wise.

Im not technical so I don’t know if it works if I were to write a script that indexes search result on the client side (so the script runs&processes or keeps track on the client device). Idk if that solves the problem. Once again I’m sorry if I sound unintelligent, Im not so good with technical stuff. But just idea for some people who are persistent with page UI.

I like the dots design I could also just adjust the url to find certain ranges. Saw an image how the filter is applied with highlighted dots and greyed out dots. It gives a good overview on how much is filtered out which I find useful.

This post has been edited by oodraloob: Dec 20 2022, 23:54

I was going to ask for page selector but judging by the replies it seems to have been removed for good.
This site used to be so good man. See ya fellas around hope you enjoy Christmas.

There's still no better site than here lolz

As far as I can tell, "OR" searches do not seem to support favnotes

~favnote:spy ~favnote:"undercover_agent" seems to return favorites notes that have BOTH spy and undercover_agent
~kunoichi ~favnote:spy seems to return galleries that have BOTH the kunoichi tag and the spy favorite note

Not sure if this is expected (as favnotes might not be able to work the same as regular tags) or an actual issue

I believe the OR operator implies tag: if no namespace is specified and it matches a tag, and if it doesn't match a tag, it just ignores ~ and counts it as an AND term. I assume if you put it before favnote, it just gets ignored as favnotes aren't tags

So I'm here for the first time in a while and how do I search for galleries by name? Or is that gone now?

title:"your terms here"
https://ehwiki.org/wiki/Gallery_Searching

So I'm here for the first time in a while and how do I search for galleries by name? Or is that gone now?

It will search name+tag by default.

I believe the OR operator implies tag: if no namespace is specified and it matches a tag, and if it doesn't match a tag, it just ignores ~ and counts it as an AND term. I assume if you put it before favnote, it just gets ignored as favnotes aren't tags

I thought they could be used for title too, that's a shame.

As far as I can tell, "OR" searches do not seem to support favnotes

I thought they could be used for title too, that's a shame.

It explicitly says in the update notes that the OR operator is only supported for tags. There are no plans to support it for anything else.

The main reason being that while OR searches for some other qualifiers is technically possible, because of how things work internally, searching for ~favnote:note1 ~favnote:note2 ~tag:tag1 ~tag:tag2 would need to be searched as (favnote:note1 OR favnote:note2) AND (tag:tag1 OR tag:tag2) which is more confusing than anything.

Not sure if worth reporting but found a case where result estimation is super off (should be ~200 but says ~2200). The gif prob explains it better:

(IMG:[files.catbox.moe] https://files.catbox.moe/b5jsfp.gif)

With the filters disabled it does show 2000+ results (mostly the non-english results which I have excluded), but it feels like the text should have said "Your custom filters removed ~1900 galleries from this page"?

This post has been edited by Shank: Dec 22 2022, 18:54

Not sure if worth reporting but found a case where result estimation is super off (should be ~200 but says ~2200). The gif prob explains it better:

With the filters disabled it does show 2000+ results (mostly the non-english results which I have excluded), but it feels like the text should have said "Your custom filters removed ~1900 galleries from this page"?

Hmm. Yeah, you did find a bug, not in the counting logic, but in the "are there more pages" logic. For indexed searches there are several levels of result buffers - four to be precise - and it was only checking three of them. So if every buffer except for the fourth one happened to be completely empty when it had enough results for a page (very unlikely) it would just welp out thinking there were no more pages.

This should be fixed now, but let me see if you still see this. Thanks for the report.

- Some fully updated but less than bleeding edge browsers were having issues with the javascript generated by the javascript optimizer we now use. This optimization now targets an older level of compatibility, which should fix this issue.

Is that Firefox ESR edition?

Is that Firefox ESR edition?

The current ESR is new enough that it shouldn't have been an issue. The previous ESR would have been too old, and some Firefox derivatives (Waterfox, PaleMoon, possibly others) are also based on an older version of Firefox that does not support the operator in question.