- There is a cap on the number of favorites that a user can have(80,000).
- There is a cap on the number of posts in a pool(1,000).
- There is a cap on the number of posts in a set(10,000).
- There is a cap on the number of sets you can have(75).
source:https://e621.net/forum_topics/25717

Okay, the 'what are they' is a bit rhetorical, but I'm curious as to why we need them.

I'm especially concerned about the favorites cap as I am currently around the 60k area and may very well hit this cap in around 18 months or so. What happens when this cap is hit? Can we no longer add new favorites, will the oldest ones be deleted?

Update: Fun bit of info for anyone that happens upon this. I finally hit the cap 14 months later. 5/8/21

mdf said:
- There is a cap on the number of favorites that a user can have(80,000).
- There is a cap on the number of posts in a pool(1,000).
- There is a cap on the number of posts in a set(10,000).
- There is a cap on the number of sets you can have(75).

Okay, the 'what are they' is a bit rhetorical, but I'm curious as to why we need them.

I'm especially concerned about the favorites cap as I am currently around the 60k area and may very well hit this cap in around 18 months or so. What happens when this cap is hit? Can we no longer add new favorites, will the oldest ones be deleted?

now im concerned i didnt know there was cap on the favorites

Assuming you go by 120 posts per page, that's over 600 pages. Nobody needs that many unless they plan on mass-favoriting.

It's scary on the surface until you realize just how big 80000 is. I have been on this site for ~9 years and I only have about 12000 (from memory, page numbering has been deleted/ corrupted by the update so I can't check by [(posts/page)*pages]

Where did you find this info?

Yeah, I'm also curious as to why we need them.
I've been on here since 2011 and I've well exceeded the 80k fave limit.

furrymcfuzzball said:
Assuming you go by 120 posts per page, that's over 600 pages. Nobody needs that many unless they plan on mass-favoriting.

It's scary on the surface until you realize just how big 80000 is. I have been on this site for ~9 years and I only have about 12000 (from memory, page numbering has been deleted/ corrupted by the update so I can't check by [(posts/page)*pages]

Sure, 80k is a lot, but there are (as of the time of me writing this post, judging by the latest post number and not taking into consideration deletions) 2.1M+ posts on this site, and 80k is only ~3-4% percent of that content.

As for mass-favouriting, personally, if I see something I like, I favourite it.

By having favourites like that, it helps when using the -fav:username meta-tag when making specific searches to filter out the stuff you know you've already seen and enjoyed, and want to see something new, or that you previously missed.

At least that's my two cents on it.

mynameisover20charac said:
Where did you find this info?

This post
https://e621.net/forum_topics/25717

Think I should just drop this in here:

If you are not able to favorite posts, it may be because you already have more posts than the cap allows.

(all your favorites are preserved, but you cannot add new ones until you drop below the cap)

I've seen about 6 people complaining about something that might be this, so far. 3 confirmed cases of someone having >=100k favs.

One wonders how Dracotay is faring. :/

Is that the guy who favorites practically everything..?

savageorange said:
Is that the guy who favorites practically everything..?

Yes. This cap is bound to put a crimp on things for him. Whether that's for good, bad, or indifferent is up to him, of course.

savageorange said:
Think I should just drop this in here:

If you are not able to favorite posts, it may be because you already have more posts than the cap allows.

(all your favorites are preserved, but you cannot add new ones until you drop below the cap)

I've seen about 6 people complaining about something that might be this, so far. 3 confirmed cases of someone having >=100k favs.

This still doesn't explain why there's a cap in the first place, which is the main question here.

It's not supposed to.

If you want my guess it would be that the performance of a bunch of things was profiled and 'extremely large fav lists' was shown to significantly worsen performance.

1. A user with 80,000 favorites has never learned about the upvote button, and has treated the favorite button as their like button.

2. That pool post limit is something that concerns me on the front of comics like FvT and Silver Soul.

Someone should probably prep the Silver Soul pool in particular for division by chapter, as it's at 928 posts.. dangerously close to that limit.

foxybomb said:

Someone should probably prep the Silver Soul pool in particular for division by chapter, as it's at 928 posts.. dangerously close to that limit.

.. really?
I calculated it at (37 x 24) + 3 = 891 posts. Am I wrong about the page size being 24?

savageorange said:
.. really?
I calculated it at (37 x 24) + 3 = 891 posts. Am I wrong about the page size being 24?

If you look at Silver Soul in the Pool Listings, the post count says 928. I'm not going to pretend I know why there's a discrepancy, I just know that this is (at least) what the site thinks.

Hmm. Probably deleted posts that were BVATSed, then.

foxybomb said:
1. A user with 80,000 favorites has never learned about the upvote button, and has treated the favorite button as their like button.

