Bug: A persistent NoMethodError when trying to create "char:chance_(stripes)" character tag on this post.

Expected behavior: Character tag creation.

Actual behavior: http://i.imgur.com/VSN7rnn.png

Steps to duplicate: Attempting to add this character tag, or in fact any new character tag at all.

Bug: Cannot add species (cat, feline) tags to this post.
Expected behaviour: Species tag added.

Steps to duplicate: Attempt to add species tags to post.

I'm starting to see a pattern here.

Jugofthat said:
I'm starting to see a pattern here.

Yeah. Artist creation is also affected.

Wiki comparison is still broken :/

undefined method `diff' for #<Array:0x9f745a0>

/home/e621/e621-production/release-2014-06-08/app/models/wiki_page.rb:76:in `diff'
/home/e621/e621-production/release-2014-06-08/app/controllers/wiki_controller.rb:171:in `diff'

{"to"=>"251",
 "title"=>"avoid_posting",
 "from"=>"249"}

{"Cache-Control"=>"no-cache",
 "Content-Type"=>"",
 "Set-Cookie"=>"blacklisted_tags=public_use&diaper&gore&dismemberment&disembowelment&amputation&inflation&urine&peeing&watersports&id%3A6268&feces&nezumi&hoihoi&mokanyann&id%3A233967&hyper_pregnancy; path=/\nblacklist_avatars=true; path=/\nblacklist_users=true; path=/"}

Char said:
That's probably due to all these tag aliases that he approved not too long ago: https://e621.net/mod_action?moderator=&body=invalid_tag&type=any

He tried to use our mass tag edit tool to clear all those out, but the jobs are stuck currently: https://e621.net/job_task

I've already alerted the devs about it. Once they finally prod the job queue to get it to run job tasks again, all those invalid_tags will disappear.

Nah, I got him to rerun it as a Resque task. Those job tasks just need to be purged at some point as far as I know.

Something has gone dreadfully wrong with the tagging system: http://e621.net/post/show/531179

EDIT: Nevermind, it's fixed.

Jatix said:
Yeah. Artist creation is also affected.

Jugofthat said:
I'm starting to see a pattern here.

DragonFox69 said:
Bug: Cannot add species (cat, feline) tags to this post.
Expected behaviour: Species tag added.

Actual behaviour

NoMethodError in PostController#update

undefined method downcase' for nil:NilClass RAILS_ROOT: /home/e621/e621-production/release-2014-06-08 Application Trace | Framework Trace | Full Trace /home/e621/e621-production/release-2014-06-08/app/models/tag.rb:73:in find_or_create_by_name'
/home/e621/e621-production/release-2014-06-08/app/models/post/tag_methods.rb:93:in commit_tags' /home/e621/e621-production/release-2014-06-08/app/models/post/tag_methods.rb:92:in map!'
/home/e621/e621-production/release-2014-06-08/app/models/post/tag_methods.rb:92:in commit_tags' /home/e621/e621-production/release-2014-06-08/app/controllers/post_controller.rb:230:in update'

Request

Parameters:

{"reason"=>"",
"post"=>{"parent_id"=>"",
"hide_google"=>false,
"rating"=>"Explicit",
"hide_anon"=>false,
"source"=>"http://d.facdn.net/art/honwell/1404872709.honwell_aeris.png",
"description"=>"",
"tags"=>"aeris_(vg_cats) breasts fur honwell looking_at_viewer nipples pussy sitting solo vg_cats species:cat species:feline"},
"id"=>"527943"}

Show session dump
Response

Headers:

{"Cache-Control"=>"no-cache",
"Set-Cookie"=>"blacklisted_tags=; path=/\nblacklist_avatars=true; path=/\nblacklist_users=false; path=/",
"Content-Type"=>""}

Steps to duplicate: Attempt to add species tags to post.

Jugofthat said:
Bug: A persistent NoMethodError when trying to create "char:chance_(stripes)" character tag on this post.

Expected behavior: Character tag creation.

Actual behavior: http://i.imgur.com/VSN7rnn.png

Steps to duplicate: Attempting to add this character tag, or in fact any new character tag at all.

My fault. I was making a change that made adding tag type to tags a bit more... non-surprising. (Adding a tag_type suffix to a tag that doesn't exist will make it infer that tag type now)

Problem is I did this at about 5 in the morning and forgot to test the case of using the old style.

It should be fixed now, though. I'm bright-eyed and bushy-tailed and did actual testing.

Pokelova said:
Something has gone dreadfully wrong with the tagging system: http://e621.net/post/show/531179

EDIT: Nevermind, it's fixed.

https://e621.net/post/show/531177/amethystlongcat-car-careature-chase_-general-comic

This one isn't. Strange.

edit: now it is.

spight said:
My fault. I was making a change that made adding tag type to tags a bit more... non-surprising. (Adding a tag_type suffix to a tag that doesn't exist will make it infer that tag type now)

Problem is I did this at about 5 in the morning and forgot to test the case of using the old style.

It should be fixed now, though. I'm bright-eyed and bushy-tailed and did actual testing.

Um, sounds alright. So does that mean both methods should work now?

Edit: Hmmm, it seems to add a _(character) suffix to every new character tag now, even ones that don't immediately need one because of a similar tag existing, or ones that already have a suffix to denote which person they belong to when there are multiple characters with that name, which is already enough to avoid conflicts.

Don't know if I'm very happy with that, as it'll easily make a tag so long that it takes up another line.

Jugofthat said:
Um, sounds alright. So does that mean both methods should work now?

Edit: Hmmm, it seems to add a _(character) suffix to every new character tag now, even ones that don't immediately need it or already have a suffix to denote which person they belong to. Don't know how if I'm very happy with that, as it'll easily make a tag so long that it takes up another line.

Yeah, kind of. You still can't edit an existing tag's type automatically by adding a suffix or by adding a prefix. Now people just won't be able to accidentally create "char_(artist)" as a general tag.

I haven't cleaned up the tags that have already become mangled like this, so it's possible to try to create "char_(artist)" and end up with "char_(artist)_(artist)" :(

Well, at least this explains why I couldn't get rid of Larynkir (character) (character) yesterday. I made that tag with char: and added a _(character) suffix to differentiate it from Larynkir's already existing artist tag, and then I got that monstrosity that just wouldn't go away.

Soooo... I just have to remove my own suffix there to make it look as it should, right. :P

But are you saying this weird behavior is getting fixed? Because I can definitely understand implementing auto-suffixes to make sure nobody goes around altering tag types on accident, but they certainly don't need to be generated every time a unique character tag is made. That's just redundant and visually clutterish.

If it could detect whether a tag someone's adding (with a prefix) actually overlaps with an existing tag of another type or if it doesn't, and then respond accordingly with either a necessary suffix or none, that would be splendid.

Jugofthat said:
Well, at least this explains why I couldn't get rid of Larynkir (character) (character) yesterday. I made that tag with char: and added a _(character) suffix to differentiate it from Larynkir's already existing artist tag, and then I got that monstrosity that just wouldn't go away.

Soooo... I just have to remove my own suffix there to make it look as it should, right. :P

But are you saying this weird behavior is getting fixed? Because I can definitely understand implementing auto-suffixes to make sure nobody goes around altering tag types on accident, but they certainly don't need to be generated every time a unique character tag is made. That's just redundant and visually clutterish.

If it could detect whether a tag someone's adding (with a prefix) actually overlaps with an existing tag of another type or if it doesn't, and then respond accordingly with either a necessary suffix or none, that would be splendid.

It "does" that.
https://e621.net/tag?name=Larynkir*&type=&order=count&show_empty_tags=1

Ehm, but how does that link prove that? I don't think I understand what you're getting at.

Because the only tags that were initially there are the artist tag and the "Larynkir(character)" tag with the spacing error. That one wasn't the result an auto-suffix (it's too old for that anyway), someone personally added that (character) bit.

I went and corrected that spacing error but initially forgot to add a prefix (hence the general tag), then added one and got the double (character) thing. The exact tag I entered was "char:larynkir_(character)", which is not the same as "char:larynkir". There's no conflict, no overlap.

So currently it clearly does not try to detect anything and instead just blindly throws "_(character)" onto whatever that's being entered with a "character:" prefix. And well, that can become a bit problematic if there's already a suffix for a variety of possible reasons. I don't necessarily mean the character suffix, we can simply learn to just not put it there anymore, but owner names for instance.

Jugofthat said:
Ehm, but how does that link prove that?

Because the only tags that were initially there are the artist tag and the "Larynkir(character)" tag with the spacing error. That one wasn't the result an auto-suffix (it's too old for that anyway), someone personally added that (character) bit.

I went and corrected that spacing error but initially forgot to add a prefix (hence the general tag), then added one and got the double (character) thing. The exact tag I made was "char:larynkir_(character)", which is not the same as "char:larynkir". There's no conflict overlap.

So currently it clearly does not try to detect anything and instead just blindly throws "_(character)" onto whatever that's being entered with a "character:" prefix. And well, that can become a bit problematic if there's already a suffix for various reasons.

No, it tries to find a tag that already exists with the given name. If no tag with the given name exists, it creates the tag with the given name and given type. If a tag exists with the given name (i.e. "laynkir_(character)" in this case), but without the proper type, it suffixes the additional _(character) and tries the process again.

The most recent fix I made solves for the underlying problem where you accidentally create a tag with a descriptive suffix but with no specified tag type otherwise.

If you want proof that it's not doing this blindly, go try to add a tag like "artist:thisdoesntexistanywhere" to a post.

spight said:
No, it tries to find a tag that already exists with the given name. If no tag with the given name exists, it creates the tag with the given name and given type. If a tag exists with the given name (i.e. "laynkir_(character)" in this case), but without the proper type, it suffixes the additional _(character) and tries the process again.

The most recent fix I made solves for the underlying problem where you accidentally create a tag with a descriptive suffix but with no specified tag type otherwise.

If you want proof that it's not doing this blindly, go try to add a tag like "artist:thisdoesntexistanywhere" to a post.

Your example seems to work (generating an artist tag without any automated suffix attached) But this does not: https://e621.net/post/show/234217
It has the existing "pumpkinhead_(character)" tag as a general tag. Frequent attempts (including a retry after your post and before this one to see if it works now) but adding "character:" to the existing "pumpkinhead_(character)" tag simply creates a second "pumpkinhead_(character)_(character)" tag, without removing the first. Resulting in an image with two wrong tags and no easy way to fix it. I think this is what Jugofthat is talking about. It flat out does not work.

ETA: Handled.

furrypickle said:
Your example seems to work (generating an artist tag without any automated suffix attached) But this does not: https://e621.net/post/show/234217
It has the existing "pumpkinhead_(character)" tag as a general tag. Frequent attempts (including a retry after your post and before this one to see if it works now) but adding "character:" to the existing "pumpkinhead_(character)" tag simply creates a second "pumpkinhead_(character)_(character)" tag, without removing the first. Resulting in an image with two wrong tags and no easy way to fix it. I think this is what Jugofthat is talking about. It flat out does not work.

It's not going to work right now. You need to change the tag type to character through the tag index if someone added a tag with the wrong type. The fix I pushed simply tries to prevent situations like this from happening in the future.

spight said:
No, it tries to find a tag that already exists with the given name. If no tag with the given name exists, it creates the tag with the given name and given type. If a tag exists with the given name (i.e. "laynkir_(character)" in this case), but without the proper type, it suffixes the additional _(character) and tries the process again.

The most recent fix I made solves for the underlying problem where you accidentally create a tag with a descriptive suffix but with no specified tag type otherwise.

If you want proof that it's not doing this blindly, go try to add a tag like "artist:thisdoesntexistanywhere" to a post.

Alright, so I tried that out here and suddenly encountered no problems whatsoever. Peculiar.

After adding the imaginary artist, I made a char:thisdoesnexistanywhere_(character) tag that showed up as a character tag without a second suffix. Then altered that into char:thisdoesntexistanywhere_(nobody) to simulate an owner name, and it again didn't put a _(character) after the suffix I already had put there.

That's all how it's supposed to be, so great.

Finally, I tested the new tag type fix at its core by entering "species:thisdoesntexistanywhere", and guess what, it created a "thisdoesntexistanywhere_(species)" tag in the species bracket while leaving the artist tag alone. So yes, that seems to work properly too.

It actually appears you're right, good job! But... now I don't understand why the system works the way I suggested on this post, yet bitches around with that double character suffix on that Larynkir post. =/

Something just hit me while typing that. I think it actually does this in response to my stupid, accidentally created general tag that's identical in content instead of the artist tag that has no suffix at all, and thus is very much different. Am... Am I onto something here? I think I just figured it out. *smacks forehead*

Jugofthat said:
The only thing I can think of now is that it actually does that in response to my stupid general tag, instead of the artist tag that has no suffix at all and thus is different. Am I onto something here?

That's right. When it fails to add the "larynkir" tag (because of the artist tag), it tries to add the "larynkir_(character)" tag, but fails because of the general tag.

I fixed this tag on both of the posts having issues by changing the larynkir_(character) tag to a character-type tag.

I don't know what kind of permissions it requires to be able to specifically change the tag type (a la the /tag/edit?name=larynkir page), but that's the only fix for affected tags right now.

Damn... Should've realized that earlier. :')

Oh well, at least I did. Then I guess that concludes my complaining for the moment, thank you.

Except for this: https://e621.net/post/show/531183

What do you suppose happened here? Is it a bug, or did the uploader enter Charmander twice, once with a species prefix and once with a character one? The character tag is obviously not needed there.

Jugofthat said:
Damn... Should've realized that earlier. :')

Oh well, at least I did. Then I guess that concludes my complaining for the moment.

Except for this: https://e621.net/post/show/531183

What do you suppose happened here? Is it a bug, or did the uploader enter Charmander twice, once with a species prefix and once with a character one? The character tag is obviously not needed there.

Obviously the code mistook "charmander" for "Char", the admin, which is a shortcut for character, rendering it a charmander_(character) tag.

That was a joke. Ha ha. Fat chance.

But really, the original uploader probably just included char:charmander

Probably just that, but I thought it was worth pointing out in case something weird's going on. :P

...

char:charmander

https://www.youtube.com/watch?v=fY_Bw2Kfrb0

Lately whenever I do the search "-female -rating:safe" I get hit with this screen:
http://i.imgur.com/I5nZ3Qc.png

Also pops up on a couple other searches, usually when trying to exclude a tag.

By the way, thanks for directing me to the tag type editor, I utterly didn't know that function even existed. I just fixed the Chance_(Stripes) tag, so it now shows up correctly as a character tag without weird double suffixes on that post. Seems you or someone else already did the same for the Larynkir one.

The galaxy is at peace.

spight said:
It's not going to work right now. You need to change the tag type to character through the tag index if someone added a tag with the wrong type. The fix I pushed simply tries to prevent situations like this from happening in the future.

So instances like that are just going to have to be cleaned up manually through the tag index edit function, but after the backlog is cleaned up, it should work fine from now on then? Ok. That's good to know.

By the way, when editing the tag type via the tag index, can you make it so that once the edit is completed it redirects you back to the page you were on (usually a search you used to find the tag in order to edit it) instead of redirecting you to the main tag index page (which is what it does now)? Because that would be more convenient to let you have to option to pick up where you left off instead of having to start all over or abuse the back button on your browser. -- Still an active bug/issue as of sept 17 2014.

Also, not the same thing, but this bug showed up: Some tags like this one https://e621.net/post/index/1/waffles_(artist)werewolf are not editable anymore. I can't remove it, change it, or edit it in any way to fix it. And I've run into a few like that since the changes last night/this morning, so it's just a bug, not a single tag. I think it's to do with them having a categorization suffix that now wants to generate an automatic categorization tag but is somehow making the tag act stuck in an "as is" position. So...not completely fixed yet. --Fixed! Thanks!

Ok, so I have no idea if this is a bug or what it is. All I know is that when I pressed enter to search, I got this log error report instead;

And that's what it displayed. All attempts to duplicate have failed, so I doubt it was actually a bug, I just really want to know what caused this since I have never seen a screen like this on this site before. I've seen similar text get generated when a program crashes in a certain way, minecraft for example, but I'm not sure how to read this. So I can't determine what caused it to appear. The URL displaye for the page is
https://e621.net/post?tags=female+rating%3Aexplicit+mlp+canine&searchDefault=Search
but that's a perfectly functional, normal URL to see when using the E621 (or most booru's) search systems. Can anyone make sense of what it says and tell me what went wrong? I'm rather curious.

EDIT: Ok, it just happened again. I used the same tags for this search as the first time it happened. The resulting error page is identical to the first. I carefully switched between the first and second pages to make sure. I have no idea what's causing it. I know it says at the top "canceling statement due to statement timeout", but my internet speed is perfectly fine. other websites load fine. so I really have no clue what could be causing it. Or if it's even something on the client end at all.

@pat180: No, that's server side. That timeout error happens when the server takes too long to produce results to your request. This can happen if the site's under heavy load. I bet that's the case here.

furrypickle said:
So instances like that are just going to have to be cleaned up manually through the tag index edit function, but after the backlog is cleaned up, it should work fine from now on then? Ok. That's good to know.

By the way, when editing the tag type via the tag index, can you make it so that once the edit is completed it redirects you back to the page you were on (usually a search you used to find the tag in order to edit it) instead of redirecting you to the main tag index page (which is what it does now)? Because that would be more convenient to let you have to option to pick up where you left off instead of having to start all over or abuse the back button on your browser.

Also, not the same thing, but this bug showed up: Some tags like this one https://e621.net/post/index/1/waffles_(artist)werewolf are not editable anymore. I can't remove it, change it, or edit it in any way to fix it. And I've run into a few like that since the changes last night/this morning, so it's just a bug, not a single tag. I think it's to do with them having a categorization suffix that now wants to generate an automatic categorization tag but is somehow making the tag act stuck in an "as is" position. So...not completely fixed yet.

That bug is amazing...

A) It's creating a new tag instead of removing a tag, and B) it's trying to infer the artist type and creating "waffles_(artist)werewolf_(artist)". which it then tries to remove...

Edit: I'm going to go ahead and manually (super manually, like DB directly) edit this post and look into the bugs tomorrow.

Bug
e621's Reverse Google Search uses a thumbnail

Expected behavior
When you click the Reverse Google Search link on a post, e621 should use
- the post's sample image, if the post is wider/taller than 800 pixels
- the full image, if the post isn't
(like the "Show image samples" account setting)

Actual behavior
e621 uses a thumbnail.
For post #530823 it uses
https://static1.e621.net/data/preview/bc/9b/bc9b5e45168489a6c2278072aa8a0a98.jpg

This is a problem because:
For post #530823, e621's Reverse Google Search doesn't find any sources.
But Search by Image for Google does, because it uses the image shown in the browser, instead of the thumbnail.

Steps to duplicate
See above.

furrypickle said:
So instances like that are just going to have to be cleaned up manually through the tag index edit function, but after the backlog is cleaned up, it should work fine from now on then? Ok. That's good to know.

By the way, when editing the tag type via the tag index, can you make it so that once the edit is completed it redirects you back to the page you were on (usually a search you used to find the tag in order to edit it) instead of redirecting you to the main tag index page (which is what it does now)? Because that would be more convenient to let you have to option to pick up where you left off instead of having to start all over or abuse the back button on your browser.

Also, not the same thing, but this bug showed up: Some tags like this one https://e621.net/post/index/1/waffles_(artist)werewolf are not editable anymore. I can't remove it, change it, or edit it in any way to fix it. And I've run into a few like that since the changes last night/this morning, so it's just a bug, not a single tag. I think it's to do with them having a categorization suffix that now wants to generate an automatic categorization tag but is somehow making the tag act stuck in an "as is" position. So...not completely fixed yet.

I pushed a fix that makes removing tags specifically search for the tag (instead of trying to create one if it doesn't exist), so this issue should be resolved.

Xch3l said:
Huh, I swear I replied to Savageorange... :/
It was something about that annoyance...

So, you're not using a computer then, right? Erm... I dunno how does that work...

I use a laptop too, but so far its just a bug on the kindle.

spight said:
I pushed a fix that makes removing tags specifically search for the tag (instead of trying to create one if it doesn't exist), so this issue should be resolved.

Excellent! I just tested one of the other instances I'd seen a "stuck" tag like that, and editing it worked flawlessly this time. Thank you! You got it fixed.

Hey, could you to look into this (editing tool which broke a few weeks back): http://i.imgur.com/jmoadkp.png Basic rundown: It's a handy little editing tool for tagging projects (and for basic members it's a lifesaver since tag scripting is priv+). You go into that specific editing mode, click the thumb of the image you want to edit, it opens the tag box within the same thumbs screen allowing you to quickly change or add a few tags, then click submit and ....it should make the edit changes, and then give a green notifications bar saying that the changes were saved. But it's currently broken, so when you click submit, the tag editing box goes away and then nothing happens. If you open the image in a new window, none of the edit changes will have been made. Basically it is unable to finish the tag edit.

I'm hoping it can be fixed pretty readily but that it just fell through the cracks. It broke the same time as the Tag Scripting tool did, but only tag scripting got fixed so far. I know it's not as flashy as tag scripting, but it's good for a different type of editing than tag scripting. And by using both tools, you can pretty much do every tag edit you need within the same thumbs screen. Tag Scripting is great for repeating the same type of tag change on several posts. The Edit Posts tool is great for the exceptions, when you need to add or change a few other tags on just that one picture. Which makes it really useful to have both tools working and able to switch between them as needed, especially on huge tagging projects. So just if you've got a moment. It'd be nice to be able to use that tagging tool again.

ETA: Fixed! Thank you so much to whoever fixed this! ILU-so-much-right-now!!!

I'm trying something new out with the way counts are handled on the backend. This should hopefully speed up results vastly.

The story behind this is that when you perform a search, two major processes happen:
A) You count the total number of posts you would match
B) You retrieve the requested results.

In most of the Statement Timeout exceptions we've been seeing, the problem revolves around the count method (because you have to count an extremely large number of posts, which means scanning the entire DB). B takes significantly less time (since you're only scanning until you find the number of posts requested).

Taking out and backgrounded the count process should speed up the searching searching portion in lieu of an exact pagination.

Please let me know if you have any issues or concerns about this change.

EDIT: OH GOD THERE ARE SO MANY BACKGROUNDED PROCESSES ;_:

spight said:
I'm trying something new out with the way counts are handled on the backend. This should hopefully speed up results vastly.

The story behind this is that when you perform a search, two major processes happen:
A) You count the total number of posts you would match
B) You retrieve the requested results.

In most of the Statement Timeout exceptions we've been seeing, the problem revolves around the count method (because you have to count an extremely large number of posts, which means scanning the entire DB). B takes significantly less time (since you're only scanning until you find the number of posts requested).

Taking out and backgrounded the count process should speed up the searching searching portion in lieu of an exact pagination.

Please let me know if you have any issues or concerns about this change.

EDIT: OH GOD THERE ARE SO MANY BACKGROUNDED PROCESSES ;_:

One thing I'm unclear on: does option B retrieve all of the results still, or just a percentage of the results that were requested? So if you search "male solo -boxers" would this new option still return all images with that tag combination, or would it now only return results matching those descriptors up to a certain capped off amount and leave any results after that amount out (so only returning a percentage of the images that match instead of all of them in order to speed searching)? As long as it's still retrieving all the images that match, it should be fine. But if it's only showing a lower percentage of the images that match the request, then that would cause problems. There's just a lot of reasons why people need it to find all the images with a particular combo of tags on them.

furrypickle said:
One thing I'm unclear on: does option B retrieve all of the results still, or just a percentage of the results that were requested? So if you search "male solo -boxers" would this new option still return all images with that tag combination, or would it now only return results matching those descriptors up to a certain capped off amount and leave any results after that amount out (so only returning a percentage of the images that match instead of all of them in order to speed searching)? As long as it's still retrieving all the images that match, it should be fine. But if it's only showing a lower percentage of the images that match the request, then that would cause problems. There's just a lot of reasons why people need it to find all the images with a particular combo of tags on them.

Erm.. I think there's some misunderstanding here. A) and B) weren't options. They're just what happens when you search for something.

You aren't very often given all of the results of a search anyway. They're just all counted.

This doesn't change anything regarding the actual posts you retrieve from the server, though.

spight said:
Erm.. I think there's some misunderstanding here. A) and B) weren't options. They're just what happens when you search for something.

You aren't very often given all of the results of a search anyway. They're just all counted.

This doesn't change anything regarding the actual posts you retrieve from the server, though.

Ah, ok. Yeah I read the "B takes significantly less time (since you're only scanning until you find the number of posts requested)" part wrong, but it makes more sense now. And since this doesn't change anything about the actual results a search retrieves from the server, then I guess that answers my concern handily. It also sounds like a a good change to make as the database gets bigger. Like growing pains for the site, but also very timely and sorely needed to make it run more efficiently. It sounds good.

furrypickle said:
Ah, ok. Yeah I read the "B takes significantly less time (since you're only scanning until you find the number of posts requested)" part wrong, but it makes more sense now. And since this doesn't change anything about the actual results a search retrieves from the server, then I guess that answers my concern handily. It also sounds like a a good change to make as the database gets bigger. Like growing pains for the site, but also very timely and sorely needed to make it run more efficiently. It sounds good.

Yeah. It's some low-hanging fruit in my overall goal to optimize the site's database usage. Unfortunately, I'm not sure this method will work very long since the background workers are struggling with the huge number of requests. =(

spight said:
Yeah. It's some low-hanging fruit in my overall goal to optimize the site's database usage. Unfortunately, I'm not sure this method will work very long since the background workers are struggling with the huge number of requests. =(

It's a big goal, but well worth it. I don't know anything about programming, but I do know some things about structures and patterns. And my guess is that e621 has been running long enough and had enough stuff stapled onto the old stuff over the years that it's like patches on top of patches on top of patches. So trying to optimise that without rebuilding some of it from the ground up...you'd have your work cut out for you. Even if you do have to overhaul some things, that type of stuff tends to pay off in the long term, because it reduces the tangles and incompatibles that you have to work around, especially when something needs troubleshooting (and something always needs troubleshooting). So hats off for even looking at that stuff, it's probably in sore need of a housecleaning at the least. And I like it when people think big. =)

furrypickle said:
It's a big goal, but well worth it. I don't know anything about programming, but I do know some things about structures and patterns. And my guess is that e621 has been running long enough and had enough stuff stapled onto the old stuff over the years that it's like patches on top of patches on top of patches. So trying to optimise that without rebuilding some of it from the ground up...you'd have your work cut out for you. Even if you do have to overhaul some things, that type of stuff tends to pay off in the long term, because it reduces the tangles and incompatibles that you have to work around, especially when something needs troubleshooting (and something always needs troubleshooting). So hats off for even looking at that stuff, it's probably in sore need of a housecleaning at the least. And I like it when people think big. =)

That pretty much sums up all of my goals on e621. :) I want to make sure that development in the future, which may or may not include me, is as easy as possible. I want people to go, "oh, this is easy to work with," when they look at my code instead of naming a horrible style of fuck-ups after me, a la all of the "patches on patches on patches" that I've seen in our codebase.

It's like finding that pair of old sneakers and its tied-up laces and trying to untangle the knots just for the sake of untangling them: the easiest way to fix it is to just pull it straight and see where its kinks are.

Also, that phrase applies to most furries.

Really, though, I want this site to be a powerhouse.

Edit: Sometimes the search works, so just add a random tag to the search and it will show the bug

spight said:

--------------------------------

Back to the cleanup for the categorization bug when it used to create double _(artist)_(artist) tags, I've noticed a few are glitched and refuse to be corrected. like this one here: https://e621.net/post/show/532035 If I remove the extra "_(artist) suffix from the tag, it removes all forms of that tag entirely. The tag history says it removed dnantti_(artist)_(artist) and "added" dnantti_(artist), but it for some reasons didn't show dnantti_(artist) in the actual tag list. Only the tag history said it should be there. And when trying to add "dnantti_(artist)" to the post to fix that, it comes back with "dnantti_(artist)_(artist)" again.

Most of these mistaken tags are fixable without any trouble, but there's a few that are acting like this, so I wanted to pass it on. Hopefully that can be fixed and then I can keep cleaning up the rest of 'em.

ETA:Seems to be fixed now. Don't know why it behaved that way earlier but someone seems to have gotten it to work now.
ETA2: Actually, I realised it probably wasn't fixed, just a workaround was applied. Both dnantti_(artist) and dnantti_(artist)_(artist) were removed and manually replaced with just plain "dnantti" as an artist tag. But now that tag categorization has been changed again, this may or may not react the same if it was tested today and may be a moot point now. So probably not a concern unless it resurfaces.

There's a bug where the categorization menu when editing via tag index seems to show the categories in randomized order. I can open six (currently general tags but with the artists suffix so need changed into artist tags) of them into new tabs to change, and on some "artist" will be the third option down, others it will be the fifth option down, others it will be the second from the top option. Basically it would be nice if it displayed them being listed in the same order every time just to reduce misclicks out of habit because they keep shuffling around.
-- Fixed and thanks! Though it does sometimes lag between when opening the dropdown menu and when it finally shows the category options in order, almost like it's taking the time to order them as you wait. But it's a minor thing. It's still worth having them display in the same order every time. Thanks.

i searched for the combination of tags female cum_in_ass internal the first page loaded normally but starting at page 2 it will say no posts match your search im not sure how far down the line this problem goes since i finnaly gave up at page 113 since having page 2-113 not working properly is kinda frustrating

dra-suzumebachi said:
i searched for the combination of tags female cum_in_ass internal the first page loaded normally but starting at page 2 it will say no posts match your search im not sure how far down the line this problem goes since i finnaly gave up at page 113 since having page 2-113 not working properly is kinda frustrating

dra-suzumebachi said:
i searched for the combination of tags female cum_in_ass internal the first page loaded normally but starting at page 2 it will say no posts match your search im not sure how far down the line this problem goes since i finnaly gave up at page 113 since having page 2-113 not working properly is kinda frustrating

That's a change I made. The longest part of a lot of page loads was pulling the count for the search. When the service can't immediately determine the count, it submits a background job to do so. Unfortunately, those backgrounded jobs are getting really backed up. :(

Would you prefer if pagination was disabled once you reached an empty page?

Maybe this is related to the bug mentioned above, but anyhoot!

Bug: XML Requests return a count of 10 posts regarless of the limit

Expected behavior: Actual count in the <posts> element

Actual behavior: Sometimes it returns the actual count (6420 in my case) or 10. It's rare the occurrence but it happens

Steps to duplicate: Take a look at, for example, the request my script makes (for my account, of course):

https://e621.net/post/index.xml?tags=fav%3Axch3l&limit=1

Xch3l said:
Maybe this is related to the bug mentioned above, but anyhoot!

Bug: XML Requests return a count of 10 posts regarless of the limit

Expected behavior: Actual count in the <posts> element

Actual behavior: Sometimes it returns the actual count (6420 in my case) or 10. It's rare the occurrence but it happens

Steps to duplicate: Take a look at, for example, the request my script makes (for my account, of course):

https://e621.net/post/index.xml?tags=fav%3Axch3l&limit=1

Yeah, that's related. Finding an exact count for a "complex" query that has a large number of results is actually really expensive. I'm playing around with that logic now. Thanks for letting me know your (very valid) concerns about programmatic access with json and xml. :)

Regarding all issues with the count of post searches being off, I just pushed a change that attempts to do a quick count (5 seconds) before deciding to background the job. Let me know if anything is happening poorly, or if everything's grand.

I re-implemented the ability to edit tags' types via the tag prefix when adding to posts. Now, however, it will give you a warning message any time you try to change a tag type you don't have permission to. This way there's far less confusion about the entire situation (which was my overall goal in the first place. :) )

I also tuned up some other common problems with adding tags to posts.

Edit: I think this will also "automatically" fix any wrongly-typed tags... so if there's anyone hoping to make their artist's name "herp_(general)", well... I don't think that's going to happen right now.

spight said:
I also tuned up some other common problems with adding tags to posts.

There's still some left. For instance, if you use caps while tagging (accidentally or not), it gets marked with black +, instead of normal green like it used to. Makes it harder to spot actual mistags, when the tag histories are so full of black marks.

Here's one example: https://e621.net/post_tag_history/index?post_id=531977

Seems blips can't be searched on for some names like this example. It should show their blips, but it doesn't.

https://e621.net/blip?name=Keith_A._Rosado

Others can be searched fine.

Genjar said:
There's still some left. For instance, if you use caps while tagging (accidentally or not), it gets marked with black +, instead of normal green like it used to. Makes it harder to spot actual mistags, when the tag histories are so full of black marks.

Here's one example: https://e621.net/post_tag_history/index?post_id=531977

Thanks for troubleshooting that and figuring out the cases when that happens. Looks like is tracking the historical before normalizing the tags.

When I have some spare cycles, I'll throw some effort at those. (Though, I'm notoriously unimpressed by post history.)

Not sure if this has been reported yet, but the 'Show Comments Below Threshold" seems to be unhiding blacklisted avatars.

SodaJerk72 said:
Not sure if this has been reported yet, but the 'Show Comments Below Threshold" seems to be unhiding blacklisted avatars.

I've created an issue for this. Thank you for reporting it.

Using the API, non-existant posts does not return an API-conformat response: https://e621.net/post/show.xml?id=1

Lizardite said:
Using the API, non-existant posts does not return an API-conformat response: https://e621.net/post/show.xml?id=1[/quote]

Indeed.
Try using the /index instead. My application isn't using the /show request at all xD

"https://e621.net/post/index.xml?tags=id:" + imageID

This gets me a valid response:

<posts count="0" offset="0"></posts>

I am currently just looking for a <post> tag, and failing gracefully if it isn't found, but it's sorta of a hack.

I can't help but notice that no matter what, if you're logged in or not, you can't put more than 6 tags in the tag bar. I can't tell if this is a bug or not because I can't find it in the Change logs... so... yeah.

JaceTheHybrid said:
I can't help but notice that no matter what, if you're logged in or not, you can't put more than 6 tags in the tag bar. I can't tell if this is a bug or not because I can't find it in the Change logs... so... yeah.

The tag limit is level based https://e621.net/help/users

spight said:
Regarding all issues with the count of post searches being off, I just pushed a change that attempts to do a quick count (5 seconds) before deciding to background the job. Let me know if anything is happening poorly, or if everything's grand.

Would it be possible to not include the count or maybe 0 instead of a random number? With count=0, it is possible to compare the count with the actual number of posts found and determine whether the count is right or if it was sent to the background, as long as you are in the first page.

Edit: In fact, setting count as limit*(page-1) + posts_in_page - 1 lets you check this in any valid page. Replacing "- 1" by "+ 1" if posts_in_page==0 would make it event more accurate.

I tried to hide one of my redundant forum posts and I was returned to my account page with the message "Error: You are already logged in".

rebane said:
The tag limit is level based https://e621.net/help/users

Ah. thanks. I didn't even know that happened! when did it occur exactly?... and why did it happen. cause now I'm confused.

JaceTheHybrid said:
Ah. thanks. I didn't even know that happened! when did it occur exactly?... and why did it happen. cause now I'm confused.

I'm pretty sure it's been that way for years, maybe since the site was set up. As for why, I suspect it may be to keep the load on the server from getting too crazy while running a search, but I'm not sure.

I do wish it would be raised by maybe two tags per level (so members could search 8 tags, priv could search 10 tags, etc) because there's just so many times where you need just one or two more slots. But it would still keep it under a limit for the server's benefit. However, I don't know if that idea will ever be implemented.

In any case, there are a few creative workarounds to maximise the limited tag search number:

• If a tag or two are both implicated to a bigger umbrella tag, then you can use that one tag in the search instead of the two more specific tags. So instead of both -herm AND -dickgirl, you could do -intersex to use a common example.
• You can also use your blacklist as a temporary workaround, using it to hide the tags that you'd be wanting the search to omit, allowing you to use that search slot for something else. Obviously that's a workaround, so it's not ideal or anything. But it can be useful when you just need one more slot or two.

There may be other tips and tricks but those are just the ones I know of. They can really help sometimes.

furrypickle said:
You can also use your blacklist as a temporary workaround, using it to hide the tags that you'd be wanting the search to omit, allowing you to use that search slot for something else.

I'll need to remember this. I always seem to need just one more tag.

furrypickle said:
I'm pretty sure it's been that way for years, maybe since the site was set up. As for why, I suspect it may be to keep the load on the server from getting too crazy while running a search, but I'm not sure.

I do wish it would be raised by maybe two tags per level (so members could search 8 tags, priv could search 10 tags, etc) because there's just so many times where you need just one or two more slots. But it would still keep it under a limit for the server's benefit. However, I don't know if that idea will ever be implemented.

In any case, there are a few creative workarounds to maximise the limited tag search number:

• If a tag or two are both implicated to a bigger umbrella tag, then you can use that one tag in the search instead of the two more specific tags. So instead of both -herm AND -dickgirl, you could do -intersex to use a common example.
• You can also use your blacklist as a temporary workaround, using it to hide the tags that you'd be wanting the search to omit, allowing you to use that search slot for something else. Obviously that's a workaround, so it's not ideal or anything. But it can be useful when you just need one more slot or two.

There may be other tips and tricks but those are just the ones I know of. They can really help sometimes.

Thank you as well, this tip has helped me well... though the black list one is not going to be used by me, I am happy a fellow E621 member is looking out for the people who don't know just what the absolute *explitive expunged* is going on. Cheers to you, good sir...s... sirs... or madams... or both... GENDERS ARE HARD.

I can't check my own comments or search using the User Listing.
Both options only loads for about a minute before either giving me the Cloudflare E621 is down screen, or the "ActiveRecord::StatementInvalid". Been like this for a few weeks now.

Hey, this is my first time posting on the forums, I hope this is the right place to post this bug I just came across.

All I did was click an image from page 1 of the index and open it in a new tab, instead of coming up normally I got this:

http://i.imgur.com/oPniSUi.jpg

If you need any other information, I still have the page up. Cheers!

Neak said:
All I did was click an image from page 1 of the index and open it in a new tab, instead of coming up normally I got this:

http://i.imgur.com/oPniSUi.jpg

That issue is very common these days.

Neak said:
Hey, this is my first time posting on the forums, I hope this is the right place to post this bug I just came across.

All I did was click an image from page 1 of the index and open it in a new tab, instead of coming up normally I got this:

http://i.imgur.com/oPniSUi.jpg

If you need any other information, I still have the page up. Cheers!

Timeouts are thrown when the database storing tags and image metadata is too busy and the server aborts the operation.

Neak said:
Hey, this is my first time posting on the forums, I hope this is the right place to post this bug I just came across.

All I did was click an image from page 1 of the index and open it in a new tab, instead of coming up normally I got this:

http://i.imgur.com/oPniSUi.jpg

If you need any other information, I still have the page up. Cheers!

Those are pretty common lately. We're told they're working on it, but a lot of it is linked with inefficient code that's becoming strained now that the site has gotten so big. So fixing it isn't easy or quick. (I could be wrong, but that was the impression I got.) The good news is that they don't happen quite as consistently as they used to because they've been able to improve some things, but the problem itself isn't gone yet. It's a situation in process.

On a practical note, you probably don't need to keep the page up, that screenshot should tell them what they need to know. But it was good to let them know about it.

In future, refreshing will often get it to load eventually. Or if errors are persistent with a certain page, then trying back later when the site may be a little less busy sometimes works. That's what most people end up doing: mostly refreshing, but sometimes trying back later if a page or section is being particularly stubborn. Not ideal, but it's growing pains while the devs work under the hood for a more long term solution. Or at least, I think that's what's happening.

Alrighty, thanks y'all. It's actually the first time I've ever received that error, so things hopefully aren't too awful on the backend. Best of luck on clearing up the coding and issues, thanks for the prompt reply. c:

And now the wiki search is broken.

Steps to reproduce: Go to Wiki, try entering anything into the search.

Genjar said:
And now the wiki search is broken.

NoMethodError in Wiki#index

Showing app/views/wiki/index.html.erb where line #59 raised:

undefined method name' for nil:NilClass Extracted source (around line #59): 56: 57: <td> 58: <span style="cursor:help;" title="<%= page.created_at.strftime("%b %d, %Y %I:%M %p") %>"><%= time_ago_in_words(page.created_at) %> ago</span>&nbsp; 59: <span class="date" style="cursor:default; font-size:85%;">by <%= link_to WikiPage.find_page(page.title, 1).user.name, :controller => "user", :action => "show", :id => page.user.id %></span> 60: </td> 61: 62: <td><%= page.version > 1 ? link_to(page.version-1, :action => "history", :title => page.title) : "" %></td> RAILS_ROOT: /home/e621/e621-production/release-2014-06-08 Application Trace | Framework Trace | Full Trace /home/e621/e621-production/release-2014-06-08/app/views/wiki/index.html.erb:59:in _run_erb_app47views47wiki47index46html46erb'
/home/e621/e621-production/release-2014-06-08/app/views/wiki/index.html.erb:48:in each' /home/e621/e621-production/release-2014-06-08/app/views/wiki/index.html.erb:48:in _run_erb_app47views47wiki47index46html46erb'
/home/e621/e621-production/release-2014-06-08/app/controllers/application_controller.rb:142:in respond_to_list' /home/e621/e621-production/release-2014-06-08/app/controllers/wiki_controller.rb:30:in index'
Request

Parameters:

{"query"=>"test"}
Show session dump

Steps to reproduce: Go to Wiki, try entering anything into the search.

Ran into that yesterday as well, but Genjar beat me to the bug report

Group_sex implicates group. However, there seem to be a few images with the group_sex tag and not the group tag. Whenever I try to fix this, I get the "Post updated" message and nothing changes.

Kämpfer said:
Group_sex implicates group. However, there seem to be a few images with the group_sex tag and not the group tag. Whenever I try to fix this, I get the "Post updated" message and nothing changes.

Yeah, tried it as well. You can temporarily fix it by removing the group_sex tag, saving the changes and adding it again. I did it for one of them.

Safari 8 on Mac OS X still isn't working. Still getting the NSPOSIXErrorDomain:100 when trying to access the site.

I can only guess it has something to do with the force forwarding to https. No other site is giving me an error message. Only e621.net.