[X] My Assistant

Those are not glitches.
You just need to use quotes, otherwise they will be treated as multiple keywords instead of one.

e.g.: "[ひだねだネ。 (波白ひだね)] LAIDばっくBEATS [DL版]"

Sounds weird but okay. Does work.

The max number of results per page is now 100. Paging Enlargement III was removed and will be refunded Soon™

I did not receive a refund (IMG:[invalid] style_emoticons/default/sad.gif)

The max number of results per page is now 100. Paging Enlargement III was removed and will be refunded Soon™

I did not receive a refund (IMG:[invalid] style_emoticons/default/sad.gif)

Soon™ = [www.merriam-webster.com] mañana

But I guess I've procrastinated on that one for long enough. I fixed up the refund script and ran it, so it should be credited now. Along with the old tag flagging perk from ca 2019 which most people probably forgot about by now.

Is there a reason for the search engine throwing a "Some terms use unsupported syntax or are otherwise not valid." error and not giving any results when searches contain a single character keyword (e.g. the "恋" in "(FF40) [おっぱいばいばい (あずきこ)] 恋 (その着せ替え人形は恋をする)")?

I may be misremembering, but I seem to recall the old search system would ignore keywords that were too short, still allowing the search to go through. Possibly also displaying a message saying some keywords were too short and were thus ignored. Would it be possible and/or desirable to do such a thing with the new system?

This post has been edited by Scumbini: Jul 10 2023, 01:38

Is there a reason for the search engine throwing a "Some terms use unsupported syntax or are otherwise not valid." error and not giving any results when searches contain a single character keyword (e.g. the "恋" in "(FF40) [おっぱいばいばい (あずきこ)] 恋 (その着せ替え人形は恋をする)")?

I may be misremembering, but I seem to recall the old search system would ignore keywords that were too short, still allowing the search to go through. Possibly also displaying a message saying some keywords were too short and were thus ignored. Would it be possible and/or desirable to do such a thing with the new system?

The fundamental reason is that short terms aren't necessarily dropped with the new search engine, they can either be combined with other words or parsed as a tag. 恋 doesn't qualify as either, so it's dropped with a generic "I can't do anything with this" error.

And on a tangential note, it can't tell you which terms are dropped anymore because spambots figured out a trick where they could link to a search page with a search term like "artist:visit shittingdicknipples.boobies for more shitting dick nipples!" and then the (old) search engine would helpfully make an empty result page saying that the artist tag "visit shittingdicknipples.boobies for more shitting dick nipples!" is not valid. Which would then be indexed by Google et.al. and show up whenever someone searched for e-hentai shitting dick nipples. Thisiswhywecanthavenicethings™.

