[X] My Assistant

Bandaid fixed my favorites with that script (only work for me, this just show an approach to developers that would not just copy-paste this and think it will provide a desired effect without changes):

CODE

    const url_params_string = window.location.search;
    const urlParams = new URLSearchParams(url_params_string);
    const searchNavBar = document.querySelector(".searchnav");
    const f_search_param = urlParams.get('f_search');

    let div_pages, currentPage, currentPageLink;

    var ehPagesDatabase =
    {
        "-favnote:horizontal favnote:vertical" :
        [
            "2204419-1651178671",
            "1578701-1582547767",
            "960706-1470075935",
            "787322-1424039781",
            "625136-1377846583",
            "1-0"
        ],
        "favnote:horizontal -favnote:vertical" :
        [
            "2141801-1644867766",
            "771641-1420026851",
            "1-0"
        ],
    }
   ;

    if(f_search_param in ehPagesDatabase) {

        div_pages = document.createElement('div');
        div_pages.id = 'pages';
        div_pages.style.setProperty("margin", "2px auto 2px");
        div_pages.style.setProperty("overflow", "hidden");
        div_pages.style.setProperty("width", "auto");

        searchNavBar.removeChild(searchNavBar.childNodes[7]);
        searchNavBar.removeChild(searchNavBar.childNodes[6]);
        searchNavBar.removeChild(searchNavBar.childNodes[5]);
        searchNavBar.removeChild(searchNavBar.childNodes[4]);
        searchNavBar.removeChild(searchNavBar.childNodes[3]);

        searchNavBar.insertBefore(div_pages, searchNavBar.childNodes[3]);

        for(let i = 0; i < ehPagesDatabase[f_search_param].length; i++)
        {

            currentPage = document.createElement('div');
            currentPage.style.setProperty("border", "1px solid");
            currentPage.style.setProperty("margin", "0px 2px");
            currentPage.style.setProperty("padding", "0px 2px");
            currentPage.style.setProperty("float", "left");

            currentPageLink = document.createElement('a');
            urlParams.set("prev", ehPagesDatabase[f_search_param][i]);
            currentPageLink.setAttribute('href', "https://e-hentai.org/favorites.php?" + urlParams.toString());
            currentPageLink.textContent = (i+1).toString();

            currentPage.append(currentPageLink);
            div_pages.append(currentPage);

        }

    }

Not evolved enough to be a standalone script, especially since everything is hardcoded in the code itself, but I wanted to show the method I used.

The idea is that for each frequently used search, the url of each page (starting from the last) of results is saved, then pages selection is generated from that.

I wish I could make a wizard that guide the user to populate/update ehPagesDatabase, and then save/load buttons that turn this variable into text you can keep in a text file, and regenerate that variable from such text.
But all the GUI work involved is too much of a burden, it's beyond my specialty.

Is it not possible to have a jump or option to only show new releases since my last active?

Also i bought Paging Enlargement III and its not working.

Also i bought Paging Enlargement III and its not working.

From the initial update changelog: "The max number of results per page is now 100. Paging Enlargement III was removed and will be refunded Soon™."

Being able to search downvoted tags was similarly useful for vigilante works, it now requires checking someone's personal tagging history to clean up after them if someone with a decently high MP misunderstands a tag.

People have pointed out this particular weakness, so I'm looking into a different approach of dealing with weak tags. Stay tuned for that.

Can you tell us if you have plans to implement a similar function for downvoted tags? I agree with Glovelove that there was a use for that.


Off topic:
I never would've thought y'all had been sitting on such a significant update to the site when I asked that seemingly unrelated question some three weeks ago, if you can remember that.

My IT knowledge is, quite frankly, non-existent. Nevertheless, I trust you guys when you say getting rid of the pagination system was necessary to ensure the sustainability of the site. I think the explanation of the new 'search by GID' in OP was adequate, and I could immediately see that manipulating the url & estimating the GID would take you where you wanted. Of course the UI for that was completely absent, but that's been addressed now as well, thanks in part to helpful members of the community. It's really disappointing that a lot of the replies ended up becoming as they did, but I think y'all held your heads high regardless.