Oh, I always knew it was there. If a piece was particularly good then I would upvote it and forget while my favorites list was something I actually really liked and wanted to return to later. Upvoting was my way of saying 'hey, you did a really good job' (without needing to comment because let's face it, I'm a lazy sack of potatoes) even though I might not actually favorite the post, I still recognized that it was good content.

Now that I see that 'votedup:anything' is a thing... If I really have to go through my 596 pages of favorites and 110 pages of upvotes, I'll be mildly annoyed.

Now what's really confusing me is if large favorite lists are something that's causing performance issues and is something that needs to be capped, voting is basically the same thing, or at least it appears so on the outside. Why isn't voting being limited as well?

Yeah this is quite annoying as I use the favorites system to basically have a curated list of stuff I like that I can use order:random on to get some good stuff instead of diving into the rest of the posts and stumbling onto some 8 year old post with untagged gore or something. Though it probably will be a while before I hit 80k

mdf said:
Oh, I always knew it was there. If a piece was particularly good then I would upvote it and forget while my favorites list was something I actually really liked and wanted to return to later. Upvoting was my way of saying 'hey, you did a really good job' (without needing to comment because let's face it, I'm a lazy sack of potatoes) even though I might not actually favorite the post, I still recognized that it was good content.

Now that I see that 'votedup:anything' is a thing... If I really have to go through my 596 pages of favorites and 110 pages of upvotes, I'll be mildly annoyed.

Now what's really confusing me is if large favorite lists are something that's causing performance issues and is something that needs to be capped, voting is basically the same thing, or at least it appears so on the outside. Why isn't voting being limited as well?

596 pages of favorites? Organized into sets, I hope.

I'm glad to know I'm not the only one affected by this. I am one of those in the aforementioned >=100k favs club and I'm very glad my favorites weren't culled to 80k, at least.

I only have a very vague idea of how backend stuff works on a website and I am curious as to why this causes such a headache while other things, like tags or upvotes, seemingly don't. If I had known it was causing an issue I would've used an alternative method.

If upvotes don't cause the issue and there's no plan to raise the fav limit back up, then provide a way to convert your favorites into upvotes so we can use the votedup:anything tag to view them instead.

I feel that if heavy favorite-ers are going to lose their ability to continue faving things we're at least owed I would appreciate an explanation.

Problem with using votedup:anything is that there is no query option to get all upvoted posts from other users, like how it's possible with favorites.

I used sets for roughly organized collections and similar, because it gives no more flexibility.
But now with the 10k posts per set limit that is basically impossible.

For the limited knowledge and speculation I have about the backend stuff, I would suspect that having some kinds of "super" versions of sets / pools / favorites would be a reasonable compromise.
Idea is that these super lists are saved in another database table with longer cells, so that the main table doesn't get longer.
Or split those long lists into multiple smaller ones and join them in the frontend.
Maybe also increase the nice level / decrease the priority of queries containing such sets.
But this is all speculation and idk.

But storage space doesn't seam to be the problem, because:
Every user gets 750k (75 * 10k) posts to save in sets, 80k favs and basically infinite pools. So more than 830k saved posts per user.

So the problem seams to be in the performance part (even though "large" sets still exist).
And already pointed out here: Up votes don't seam to have that problem, so there has to be some way of making it perform better without limiting the users that use this site already for long and/or extensively.

foxybomb said:
596 pages of favorites? Organized into sets, I hope.

No.

Back when I got into this whole thing and was fanatically downloading stuff after having more than one artist DNP their stuff here, I used to take the time and organize things. Species > gender > # of characters for all the general stuff, kinks, animated stuff, specific artists, specific characters. I still do to a degree, but after I found e6 and a tagging system that actually worked and is community-driven instead of done by artists (see FA), that's fallen by the wayside.

I guess disk corruption didn't help either, but these days I can't really be assed because again, lazy sack of potatoes. Now that the tag search limit has been removed, the only real threats are content being removed, internet outage, power outage, e6 shutting down, government censorship, government collapse, an EMP from a less than friendly country, zombies, plagues, gamma-ray bursts, and acts of god.

Already use a small number of tools to curate my content here but the API change borked all that of course so I'm waiting. Think I'll look into that tool that tags your downloaded images, who knows, maybe I'll get back into really sorting my downloads again.

Favorite cap is indeed a performance thing. Specific users were getting so many favorites that it was interfering with database statistics generation and causing small site outages when they interacted with their favorites. The reason that favorites have a limit and voting doesn't, is because of the way votes are accessed compared to favorites. They are not pulled up publicly anywhere so the number of ways they can be accessed is quite small and controlled. Favorites get used a lot on the site, and the sorting information on them is important, but it isn't for votes(don't ask me for images sorted by vote date, please, I can't offer it unless I can do some major problem solving,) so there is a less controlled number of ways they are accessed.

