[X] My Assistant

Based on the excellent job of FabulousCupcake, I tweaked it a little bit, now it should work with compact/extended list and will show the span of gid shown.

(IMG:[i.imgur.com] https://i.imgur.com/YUeP1Nm.png)

[gist.github.com] https://gist.github.com/OceanS2000/0849a058...71958944883b4df

Thnaks for the script but just want to report I'm having too the null-1 problem the other two guys posted

@Tenboro I think I speak for plenty of people in asking for an option to at least see the titles of deleted and expunged galleries in our favorites.

I was making my way backwards through a certain category. Now my bookmarks are all broken and I'm not able to get back to where I was. You should NEVER break bookmarks.

This post has been edited by ajarlube: Nov 3 2022, 09:41

Gotta get used to this page-flipping thing

what the fuck why

Seems counter productive to remove page numbers I like looking in between and not having to sift though countless pages

The change in indexing, despite its problematic implementation might be understandable but new tools should be added to at least partially recover the lost functions in searching (As someone already demonstrated some replies ago).

However the new mutually exclusive searching of normal and expunged galleries is inexcusable. Also please announce and beta test the major changes before its silent and sudden implementation.

And yes, in line with Halloween celebrations, the skeletons are rising just to scream.

Easy way to reduce resource usage is to reduce users: Mission Accomplished?

id say it openly - its crap!
i browse weekly galleries with tags that have page resulys in range 100~200, one has 200+
often jumping too middle ranges an browsing from there (bookmarks are not an option)
not sure if i want to spend 5min (150p x 2s per page) to do nothing else just to click "next" for something that was done in 5s

also separating expunged from results...
now workload doubles case we need to search tags again with expunge on - often multichapter works are expunged and only last chapter, resp. compilation of chapters is visible

kinda fast way to keep us users on last 10 pages and history be forgotten (IMG:[invalid] style_emoticons/default/sad.gif) *SAD*

ps: how hard is to transform GUID list to pages - we have N resultes per X shown per page
by adding each Xth GUID to N+1...
only thing im thinking, search seems now indexes only 1st and last page instead pushing all results at once

Suggestion:

Since we've already gone this far, why not try to enable the function of ← and → keys to travel back and forwards between the pages (IMG:[invalid] style_emoticons/default/smile.gif)

Would be a lot easier for folks to view the hentais

Oh boy, time to post my first message! I'm sure it'll be positive. Oh wait, my almost exclusive mode of browsing is dead.

When changes like these are implemented, they are usually judged from the perspective of a tech-savvy admin/mod/dev who knows their site and all its functions in and out and enjoys jumping through hoops, as evidenced by their comments so far. But the average user is none of that. The average user is an instinct-driven monkey. See number? Click number. Number works. Number good. Use number again later. —Where number gone? What "GID"? How far from home is monkey? How far from end? How run faster? How return? Monkey no know.
Your users, outside of a tiny subset, are not like you. Get that out of your head.

Very weird that it tells me things like "Found about 3,407 results". That's an awfully specific number to then prefix with an "about". Like, what do you mean now, can you count or can you not?
The new navigation elements look out of place, clash with the rest of the site. Is that a different font? If so, why?

Expunged galleries are separated. Guess I'll need to browse on two windows simultaneously now.
Even the favourites lost their page numbers and aren't even tallied up any more. Now I have to do the math myself, and if I want to get to a doujin that I know is on page 7, then have fun clicking six times instead of twice. Oh and deleted galleries are gone for good, though I've hope that's just a bug.

I'm sure it's all lovely for the backend, but for the user? My god. Actual Youtube-tier.
I'd honestly prefer the site buckling and groaning under its inevitable load, eventually forced to limit bandwidth hard or searches receiving a loading bar to inform you how many coffees you can brew before it's done.
New OR searches are cool though, I'll make use of those some time.

I'm surprised more people didn't learn from the near death of sadpanda to back up literally everything.

I remember way back that the internet was forecasted to get worse and worse, more commercialized, sterile.
Sad to see it happen to something everyone loved.

I've backed up everything I liked ever since I found the site. Problem is, I don't have time to review every gallery that looks promising. I have a backlog of porn to check out stretching back years at this point, and I'm not about to start buying enough HDDs to store literally everything that looks like it MIGHT be decent, especially not with filesizes ballooning the way they have been recently.

I can think of several ways to do effective pagination.

As an example, have GID-SORTED (so, numerical sorted and chronological) databases (or sqlite) or whatever for every tag (possible due to tag whitelisting) with just the GID in it.

When a search is executed, start a poinrter on the newest gallery(GID) in each DB that the tag search was.

Ex. user searches "yuri kimono kissing" (minus quotes, I'm going to ignore wildcarding, as that's a solved issue)

(Assuming the most recent GIDs)
initialized to most recently added:
yuri DB at GID 2367160
kimono DB at GID 2367160
kissing DB at GID 2367081

pick the smallest DB with the least GIDs (kimono DB in this case).

pick the 2nd smallest DB and see if has a matching GID (recall all DBs are numerically GID sorted, so this is very very very fast).

If no, fail-fast, advance to the next GID in kimono DB, and repeat the search in kissing DB, but limit off the area you already searched and know to be before the first search.

If yes, proceed to the yuri DB and do the same thing. Repeat for every tag in a search. As you have more tags, the amount of galleries matching the smallest DB(least common tags) will fall off dramatically, so more tags doesn't necessarily mean more load on the search.

This would be VERY fast, as it only hits the smallest databases first, so you can give an accurate total number of search results, which allows GID based pagination/indexing at least client side.

For nasty searches like just "big breasts", just cache the results and either update it every few minutes, or have it update itself whenever that tag is added to a gallery.

TL;DR: paginate searches using the smallest DBs first, and if any search is used enough to cause performance issues, just add it (or the tag combination) to be cached. I'd suggest automating it, but I know that's just adding a ton more work on someone's plate.

Fair warning, it's really late and I'm somewhat drunk and wrote this up in 3 minutes.

EDIT:

Some back of the napkin math shows 3 bytes to an int to 15million, let's just say 4bytes for future proofing, which would be 4 billion or something.

If you had a DB with JUST a GID for EVERY gallery, it would be currently 700000*4bytes, so 2.8MB.

This is not going to happen so most of these hypothetical single tag GID DBs would be in the KB range.

If you're concerned about load, you can hand these to the clients and they can do the pagination processing.

Ex. Someone searches "yuri kimono kissing", local javascript pulls those 3 DBs (62,488 yuri results so ~300KB, 11,000 kimono results so ~50KB, 13,000 kissing results, so ~60KB, so ~410KB total), and gets to work generating local pagination for them for as long as they're in that specific search.

Double/Triple the sizes for overhead, and you're still in margin of error for bandwidth use for a single image.

This post has been edited by manywelps: Nov 3 2022, 10:43

This update has made the simple act of searching hentai to fap to way more tedious and annoying than it needs to be. Not a fan, especially the removal of page numbers and the whole expunged galleries thing.

I'm having deviantart flashbacks, roll it back plz?

How do I jump to page 15 of my cyan favorite list? The numbers in the url seem to be random for each page.

Lets say I now want to browse page 27 of the same list how would I know what GID number to put in? or even what page I'm currently at right now so that I know how many more 'next page' I need to click to get there?

I get the technical reason for it, doesn't mean it was a good idea.

Do you have any idea how many pages I have in my favorites? Why would I want to manually go through every single page.

The MAXGID value is output as null and does not work. Does anyone know a solution?

Doesn't seem to work. Bar's just green, with range of null to 1 for me

my bad. I fucked up updating maxGID in list layout other than compat.

This new version should fix the problem, though. (Still you need to open Front Page once without any search terms, etc. to make it work)

[gist.github.com] https://gist.github.com/OceanS2000/0849a058...11.03.3.user.js

This post has been edited by OsenTen: Nov 3 2022, 11:00

Been around since 2008. While I think pages are important and should be reimplemented, another problem here than just the absent of pages is the new method just doesn't have a good visual indicator for how far into a search result you are. We went from a fairly easy to use and ubiquitous UX, numbered pages, to a bare bones one with no indication how much further the galleries go or how far we've been thus far.