(Practically they were using it to advertise VPNs, but that's boring.)

This came up in another thread. There appear to be some restrictions that make some searches return zero results, especially searches containing the term loli and the like. This has assumably unintended side effects such as making this artist unsearchable on e-hentai.org (see https://e-hentai.org/tag/artist:lolimoyashi).

I thought I'd bring it up here because a similar issue was fixed a few weeks ago (https://forums.e-hentai.org/index.php?showtopic=266974).

This post has been edited by peterson123: Jul 12 2023, 15:10

Prior to the update there was the option to add "&skip_mastertags=1" to a search url in order to avoid a slaved tag's master from the search. This doesn't seem to work anymore. Could someone confirm that this has been removed?

This came up in another thread. There appear to be some restrictions that make some searches return zero results, especially searches containing the term loli and the like. This has assumably unintended side effects such as making this artist unsearchable on e-hentai.org (see https://e-hentai.org/tag/artist:lolimoyashi).

I'll look into it.

Prior to the update there was the option to add "&skip_mastertags=1" to a search url in order to avoid a slaved tag's master from the search. This doesn't seem to work anymore. Could someone confirm that this has been removed?

It hasn't been removed, but it looks like there might be some caching issues with using this function.

Though since the Autotagger was added, slaved tags will generally have zero hits after it has finished a complete cycle, is there really any legitimate use for this anymore? I'm probably just going to remove it rather than try to fix it, since it will probably be a fairly involved fix for an extremely obscure feature.

Though since the Autotagger was added, slaved tags will generally have zero hits after it has finished a complete cycle, is there really any legitimate use for this anymore? I'm probably just going to remove it rather than try to fix it, since it will probably be a fairly involved fix for an extremely obscure feature.

I wasn't using it to search the slaved tag exactly but to suppress unwanted results that I couldn't retrace. This mainly happens when using a "temp:" search, because most slaved tags are in that namespace. For example when I search temp:hit* I get a bunch of results where I have no idea where they even come from and can only assume that it's due to some slave tag. Maybe I can find a somewhat less obscure use case where the search result is mainly unwanted master tags but this is my best for now.

I wasn't using it to search the slaved tag exactly but to suppress unwanted results that I couldn't retrace. This mainly happens when using a "temp:" search, because most slaved tags are in that namespace. For example when I search temp:hit* I get a bunch of results where I have no idea where they even come from and can only assume that it's due to some slave tag. Maybe I can find a somewhat less obscure use case where the search result is mainly unwanted master tags but this is my best for now.

Getting a bunch of stray results if you use a three-character search with a wildcard is unavoidable anyway. Using exact tag searches would be a better solution to that.

Getting a bunch of stray results if you use a three-character search with a wildcard is unavoidable anyway. Using exact tag searches would be a better solution to that.

Yeah, but I did want stray results, but only the the kind of stray results I was looking for (actual temp tags starting with "hit"). I'm gonna admit, I don't see myself using the feature for anything not vigilante-related. So if it's trouble to fix, I don't have a problem with it being removed. The "trick" with &skip_mastertags=1 is still on the wiki and that was the main reason I asked.

Yeah, but I did want stray results, but only the the kind of stray results I was looking for (actual temp tags starting with "hit"). I'm gonna admit, I don't see myself using the feature for anything not vigilante-related. So if it's trouble to fix, I don't have a problem with it being removed. The "trick" with &skip_mastertags=1 is still on the wiki and that was the main reason I asked.

I see. Well, I took another look at it and it turns out it was a much simpler fix than it initially looked like, so this should be fixed now, but let me know if you encounter any other weirdness using this function. Considering that no one noticed it was broken for 9 months I'm guessing it's not exactly widely used.

I see. Well, I took another look at it and it turns out it was a much simpler fix than it initially looked like, so this should be fixed now, but let me know if you encounter any other weirdness using this function. Considering that no one noticed it was broken for 9 months I'm guessing it's not exactly widely used.

Cool, thanks, seems to be working as expected now.

I think I mentioned this somewhere, but it's because my code considers it indexable but the database engine does not, so it won't return any hits if it uses the index.

Generally, the database engine requires three characters, while my indexing code requires three single-byte characters or two multi-byte characters. It could probably print a warning if a shorter word was passed to an indexed lookup, but it shouldn't error out in general since it works with non-indexed comment lookups, like say when using

Maybe add an option to trigger non-indexed search for comments until it's fixed? Like a URL parameter.

A few other examples:
comment:"诸君安好" - 4 characters, but no results
comment:"诸君安好" group:"hell and heaven" - non-indexed? works
comment:"黒人" a lot of irrelevant results

Maybe add an option to trigger non-indexed search for comments until it's fixed? Like a URL parameter.

The alternative to indexed comment searches is no comment searches since the database load would be far too big to allow that.

As for whether a better index is available (like say ElasticSearch), that's certainly possible. Seems unlikely that it's worth the dev time though since I'm not familiar with it.

https://e-hentai.org/?f_search=comment:past...1022&prev=1

None of the galleries here have "pastes" in the description.

Also,
comment:video comment:released (misc category)

https://e-hentai.org/g/2643096/c85aa12d67/ only has "released"
https://e-hentai.org/g/2642901/c2360cb8f5/ only has "video"

So it looks like multiple "comment" qualifiers work as OR searches, but is this intended? If I add some non-comment keyword they seem to perfrom as AND again though.

This post has been edited by naaakful: Aug 16 2023, 14:35

Yeah, I'm aware wildcard characters aren't properly searchable for uploader names, I'll get around to fixing it.

Any updates for this?
Also uploader names contain "~", like this, are not searchable either.

Any updates for this?
Also uploader names contain "~", like this, are not searchable either.

It will be fixed by rejecting those characters in display names and prompting people with those characters to change their name, but this is probably some ways off.

If OR comment searching is possible, can it be made to be enabled with ~ operator instead of being default?

If OR comment searching is possible, can it be made to be enabled with ~ operator instead of being default?

It's not.