One of the preliminary fixes for this was to move favorites partially into the new search system, but the new search system doesn't(and may not be able to?) support the additional information of when a favorite was added. This made doing searches for tags among people with lots of favorites go from being a constant maintenance headache, to almost instant and without cost, but didn't solve that favorites still are so visible that it's a problem when favorite list sizes get too big.

Sets are capped for sanity reasons to prevent them from getting too big and causing other problems. Pools cap might go up, but I don't know yet, there is a lot that goes into analyzing usage patterns and making sure that things can't simply break the site because it became too large.

Summary: Lots of technical nonsense involved in trying to make stuff work.

kiranoot said:
Favorite cap is indeed a performance thing. Specific users were getting so many favorites that it was interfering with database statistics generation and causing small site outages when they interacted with their favorites.

No idea how feasible this is, but a compromise idea: Since anybody with 100,000 favs can't possibly care about exactly what order they're in, how about a soft cap? Tell users that favourites will be sorted as long as you have fewer than a certain number, but if you go over that then the ordering will be lost. Maybe even go the extra mile and make it a user setting to choose between convenient but capped and uncapped but impenetrable. To give you an idea of the sort of person who might willingly use the second option, I've seen at least one person on here claim they used the favourites as a "seen" marker.

kiranoot said:
The reason that favorites have a limit and voting doesn't, is because of the way votes are accessed compared to favorites. They are not pulled up publicly anywhere so the number of ways they can be accessed is quite small and controlled. Favorites get used a lot on the site, and the sorting information on them is important, but it isn't for votes(don't ask me for images sorted by vote date, please, I can't offer it unless I can do some major problem solving,) so there is a less controlled number of ways they are accessed.

So, what I got out of this was that it comes down to the search term used ('are accessed' correct?) and because favorites are used more commonly than voting, explains why the cap is in place? Is this correct or have I misinterpreted?

As for sorting information, I just voted up three images and they all appeared ordered in the time that I voted on them. I also visited my earliest voted images (boy that's a trip down memory lane) and they matched up with what I had in mind for that time period. It seems as if order isn't a problem unless my quick check was too quick.

Would there be an option for users to bulk translate favorites into votes? Also, favorites lists are being targeted for the ability to make them private, will votes be given similar treatment?

The first of the above questions only begs the question of how voting might follow the same path with a cap like the treatment now being given to favorites. Maybe there is lesser data focused on the order the votes are applied in but given enough time, I think we'd be right back to square one on this issue.

So now votes are capped and favorites are capped, what's the solution for user liked content, sets? Sets are already capped.

If votes do become capped then I don't yet see any other alternative aside from creating another account. There doesn't appear to be any rules on the books about having more than one account. So far this is the least desirable solution as I'd like to keep things contained to one account.

I'm still confounded as to how this whole thing is even an issue.

wat8548 said:
I've seen at least one person on here claim they used the favourites as a "seen" marker.

I've viewed this image so therefore I'll place it in my favorites list?

Wild. You do you I guess. :P

kiranoot said:

Favorite cap is indeed a performance thing. Specific users were getting so many favorites that it was interfering with database statistics generation and causing small site outages when they interacted with their favorites. The reason that favorites have a limit and voting doesn't, is because of the way votes are accessed compared to favorites. They are not pulled up publicly anywhere so the number of ways they can be accessed is quite small and controlled. Favorites get used a lot on the site, and the sorting information on them is important, but it isn't for votes(don't ask me for images sorted by vote date, please, I can't offer it unless I can do some major problem solving,) so there is a less controlled number of ways they are accessed.

One of the preliminary fixes for this was to move favorites partially into the new search system, but the new search system doesn't(and may not be able to?) support the additional information of when a favorite was added. This made doing searches for tags among people with lots of favorites go from being a constant maintenance headache, to almost instant and without cost, but didn't solve that favorites still are so visible that it's a problem when favorite list sizes get too big.

Sets are capped for sanity reasons to prevent them from getting too big and causing other problems. Pools cap might go up, but I don't know yet, there is a lot that goes into analyzing usage patterns and making sure that things can't simply break the site because it became too large.

Summary: Lots of technical nonsense involved in trying to make stuff work.

Thanks for the explanation. I neither need my favorites to be public nor ordered by fav order so it sounds like upvotes are the way to go for me (although I guess if ever lost my account somehow there would be no way to recover my upvote list.)

mdf said:
Would there be an option for users to bulk translate favorites into votes?

I second this. Given this new information I would like to be able to transfer my favorites into upvotes and then perhaps clear my favorites list entirely so I can still use that if I want to for certain posts.

I suppose it should be possible with the API but with my coding skills it would take me 300 years to figure out how to do it.

I'd love a way to mass cull my favorites list in general, perhaps a few options to cull anything that I faved more then 2 years ago? I currently have 80212 posts in my favorites, barely passed the mark before the new site update, so I'd really enjoy a way to translate faves into votes, as the above post suggests, or remove them en masse somehow.

I have Reached the Cap limit n i'm in total of 189k, do i wait for a new update or i'm stuck not favoring new post?

I'm almost at the fav cap, what do I do? Just make a new account after 10 years?

You could use sets, you got 75 and 10k posts per set.
Or use the upvote feature (no size limitation), but can't be displayed in order and is not accessible by other users.

Would it be possible to simply have favorites behave similar to upvotes after you reach 80,000 instead of capping them completely?

foxybomb said:
2. That pool post limit is something that concerns me on the front of comics like FvT and Silver Soul.

Why wouldnot you break those into chapters!? I can understand wanting to binge the comic, but containing the entire work in a single pool seems slightly inane to me. I have not the proper context for this as I read all of ShiroNeko’s work on thier FA page.

blackasnight said:
Why wouldnot you break those into chapters!? I can understand wanting to binge the comic, but containing the entire work in a single pool seems slightly inane to me. I have not the proper context for this as I read all of ShiroNeko’s work on thier FA page.

Victory Fire is nearly 3/4ths of the way there too (725 posts). There needs to be a good way to link multiple chapters together. If you're coming into such a comic late and you start at the beginning, once you get to the end of a chapter pool, it's not terribly easy to find the next. Parent/Child posts are probably the best option currently, but it's not exactly elegant (they're easy to overlook when expecting pool navigation links) and aren't supposed to be for that purpose.