I'm looking forward to the new visual aids you've mentioned as with that, there really should be no more benefit to sticking to a page based system. And thank you E-hentai (or 10b ig. Hear that guy's been running the 20th most popular .org site in the world on his own basically), for maintaining this wonderful, one-of-a-kind Library of Awesome, even after all these years.

Let us know when you have figured out how to safely, quickly and reliably integrate that into a webpage without needing every visitor to install anything. Go team!

I have no interest being part of the "naysayer brigade" groaning over the changes, merely wanted to point out a potential solution out of academic interest.

The idea I called HentaiDB@Home would be similar to the current image distribution backend, but instead of images you'd distribute the gallery database in a primary-replica model. Volunteers have full replicas of the database that follow changes made to the primary. The site backend could then farm out queries to this pool of replicas. Throw in some caching for a result set (token encapsulating a given query, valid for x hours as those precious pages are explored) and serve pages based on it. Could be neat, also entails lots of design and backend work.

Again, purely [www.scylladb.com] academic. Nothing suitable for an issue needing a solution yesterday, as seems to be the case here.

Tenboro, thank you. Not sure how often people tell you that, but thanks for putting in the hard work over all these years to keep the site running.

Hey,When I call out the Console to test the page,I found something like "“toggle_advsearch_pane”Undefined".

I guess maybe it can be fixed by some special tech on client,can it?
So that these function can work in IE,then i don't need to change browser.

This post has been edited by BB201265: Nov 13 2022, 09:17

In my opinion, a community-based distributed database is not really practical, the clients will need to store a full database, and some specific softwares need to be programmed, and the results are not guranteed to be accurate. Such system is more complicated compared to a file distributing system like H@H. Still, it may be a solution if we can periodically download a copy of the gallery database and make some unofficial indexing services.

Can you tell us if you have plans to implement a similar function for downvoted tags? I agree with Glovelove that there was a use for that.

There's no index for that and it's not really worth the effort of maintaining one, so not this time around. That said, there's a small chance it could be reintroduced at some point in the future after I redesign the tagging vote tables since it would be able to use those directly, if there are actual practical use cases for that functionality.

I thought of something that could improve my use of my favorites, though I think of it as an alternative of the current system, rather than a replacement that overwrite it, since it may not be an improvement for other use cases:
Instead of a "prev" and a "next" button, there would be a "see more" button, and when clicked, it would load the next results in the current page.

Some minor fixes:

- Fixed some more search issues with uploader usernames with leading or trailing underscores as well as multiple consecutive spaces/underscores.

- We now avoid using the /uploader/ shorthand URLs for uploader usernames containing forward slashes since the resulting URLs are broken.

This build will probably be fully deployed early next week unless any more issues are discovered.

The keyword I searched for was artist:someone$ -language:translated$
(artist:someone is for example only, not the artist is called someone)

It shows that I found 67 results, but obviously less than 67 results

And I removed -language:translated$ to search, the result is the same as 67, but the result is obviously more than 67, why is this happening?

In addition, about the usage of weak

Taking the above example, I want to search for weak tags of artist:someone$ -language:translated$

What should my keywords be? I still don't understand after reading the description

artist:someone$ isn't a clear example, you need to be more specific.

Weak tags cannot be used for exclusions or searched in favorites.

So in your case, the keywords would be weak:artist:someone$ -language:translated$.
It will search weak tag artist:someone$ and exclude active tag language:translated$.

- The search engine will now stop looking for more results if more than 1000 galleries have been filtered. (This is mostly relevant in edge cases where you are intentionally searching for things you heavily filtered.)

I'd assume this is referring to filtering with default filters (which I don't really use, I got watched tags in red to warn me about stuff I wouldn't want to use as porn but blinding myself would be really counterproductive for vigilante work) and/or tags excluded in search.

How do I know if/when my search results are cut off by this? when dealing with the manga category I'll generally use "-anthology -tankoubon" as shorthand for "just the stuff where presence rule isn't a major headache" but I don't have a clue how much search results this filters specifically, total results being summarized as "Found many results." and having no page numbers doesn't really help me to calculate how much I would have filtered either.

Oftentimes when I'm getting an excessively large search result when tagging I'll add some arbitrary filters (pretty much always category, followed by a few popular languages or related tags and then I can bundle up the leftovers by just excluding the additional tags I already went through separately)

Of course, compartmentalizing my workload for more visible progress is something I could go without, unless I'm misunderstanding this feature it sounds like it's just hypersensitive to language filters in general given that even a single one can easily be 1k results to filter out (and those can't always be circumvented by just adding additional tags......because Japanese raws can only really be searched by filtering/excluding translations and non-translated non-Japanese content)

This post has been edited by Glovelove.: Nov 13 2022, 19:59

I've searched this :

english incest "sole male" female:daughter male:dilf female:impregnation

And exh is telling me this :

Some of your keywords were not used. Try combining keywords with quotes. (Ignored sole male)

I have also done variation for sole male like male:"sole male" or male:"sole male$", it is still ignored. Why it is ignored? Is it because the search didn't find any with that particular tag in together with other tags?

I'd assume this is referring to filtering with default filters (which I don't really use, I got watched tags in red to warn me about stuff I wouldn't want to use as porn but blinding myself would be really counterproductive for vigilante work) and/or tags excluded in search.

How do I know if/when my search results are cut off by this? when dealing with the manga category I'll generally use "-anthology -tankoubon" as shorthand for "just the stuff where presence rule isn't a major headache" but I don't have a clue how much search results this filters specifically, total results being summarized as "Found many results." and having no page numbers doesn't really help me to calculate how much I would have filtered either.

It cuts off the number of results it shows on one page, not the result set as a whole. In other words, the "Your default filters removed" message will show a number above 1000. Anything that got cut off will be on the next page.

english incest "sole male" female:daughter male:dilf female:impregnation

Some of your keywords were not used. Try combining keywords with quotes. (Ignored sole male)

You're using more than five inclusion search terms. The error message could probably be more specific.

artist:someone$ isn't a clear example, you need to be more specific.

Ok

The keyword I searched for was artist:smomo$ -language:translated$, and only for types Doujinshi and Manga and Artist CG

According to the above situation, there are 67 results, but obviously less than 67 results

If I removed -language:translated$ to search, the result is the same as 67, but the result is obviously more than 67

It cuts off the number of results it shows on one page, not the result set as a whole. In other words, the "Your default filters removed" message will show a number above 1000. Anything that got cut off will be on the next page.
You're using more than five inclusion search terms. The error message could probably be more specific.

Oh ok, yeah I did indeed misunderstand what the change actually meant then.

Wasn't really familiar with the default filters in general because aside from a specific blocked uploader and filtering out rewrites back when I wasn't aware how much that tag was abused I've only really used it to temporarily block watched to then search them with low power included to recreate the same functionality the new weak modifier added.

Let us know when you have figured out how to safely, quickly and reliably integrate that into a webpage without needing every visitor to install anything. Go team!

Lol , I concur .

Potential bug with search - gallery description contains pixiv url (e.g. [www.pixiv.net] https://www.pixiv.net/en/users/16504957), searching for "16504957" with the old engine turns up all galleries with the url. New engine can't find any of them.

Ok

The keyword I searched for was artist:smomo$ -language:translated$, and only for types Doujinshi and Manga and Artist CG

According to the above situation, there are 67 results, but obviously less than 67 results

If I removed -language:translated$ to search, the result is the same as 67, but the result is obviously more than 67

I tried searching with artist:smomo$ and artist:smomo$ -language:english$.
Both give me the same number of results count, but the second one is approximate.
It says "Found about xxx results".
Maybe you have some default filters enabled?

Potential bug with search - gallery description contains pixiv url (e.g. [www.pixiv.net] https://www.pixiv.net/en/users/16504957), searching for "16504957" with the old engine turns up all galleries with the url. New engine can't find any of them.

I'm getting the same results with the old and new engine. Better with the new one in fact, since the old one doesn't handle the full URL but the new one does. Disable your filters if enabled. If they still don't show up, post the exact query you are using. (You're probably missing a comment: before the number.)