[X] My Assistant

Disregarding the previous hate comments, I do have a genuine question regarding my niche situation. I primarily browse e-hentai.org on my jailbroken iPad using a custom app called Shinsi2. Everything was working well until the changes to the search engine where it now just duplicates the first page. I tried installing another unofficial app called EhPanda, but my iOS version is too low to use it (13.5). My best option at the moment is to wait for an update to the Shinsi2 app, but if any developers of EhPanda are browsing this thread, would it be possible to enable support for iPadOS 13.5? Otherwise is there an alternate official/unofficial app that I can use to browse e-hentai.org with the new search engine and without going through an internet browser? Any help would be greatly appreciated.

This post has been edited by uo93: Nov 11 2022, 22:44

You know if the issue was server cost, why didn't you just post how much money you need to keep the pagination? I don't think you understand the disgusting amount of wealth that coomers have on this website that are willing to give to you to avoid the most basic feature of a gallery being removed.

You know if the issue was server cost, why didn't you just post how much money you need to keep the pagination? I don't think you understand the disgusting amount of wealth that coomers have on this website that are willing to give to you to avoid the most basic feature of a gallery being removed.

If we were to double the capacity for the core webserver cluster, $4500 per month.

Which isn't really realistic even if people pinky-promise to increase donations by that much, and it's just a kick-the-can solution anyway.

Hello I noticed a bug in the first day of the new update but forgot to report. When searching by uploader, I can't get any results with this search no matter what I do: https://e-hentai.org/uploader/bury_

Obviously has something to do with the underscore at the end of the name.

Two of this person's galleries for reference, I know there's at least one more:
https://e-hentai.org/g/1911459/c3c3f57648/
https://e-hentai.org/g/2364253/27220e4c12/

So many what ifs... you can't be serious right?
What if you forget which page you were on?

What if you view the site on another device?
- Use a browser with sync feature.
What if you forget to bookmark or close the tab?
- Use browser history.

They aren't what ifs for me though, they are things I do all the time. I do not use the same computer to browse the website all the time, nor do I want to used synced accounts because then I will need to use a browser which works well on PC but not on mobile. I do not want to have to create a damn account for a browser regardless though. Thats lowering privacy for something I want to keep private. I also browse the site in a private window so history is not saved.

Tenboro's solution is to use portable apps locked in a veracrypt folder. What about people on mobile devices like myself? And this is only really scratching the surface of my issues with this new system. It absolutely sucks for archival.

The issue for old-style paged searches is not bandwith, it is ram caching and cpu cycles growing exponentially when the archive grows linearly. No way around this, old system just had to go.

Besides, your "remember which page I was up to" was already a flowed method; because after a few months (or just after some days for frequently used tags, even a few hours for some) the same page number would not take you to the same content. What is now on page say 25 would be on page 33 or 44 or whatever after some time.

Better jot down the date of upload where you are (say, 25 dec 2015); next time search the same tag starting from that date and voilà ... you are exactly where you left off. (or the same day, at least)

Hardware has gotten exponentially faster and more efficient over the last decade. I don't believe that its simply "not possible" to go back to the old system. Of course it is possible, we just need to use hardware that can keep up with the demand. Which is infact solved by money. Like I stated. I don't see why we don't implement WebP to lower bandwidth costs, and ask for more donations if money is the problem. Both would help afford faster hardware.

This post has been edited by Black-lights: Nov 12 2022, 03:22

Previously, you could search in the gallery description by selecting a filter in the search. In this way, I found Pixiv galleries by id in the links specified in the description. And other useful things. Now I can't do that. Will this filter come back? Or is there a new search method that I do not know about?

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

Hardware has gotten exponentially faster and more efficient over the last decade. I don't believe that its simply "not possible" to go back to the old system. Of course it is possible, we just need to use hardware that can keep up with the demand. Which is infact solved by money. Like I stated. I don't see why we don't implement WebP to lower bandwidth costs, and ask for more donations if money is the problem. Both would help afford faster hardware.

Not going to comment on the specifics of this site, as I sure as heck don't know them. But you bring up hardware getting "exponentially faster and more efficient". People always quote Moore's Law, but as time has gone on, we're starting to push up against the physical limits of what that can do. Even Moore himself feels we're about at the end of it. I trust that people making chips are very smart people and they still have tricks left up their sleeves, but it's likely not going to be as simple as "just throw next year's CPU at it". And yeah, more money would help, but Tenboro already said that it would be a fool's errand anyway, just kicking the can down the road a few more years. A bandaid on a broken system, instead of a fix, just so we can waste money ignoring the problem a few more years.