watsit said:
There needs to be a good way to link multiple chapters together.

Pools can have a description with a list of links to all the chapters
eg: pool #6558

usbees said:
Pools can have a description with a list of links to all the chapters
eg: pool #6558

Still not he best since every chapter pool will need to have links added for every other chapter pool. All previous chapters would need their descriptions updated whenever a new chapter is added. And when reading through and reach the end of the chapter, that means you'll have to go to the current chapter's pool, then click to the next chapter's pool, then click the first entry, to get to the next page. It also won't necessarily be clear that way; you reach the end of a pool and ther's no more next>> links, so would that mean that's the last page available or do you need to look for the next chapter? It would be far better to have an easily noticeable link from the last page of a chapter to the first page of the next chapter.

foxybomb said:

2. That pool post limit is something that concerns me on the front of comics like FvT and Silver Soul.

Someone should probably prep the Silver Soul pool in particular for division by chapter, as it's at 928 posts.. dangerously close to that limit.

There used to be a rule against using e621 to host/mirror a long-running serial webcomic. What happened to that?

Help: Uploading Guidelines
Webcomics are allowed as long as not the entire comic is mirrored here, meaning only up to a maximum of 5 pages total.

magnuseffect said:
There used to be a rule against using e621 to host/mirror a long-running serial webcomic. What happened to that?

Help: Uploading Guidelines
Webcomics are allowed as long as not the entire comic is mirrored here, meaning only up to a maximum of 5 pages total.

We use webcomics as a very narrow definition of "has its own hosted page and is not distributed officially in another way". If someone posts a comic to their FA page it's perfectly fine to host here in its entirety. With actual web comics that are privately hosted we simply disallow excess pages to not steal their traffic, as the owner likely uses the traffic to off-set the costs of hosting the webcomic.

watsit said:
Still not he best since every chapter pool will need to have links added for every other chapter pool. All previous chapters would need their descriptions updated whenever a new chapter is added. And when reading through and reach the end of the chapter, that means you'll have to go to the current chapter's pool, then click to the next chapter's pool, then click the first entry, to get to the next page. It also won't necessarily be clear that way; you reach the end of a pool and ther's no more next>> links, so would that mean that's the last page available or do you need to look for the next chapter? It would be far better to have an easily noticeable link from the last page of a chapter to the first page of the next chapter.

A neat trick that I've seen in some multi-pool comics is to put the first page of one pool as the last page of the former.

notmenotyou said:

We use webcomics as a very narrow definition of "has its own hosted page and is not distributed officially in another way". If someone posts a comic to their FA page it's perfectly fine to host here in its entirety. With actual web comics that are privately hosted we simply disallow excess pages to not steal their traffic, as the owner likely uses the traffic to off-set the costs of hosting the webcomic.

Okay, that makes sense.
Is e621 more lenient in general on this now that it's more typical for a larger webcomic to rely on Patreon for funding? For example, out-of-placers is a traditionally-hosted webcomic but the only ad they run is their own Patreon link. I don't particularly want to see this one go, I'm just wondering if the guidelines are changing with that in mind.