I'm also not sure why you mention WebP at all. The selection of what image format to serve affects three things - a bit of processing power when someone first uploads the image (if the image is too large, to convert it to a more manageable size), the disk space needed to store it, and then pure bandwidth from that point on. None are relevant to the problem that is being talked about. 2/3 of those stats aren't even CPU- or memory-bound (which is where the old search was breaking). And the third - image conversion - I doubt is being performed on the servers that handle the database searching.

...I guess an argument could be made for lower bandwidth meaning lower costs thus meaning more money for servers? Maybe? But unless I misunderstand how this site works, aren't most of the images served by H@H... which means zero site bandwidth incurred for the normal image loads anyway? You'd save some bandwidth from Joe Schmo in Idaho running H@H, but none of that would turn into saved money for Tenboro.

You're right in one thing. Yes, it's possible. Most anything is possible. It's also possible to take your entire life savings and bring them to Vegas and see if you can double them over the weekend.

Not all possible things are smart things.

Hello I noticed a bug in the first day of the new update but forgot to report. When searching by uploader, I can't get any results with this search no matter what I do: https://e-hentai.org/uploader/bury_

Obviously has something to do with the underscore at the end of the name.

Yeah, looks like trailing underscores cause some issues with uploader names. I'll fix that for the next update.

Tenboro's solution is to use portable apps locked in a veracrypt folder. What about people on mobile devices like myself? And this is only really scratching the surface of my issues with this new system. It absolutely sucks for archival.

Your mobile device has built-in encryption and can be trivially protected with a number of different locks, so your solution should be obvious.

Not that it's even necessary. The "solution" is only so that the people who are somehow capable of remembering the query they were using and the page they were on, but are somehow incapable of remembering the date they had browsed to instead of the page, can store a bookmark of where they left off. There probably aren't anyone who actually have this problem.

Hardware has gotten exponentially faster and more efficient over the last decade. I don't believe that its simply "not possible" to go back to the old system. Of course it is possible, we just need to use hardware that can keep up with the demand. Which is infact solved by money. Like I stated. I don't see why we don't implement WebP to lower bandwidth costs, and ask for more donations if money is the problem. Both would help afford faster hardware.

I don't know what universe you're living in, but if "just throw exponential amounts of money at it" is a sustainable solution to exponential database lookup costs when the revenue is somewhere between static and linear, it sure as hell isn't this one. (And I'm not going to comment further on the fact that this is coming from someone with a donation total of $0.)

And as jadoeman says, the fact that you are bringing up WebP and bandwidth costs into a discussion about exponential database lookup costs just shows that you have absolutely no idea what you're talking about. Bandwidth is cheap, and most of the bandwidth cost is mitigated by H@H anyway, so there's little to nothing to save there.

Hello, I just came here after finding that the "Advanced Options" search in new e-hentai is now less functional than the old e-hentai one.

Can someone do me a TL;DR to bring the "Advanced Options" search to make the same effect on both sites?

I try to copy the URL of the search command in the old version to use in the new version & it is still not the same.

the search in the new version got fewer options & results compared to the old version.

Right now some old stuff I used to find is now gone & I got no idea how to bring that up again.

If I am lucky, I still get the URL in the history tab & need to swap the front URL just so it works again & that is not how I want to use it.

Pls, help.

This post has been edited by TrinTong: Nov 12 2022, 12:58

Any reason the GID search does not work in the favorites page? Just returns all favorites, searching for tags or titles works fine.

WebP

Silly little boy. WebP is old tech now. We have avif and heif. Also yes I too put my DB in WebP format for better performance and cost savings.

This post has been edited by Cipher-kun: Nov 12 2022, 17:37

... most of the bandwidth cost is mitigated by H@H anyway, so there's little to nothing to save there.

HentaiDB@Home?

Just a random silly thought. If scaling the processing load of the database is the issue why not distribute it? I have no background in database operations, but I'm pretty sure the magic of Google and other search engines being so fast is the capability to do distributed lookups.

magic of Google

Just did a search for porn.

First page: About 839,000,000 results (0.45 seconds)
No last page button
Page numbers generate only as you increase, and there is no skip to last page button.
Hit page 15
Page 15 of about 145 results (0.90 seconds)
Can't go any further.

On Google Workplaces (and presumably normal gmail), any search with >1 page shows "page 1 of many", with no jump to last button, and clicking manually through until the end is the only time it displays the actual results.

Even Google with all their resources has limitations.

Any reason the GID search does not work in the favorites page? Just returns all favorites, searching for tags or titles works fine.

gid: is not actually supported for favorite searches, guess I need to add a warning for that.

Just a random silly thought. If scaling the processing load of the database is the issue why not distribute it? I have no background in database operations, but I'm pretty sure the magic of Google and other search engines being so fast is the capability to do distributed lookups.

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 don't like this update. Being able to jump to a certain page when looking through my favorite tags allowed me to keep up with what I've read and what I havent. Second, I liked the ability to look at expunged galleries ALONG with the normal galleries. It allowed me to at least see if there's something I missed for one reason or another. Idk much about website management but it seems like these changes did a lot worse than improve. I didn't think there was a problem with the previous system.

I don't like this update.

A lot of people have already said that. And it won't change a thing, and do you know why ?

Because, would you prefer if this site close down forever ? 'cause it's what is going to happen if people goes on pretending next-to-impossible things from what, at the end of the day, is essentially a one-man amateur's effort. This site is not a for-profit big company.

You have this site. It is a miracle already. It's free for anyone (thanks to donor, especially Catgirls). It lasted a lot of time already. Enjoy it while it lasts, just don't take it for granted.

Tenboro deserves only praise and thanks for what he did all these years, not gratuitous criticisms and unwarranted aggressive (and almost always plain ignorant and wrong) posts, on the line of "why won't you do it this or that way".

For what is worth my opinion (i.e. nothing), he has been already too much patient, trying to answer to objections, trying to make people understand the real problems at hand, trying to enhance the new search engine in ways more alike to what people asked.

I know in his place, I would have already told the world "go f@@k yourselves" !

I'm not telling all this specifically to you, Vegaswolfpac, so please don't take it personally. It's just that all this has been going on too much days already.

So, any chance of that random button for favorites? Not sure how favorites are stored, but if all GIDs marked as favorite can be referenced at once, then it would just need to randomly choose one and search it.

Alternatively, is there any way a user could somehow reference all favorites at once in a script without manually grabbing every GID?

This post has been edited by balloondraw: Nov 12 2022, 20:35

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

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!

Assuming I read it right, I think the idea was for something like H@H except for the search engine. So instead of distributing bandwidth, you distribute processing power. And do so in a dedicated - and intentionally installed - client, instead of in, I dunno, on-page Javascript. (Just the thought of in-browser database management via JS gives me nightmares.)

...Though that comes with its own problems. Bandwidth sharing works well here, because each client can serve a small fraction of the full database. Client #12345 doesn't need to know or care what the other thousands of clients are doing, nor does it need to have access to anything beyond its own slice of the pie. It just keeps its own cache of images, serves them to anyone who asks, and on occasion gets told from the mothership to serve different images. (I'm sure it's more complicated than that, like with certificate renewal and logistical challenges of who serves what and when, but that's probably tangential here.)

Volunteer-distributed stuff works well in situations like that. It can work for processing too; things like seti@home and folding@home come to mind. But they share a common thread with the bandwidth examples - a client doesn't need access to everything. They get mostly isolated jobs submitted to them from the mothership, they handle those tasks, and report back the results. Like a process pool in a multiprocess app.

The search engine needs the entire (metadata) database to search over. It simply can't operate without that - how can you return accurate results if you're not even seeing most of them? So distributing the search would mean that every single client has the full database to reference, and would need to be kept up-to-date with every single tag or title change. Which sounds like a nightmare. I can't imagine how many database changes happen every hour, or even every minute.

So, any chance of that random button for favorites? Not sure how favorites are stored, but if all GIDs marked as favorite can be referenced at once, then it would just need to randomly choose one and search it.

Honestly it would be nice to just have a generic "random page" button. Not just for favorites, but for any search. I've seen a number of times now people wanting pages for that - they want to see "page 1 of 34", then roll their mental dice and pick page 23. Dates don't really have that kind of thing, since you don't know when it started, so you can't aim for somewhere "in the middle". (Yes, I recognize the contradiction of explicitly seeking something "in the middle" when you want random, but that's how people's brains work. The edges aren't "random enough".)

So if there was a button to just tell the search engine "give me a search page starting at randrange(firstgid,lastgid)" then that would probably help. Still would have the same issue of the results maybe not being equally distributed. but Tenboro already mentioned improving that kind of stuff for the scrobber-prototype-thing.