Topic: (OLD) The Bug Report Thread

Posted under Site Bug Reports & Feature Requests

This topic has been locked.

savageorange said:
Have you tried visiting the url I linked (and reloading it)? It would actually be rather insane if only some people got a 404, since 404 implies the file doesn't exist at all.

https://e621.net/images/deleted-preview.png --this link gives me a "404 - Nobody here but us chickens! The page cannot be found. Either you made a typo in the URL or someone gave you a bad link" page. I don't pretend to know why, but just in case that helps narrow down the problem.

I also flipped over to my member account to test this (because otherwise I wouldn't be shown the 'deleted' thumbnail). And yes, searching status:deleted on my member account just gives me a page full of thumbs with the broken image icon. So the same variant of the problem that savageorange is talking about. Browser info here. Also, I don't know much about computer coding etc, but is it possible the reason parasprite is able to get the normal "deleted thumb" is if it's pulling it from their cache/browser temp files from when the thumbnail was working fine? But that the direct url to the deleted thumb doesn't work currently because the actual file's been moved or something since then? If that's impossible, then ignore that. It's not something I know very much about.

Updated by anonymous

savageorange said:
^ Granberia's screenshot is accurate for me too, aside from the theming difference.

My browser is Firefox 33.0 on Arch Linux x86_64.
Testing in Chromium, it's broken in a slightly different way: instead of tags, you see the 'broken image' icon. ( http://i.imgur.com/6kJqMPf.png )
Midori (another Gecko based browser) is similar to Chromium, just with a different 'broken image' icon.

Have you tried visiting the url I linked (and reloading it)? It would actually be rather insane if only some people got a 404, since 404 implies the file doesn't exist at all.

Yup, can't reproduce.

I've tried it on Firefox 33 for both OS X and Windows 8.1, Chrome 38 OS X, Safari 8 on both iOS and OS X, IE 11 on Windows 8.1 and an iOS app called Photon (which allows you to play Flash content through something not unlike a glorified video stream). I disabled javascript and the cache (through developer tools) on each of them (except Photon and IE)

The only one that I could reproduce this issue on was Photon, which according to aboutmybrowser.com is running Chrome 23 or Chrome 30 on Windows. Unfortunately it's also the only one I can't look at with developer tools. :/

The file is definitely there. The only thing I can think of is it's accessing the closest server to you guys, which happens to not have the file for some reason (Photon uses the IP address of...well wherever the stream comes from). But beyond that I have no leads.

Updated by anonymous

That could probably be because the image's url is wrong, because the image at https://e621.net/images/deleted-preview.png does exist.

I've seen the url without the "/images" part, so that might be the issue. Check it on your browser's developer tools by right-clicking on any image then 'Inspect element' and checking the hightlighted item. It should be in the form of

<img id="i[Post ID]" class="preview deleted" src="/images/deleted-preview.png" alt="[Tags]" title="[Tags, again]" width="150" height="150"> 

(notice the src part)

Edit: Btw, I'm testing this over e926 on my phone (yep, OCSP/authentication error)

Updated by anonymous

Xch3l said:
That could probably be because the image's url is wrong, because the image at https://e621.net/images/deleted-preview.png does exist.

I've seen the url without the "/images" part, so that might be the issue. Check it on your browser's developer tools by right-clicking on any image then 'Inspect element' and checking the hightlighted item. It should be in the form of

<img id="i[Post ID]" class="preview deleted" src="/images/deleted-preview.png" alt="[Tags]" title="[Tags, again]" width="150" height="150"> 

(notice the src part)

Edit: Btw, I'm testing this over e926 on my phone (yep, OCSP/authentication error)

src attribute matches what you specify. I looked at the url you specify -- it is a 404 page for me. Naturally, since it's the exact same url I specified, which was a 404 page. Verified in Firefox, Midori, elinks, and even wget.

I'm currently suspecting that it's a problem with the CDN. But I'm not sure whether 'one-of-a-kind' files like that are even on the CDN, rather than on a fixed server.

Updated by anonymous

furrypickle said:
https://e621.net/images/deleted-preview.png --this link gives me a "404 - Nobody here but us chickens! The page cannot be found. Either you made a typo in the URL or someone gave you a bad link" page. I don't pretend to know why, but just in case that helps narrow down the problem.

I also flipped over to my member account to test this (because otherwise I wouldn't be shown the 'deleted' thumbnail). And yes, searching status:deleted on my member account just gives me a page full of thumbs with the broken image icon.

I've tested both logged in and logged out, they are the same visually -- either the list of tags or a broken image icon.

So the same variant of the problem that savageorange is talking about. Browser info here. Also, I don't know much about computer coding etc, but is it possible the reason parasprite is able to get the normal "deleted thumb" is if it's pulling it from their cache/browser temp files from when the thumbnail was working fine? But that the direct url to the deleted thumb doesn't work currently because the actual file's been moved or something since then? If that's impossible, then ignore that. It's not something I know very much about.

No, that is possible. I'm pretty sure that's why I didn't get the broken display until i Ctrl+F5ed (that reloads all parts of the page, ignoring cached data).

Updated by anonymous

savageorange said:
src attribute matches what you specify. I looked at the url you specify -- it is a 404 page for me. Naturally, since it's the exact same url I specified, which was a 404 page. Verified in Firefox, Midori, elinks, and even wget.

I'm currently suspecting that it's a problem with the CDN. But I'm not sure whether 'one-of-a-kind' files like that are even on the CDN, rather than on a fixed server.

Huh, I can see it at that url... I'll have to clear phone's cache

I'm testing this on Opera Classic and Android's default, btw

Edit: It does exist. Cleared cache and tried again with both browsers, ES Downloader and a custom downloader too and all loaded the image...

Updated by anonymous

I'm pretty convinced it's CloudFlare, by this point (ie. it exists on some servers of the CDN but doesn't on one or more particular others). If they divide it up by geographical location, then I might as well mention I'm in Australia. Hopefully Granberia is also.

Updated by anonymous

savageorange said:
I'm pretty convinced it's CloudFlare, by this point (ie. it exists on some servers of the CDN but doesn't on one or more particular others). If they divide it up by geographical location, then I might as well mention I'm in Australia. Hopefully Granberia is also.

I'm USA. So if you're Australia, then that must mean it's more than one server that's borked it. Hopefully Tony and/or Spight can use the information in this thread though to follow up with cloudflare and get them to fix it.

Updated by anonymous

parasprite said:
Woohoo, I'm not special anymore

I think the changes got rolled out to each of the servers slowly or something.

lol, dangit! I would have rathered the change had gone the other direction...Ah well, at least it's consistent now. More information is usually a good thing when something needs troubleshooted. Hopefully it'll help in some way while they work on solving it. =/

Updated by anonymous

Bug
Can't search for artist URL's that contain escape sequences

Expected behavior
This artist's Furaffinity URL
https://e621.net/artist/show?name=koh
contains the characters [ and ]
(i.e. the URL contains un-escaped characters)

When you copy the URL in Firefox (and probably other browsers), it is turned into:
http://www.furaffinity.net/user/%5Bkoh%5D/
(i.e. the URL contains escaped characters)

When you search for this URL in
https://e621.net/artist/index?order=updated
e621 should find the artist.

Actual behavior
e621 does not find anything.

I haven't tested if the reverse works (an artist URL contains escaped characters, and you search for it using un-escaped characters).

Steps to duplicate
See above.

Updated by anonymous

Bug

Can't remove tag. (see below)

Steps to reproduce

1. Find a post at random.
2. Put a hyphen "-" in the begining of the text box and hit space.
3. Hit "Save changes"
4. Voila! blank tag

There's no way of deleting it that I can tell (as a user of course).

Updated by anonymous

Bug: Markup inside "url text":\http//www.google.com does weird things to the sanitizer.

Expected behavior: It disregards markup or parses it as it would outside of a url.

Actual Behavior

1. "[b][/b]":http://www.google.com
2. "[b]Hand[/b]":http://www.google.com 
3. "[i]Hand[/i]":http://www.google.com 
4. "[s]Hand[/s]":http://www.google.com 
5. "[o]Hand[/o]":http://www.google.com 
6. "[u]Hand[/u]":http://www.google.com
7. "[spoiler]Hand[/spoiler]":http://www.google.com 
8. "[sup]Hand[/sup]":http://www.google.com 
9. "[sub]Hand[/sub]":http://www.google.com 
10. "[sup][/sup]":http://www.google.com 
11. "[u][b][o][u]Hand[/o][/u][/u][/b]":http://www.google.com - lol

1.
2. Hand
3. Hand
4. Hand
5. [o]Hand[/o]
6. Hand
7. [spoiler]Hand[/spoiler]
8. Hand
9. Hand
10.
11. >>>[o]>>Hand[/o]>>[/u]>> - lol

Also whatever this is (probably doesn't matter):

http://\[

http://\[

Updated by anonymous

Munkelzahn said:
I haven't tested if the reverse works (an artist URL contains escaped characters, and you search for it using un-escaped characters).

Entering
http://www.furaffinity.net/user/[koh]/
(no escape codes)
in the URL field works for me.
I can reproduce the copy link behaviour with Firefox. However, you can get around it by instead highlighting the link text and copying that.

Updated by anonymous

For some reason trying to read forum #143880 was giving me following error:

PGError: ERROR: canceling statement due to statement timeout
: UPDATE "users" SET "last_forum_topic_read_at" = '2014-11-21 22:00:47.069347' WHERE "id" = 16311

Error was gone when I marked all forum posts as read and then tried to open it. BTW Mark all read tab is working really slowly recently.

Updated by anonymous

[b]Bug: Pages load slow with "Waiting for Available Socket" message[/b]

[b]Expected behavior: Pages to load fast[/b] 

[b]Actual behavior:Pages load slow and Chrome says "Waiting for available socket" [/b] 

[b]Steps to duplicate: Type in a tag to search with a lot of results, preview page takes forever to load.[/b]

I did a quick search of the error "Waiting for available sockets" didn't turn up any posts in the forum so I'm posting this here assuming it hasn't been addressed yet. My system is Windows 7 x64 with 8gb of memory, a cable connection that's upwards of 50mb/s download, using the latest version of Chrome and only this page takes forever to download and gives me the "Waiting for available sockets" error.

Updated by anonymous

Roseroar said:
I did a quick search of the error "Waiting for available sockets" didn't turn up any posts in the forum so I'm posting this here assuming it hasn't been addressed yet. My system is Windows 7 x64 with 8gb of memory, a cable connection that's upwards of 50mb/s download, using the latest version of Chrome and only this page takes forever to download and gives me the "Waiting for available sockets" error.

It's probably your browser. Have you tried clearing your cache, checking your connection or other programs not hogging your available bandwidth?

Updated by anonymous

Roseroar said:

[b]Bug: Pages load slow with "Waiting for Available Socket" message[/b]

[b]Expected behavior: Pages to load fast[/b] 

[b]Actual behavior:Pages load slow and Chrome says "Waiting for available socket" [/b] 

[b]Steps to duplicate: Type in a tag to search with a lot of results, preview page takes forever to load.[/b]

I did a quick search of the error "Waiting for available sockets" didn't turn up any posts in the forum so I'm posting this here assuming it hasn't been addressed yet. My system is Windows 7 x64 with 8gb of memory, a cable connection that's upwards of 50mb/s download, using the latest version of Chrome and only this page takes forever to download and gives me the "Waiting for available sockets" error.

I have no idea if this will help (because I don't have the issue), but try going to chrome://net-internals/#sockets and click "Flush socket pools". It may be temporary or do nothing depending on if it's the server or whatever your particular setup is. But it's harmless and worth a try.

Updated by anonymous

Bug: Webms aren't looping.

Expected behavior: When the webm reaches its end, it automatically loops.

Actual behavior: When the webm reaches the end, it stops. Attempting to rewind or pause and continue from the start results in a neverending load screen.

Steps to duplicate: View any webm Actually it appears to be only certain webms, such as post #562422.

Updated by anonymous

Furrin_Gok said:
Bug: Webms aren't looping.

Expected behavior: When the webm reaches its end, it automatically loops.

Actual behavior: When the webm reaches the end, it stops. Attempting to rewind or pause and continue from the start results in a neverending load screen.

Steps to duplicate: View any webm Actually it appears to be only certain webms, such as post #562422.

It works fine in Chrome. I think this may be a Firefox bug, but I don't know enough about how it's implemented to add much other than that.

Updated by anonymous

Implication (and probably alias) search is bugged.

Expected behavior:
This url (implied to = digimon) should show the list of tags that imply digimon tag.

Actual behavior:
It shows both correct results (like renamon -> digimon) and things that are implied by digimon tag (like digimon -> bandai)

Updated by anonymous

Can't browse while logged in

Expected behaviour:
Should be able to browse with tags, etc. while logged in.

Actual behaviour:
Unable to browse unless logged out, but can only view pictures in post while logged in.

Not sure I can explain it, or if it's just me, just hoping for some answers...

Updated by anonymous

DanDaMan97xx said:

Can't browse while logged in

Expected behaviour:
Should be able to browse with tags, etc. while logged in.

Actual behaviour:
Unable to browse unless logged out, but can only view pictures in post while logged in.

Not sure I can explain it, or if it's just me, just hoping for some answers...

I'm not exactly sure. Can you tell me what you are looking at/take a screenshot (imgur.com). Have you tried on a different computer? Different browser?

Updated by anonymous

parasprite said:
I'm not exactly sure. Can you tell me what you are looking at/take a screenshot (imgur.com). Have you tried on a different computer? Different browser?

I'm on Chrome for iPad, but I can take a shot with Safari...

http://imgur.com/fAlu941
My view if I go to posts

http://imgur.com/EowtA5p
If I use tags (butt in this instance)

*problem is same on Safari

Updated by anonymous

Granberia said:
Implication (and probably alias) search is bugged.

Expected behavior:
This url (implied to = digimon) should show the list of tags that imply digimon tag.

Actual behavior:
It shows both correct results (like renamon -> digimon) and things that are implied by digimon tag (like digimon -> bandai)

For the record, I'm actually glad it works like that. Because when you're processing implications, you often need to know all implications that are both coming and going from the tag you're handling at the moment. Having to search both coming and going separately wouldn't be nearly as helpful and it would be a lot easier to miss things that are messy to fix after the fact if changed in the wrong order. Same with aliases. It's just helpful on the processing end of things to have both the to and the from results showing up in the same search.

But I can see the point Granberia's making. And so if the devs really want to fix it, then I'd just request they also add a search function at the same time that intentionally enables you to search for both to and from that tag at the same time. Maybe a ticky box would work. Because on the processing end of things, it really helps to be able to search for both ways tags are linked to each other at the same time and I'd hate to lose that functionality (even it was originally because of a bug, it is useful to be able to search that way).

Updated by anonymous

furrypickle said:
For the record, I'm actually glad it works like that. Because when you're processing implications, you often need to know all implications that are both coming and going from the tag you're handling at the moment. Having to search both coming and going separately wouldn't be nearly as helpful and it would be a lot easier to miss things that are messy to fix after the fact if changed in the wrong order. Same with aliases. It's just helpful on the processing end of things to have both the to and the from results showing up in the same search.

But I can see the point Granberia's making. And so if the devs really want to fix it, then I'd just request they also add a search function at the same time that intentionally enables you to search for both to and from that tag at the same time. Maybe a ticky box would work. Because on the processing end of things, it really helps to be able to search for both ways tags are linked to each other at the same time and I'd hate to lose that functionality (even it was originally because of a bug, it is useful to be able to search that way).

Yeah, I'll admit that ever since Granberia mentioned it I've been abusing this bug like crazy.

Updated by anonymous

furrypickle said:
For the record, I'm actually glad it works like that. Because when you're processing implications, you often need to know all implications that are both coming and going from the tag you're handling at the moment. Having to search both coming and going separately wouldn't be nearly as helpful and it would be a lot easier to miss things that are messy to fix after the fact if changed in the wrong order. Same with aliases. It's just helpful on the processing end of things to have both the to and the from results showing up in the same search.

But I can see the point Granberia's making. And so if the devs really want to fix it, then I'd just request they also add a search function at the same time that intentionally enables you to search for both to and from that tag at the same time. Maybe a ticky box would work. Because on the processing end of things, it really helps to be able to search for both ways tags are linked to each other at the same time and I'd hate to lose that functionality (even it was originally because of a bug, it is useful to be able to search that way).

It might be a little hackish, but to me it makes sense that if you enter the same tag in 'tag' and 'implied to', you should get results for both. Because obviously, implicating a tag to itself is nonsense.

This is in fact how it currently works ; so I'm suggesting fixing the behaviour granberia described for 'implied to' but using it in the case that both fields match.

Updated by anonymous

parasprite said:
(very minor bug) I've seen this before, but not with this high of a post count.

Bug: post #562610 has legend_of_zelda as a tag. However, it's already been aliased to the_legend_of_zelda.

Expected behavior: The tag disappears from all posts.

I actually know this one! That happens because aliases are processed first, and then implications are processed after. So if an implication re-adds an aliased away tag, the system is unable to fix itself. Which is why implications technically need to be moved over when an alias is made to prevent this from happening. But now and then one gets missed, and that's when it behaves like this. In this case wind_waker was still implicated to legend_of_zelda instead of the_legend_of_zelda so when the implication was processed on a post after a tag edit, then the other tag was being added back on.

But I fixed that one. Instances like this are a little bit hard to find but easy to fix. So if you know of any others, you can dmail me and I'll add it to my list of tags to fix.

Updated by anonymous

furrypickle said:
I actually know this one! That happens because aliases are processed first, and then implications are processed after. So if an implication re-adds an aliased away tag, the system is unable to fix itself. Which is why implications technically need to be moved over when an alias is made to prevent this from happening. But now and then one gets missed, and that's when it behaves like this. In this case wind_waker was still implicated to legend_of_zelda instead of the_legend_of_zelda so when the implication was processed on a post after a tag edit, then the other tag was being added back on.

But I fixed that one. Instances like this are a little bit hard to find but easy to fix. So if you know of any others, you can dmail me and I'll add it to my list of tags to fix.

Oh, neat. Alright I'll start keeping track of them then.

Updated by anonymous

furrypickle said:
I actually know this one! That happens because aliases are processed first, and then implications are processed after. So if an implication re-adds an aliased away tag, the system is unable to fix itself. Which is why implications technically need to be moved over when an alias is made to prevent this from happening. But now and then one gets missed, and that's when it behaves like this. In this case wind_waker was still implicated to legend_of_zelda instead of the_legend_of_zelda so when the implication was processed on a post after a tag edit, then the other tag was being added back on.

But I fixed that one. Instances like this are a little bit hard to find but easy to fix. So if you know of any others, you can dmail me and I'll add it to my list of tags to fix.

This seems like something that should be automatically fixable -- or at least automatically detectable. Like

select T.name from alias as A
     join implication as I on A.tag_id=I.implied_tag_id 
     join tag as T on T.id=A.tag_id

, off the top of my head, with a rough guess at E621's database schema.

Updated by anonymous

Bug: combined numerical and negated favorite search gives a stack trace/error page
Expected behavior: giving the expected results page
Actual behavior: an error/stack trace page with the heading ActiveRecord::StatementInvalid in PostController#index
Steps to duplicate: make a search using a numerical option (score, favcount, id) along with a negated favorite (ie -fav:user), example: https://e621.net/post/index/1/score:0%20-fav:foobar

Updated by anonymous

Bug: In some cases adding -voted:name makes search empty for no reason.
Expected behavior:
source:pixiv cub order:score -pokemon -voted:Granberia should result in at least one post displayed

Actual behavior:
"No posts matched your search." No I haven't voted every post on source:pixiv cub order:score -pokemon search (which displays normally). In fact source:pixiv cub order:score -pokemon -voted:Barbados gives empty list either.

Curiously source:pixiv cub order:score -pokemon voted:Granberia works okay. It shows only pics I've voted.

Updated by anonymous

Granberia said:
Bug: In some cases adding -voted:name makes search empty for no reason.

There's already a fix ready for that in the next update.

Updated by anonymous

Bug:Forum quote function mangles Unicode characters with values > 0xffff.
For values > 0xffff, only the top 16 bits are used -- eg. if you enter character 𐄗 (10117), after quoting it becomes ė (0117). Characters with values <= 0xffff are preserved as-is
Expected behaviour:All UTF-8 characters are correctly preserved just as they were in the post you quote.
Other comments:

  • We've been exploring this problem in this forum thread ; you can see some of the confusion that has resulted from this behaviour.
  • It may effect other quoting functions, like post comments.
  • you can work around this by removing the contents of the quote block and manually copy+pasting from the post in question.

Updated by anonymous

suddenly im getting invalid certificate notifications and all thumpnails/pictures are replaced with their tags. this happened out of nowhere while browsing

Updated by anonymous

Languedoc said:
suddenly im getting invalid certificate notifications and all thumpnails/pictures are replaced with their tags. this happened out of nowhere while browsing

i did some research myself and managed to fix it, and this is something worth looking into. the certificates have specific times at which they become valid, but my computers time zone was changed and the actual time was off to compensate. the certificates were invalid for me because they were from a future time. i dont know how you can fix something like that but that was the problem.

Updated by anonymous

Languedoc said:
i did some research myself and managed to fix it, and this is something worth looking into. the certificates have specific times at which they become valid, but my computers time zone was changed and the actual time was off to compensate. the certificates were invalid for me because they were from a future time. i dont know how you can fix something like that but that was the problem.

IMO that is something that should not be 'fixed' on this end. If your computer is telling lies about what the 'current time' is, you need to make it not lie. SSL certificates are not the only thing affected by this. Anything that might want to compare your system date with the date of something else (for example, a file that is part of an update) can potentially be screwed up by this.

Updated by anonymous

savageorange said:
IMO that is something that should not be 'fixed' on this end. If your computer is telling lies about what the 'current time' is, you need to make it not lie. SSL certificates are not the only thing affected by this. Anything that might want to compare your system date with the date of something else (for example, a file that is part of an update) can potentially be screwed up by this.

I once triggered a simple calender program to take up over 5 GB of RAM after I changed the time forward 30 years and forgot about it for a couple hours. I'm not exactly sure why it did that, but the console was filled swamped all the way down with certificate errors.

So...yeah, computers really don't like it when you do that.

Updated by anonymous

This isn't the most pressing issue, I know, but on e926, TonyLemur still appears as Tony311...

Updated by anonymous

Cause "Artist is on the avoid posting list." in reports should be changed to "Content is on the avoid posting list." or something, as the artist might not be on the DNP list but the content may be on the DNP list (ie low quality, blurry...)

Updated by anonymous

Another one: report that the user has reached the upload limit BEFORE clicking "upload" on the upload page. It's kinda annoying to have everything tagged and then notice you've reached the limit.

Updated by anonymous

Can we get a code change so that tag history doesn't attribute alias and implication tag changes to the next user?

Example: https://e621.net/post_tag_history/index?post_id=580455

Edit 1 tags "Panda", "tubetop", "english_text", "cleavage". It makes it look like Edit 2 added "text", "panda", "tube_top", "bear", "clothing", "clothed", "breasts", "mammal". Edit 3 adds "char:sad_panda", the system changes that to character type, but it makes it look like Edit 4 changed it.

Expected behavior: tag changes by the system are represented in the tag history item that triggered the changes.

The tag history (first 4 only) should look like:

+anthro bear breasts black_and_white cleavage clothed clothing collar english_text female flower mammal monochrome navel panda rating:s sad sad_panda shepherd0821 solo text tube_top unknown_artist

+sad_panda bear breasts black_and_white cleavage clothed clothing collar english_text female flower mammal monochrome navel panda rating:s sad shepherd0821 solo text tube_top unknown_artist

+black_and_white +collar +sad +shepherd0821 bear breasts cleavage clothed clothing english_text female flower mammal monochrome navel panda rating:s solo text tube_top unknown_artist

+bear +breasts +cleavage +clothed +clothing +english_text +female +flower +mammal +monochrome +navel +panda +rating:s +solo +text +tube_top +unknown_artist

compare to:

+anthro +sad_panda -char:sad_panda bear breasts black_and_white cleavage clothed clothing collar english_text female flower mammal monochrome navel panda rating:s sad sad_panda shepherd0821 solo text tube_top unknown_artist

+char:sad_panda bear breasts black_and_white cleavage clothed clothing collar english_text female flower mammal monochrome navel panda rating:s sad shepherd0821 solo text tube_top unknown_artist

+bear +black_and_white +breasts +clothed +clothing +collar +mammal +panda +sad +shepherd0821 +text +tube_top -Panda -tubetop cleavage english_text female flower monochrome navel rating:s solo unknown_artist

+Panda +cleavage +english_text female +flower +monochrome +navel +rating:s +solo +tubetop +unknown_artist

Updated by anonymous

Lizardite said:
Cause "Artist is on the avoid posting list." in reports should be changed to "Content is on the avoid posting list." or something, as the artist might not be on the DNP list but the content may be on the DNP list (ie low quality, blurry...)

Lizardite said:
Another one: report that the user has reached the upload limit BEFORE clicking "upload" on the upload page. It's kinda annoying to have everything tagged and then notice you've reached the limit.

These should probably go into the feature request thread, this thread is for bug reports.

Updated by anonymous

Furrin_Gok said:
These should probably go into the feature request thread, this thread is for bug reports.

I've posted it here because I consider the feature request thread is to add new features. These are fixes for current features.

Updated by anonymous

Lizardite said:
Cause "Artist is on the avoid posting list." in reports should be changed to "Content is on the avoid posting list." or something, as the artist might not be on the DNP list but the content may be on the DNP list (ie low quality, blurry...)

Not actually a bug. The quality standards are not listed as a FFD option because they are not a valid reason to flag an image for deletion. Something you are probably well aware of by this point. It's the moderation staff's job to apply the site quality standards onto uploaded images.

Users who try to use the FFD for quality reasons are not actually being helpful, because the moderation staff can't just evaluate that image like normal once it's been FFD. They first have to evaluate the Flag itself for validity, relevance, and investigate what it is claiming about the image. And when it turns out to actually be an example of Flag Abuse, then we also have to stop approving/deleting images in order to go give someone a very carefully cited record for failing to read the instructions on what to FFD. And for abusing the FFD tool by picking something which they knew didn't actually apply to that image just because they wanted to flag it anyways and the reason they really wanted to flag it for wasn't listed.

If the reason isn't listed in the FFD options, then it probably is not what the FFD is allowed to be used for. If you think someone has done something to break the rules (such as plagiarism) then you can report the user to let us know about it. If it's over image quality, then let the moderation staff handle it and try not to backseat moderate the approval process. If you have a question about something that was approved, then you could Dmail the staff member who approved it with your questions. But chances are fairly good there was a reason it was approved, so it's not likely that doing this would change the outcome itself.

Updated by anonymous

Fine then. It's the last time I'm using the tool, then, since I won't get any record if I don't attempt to be helpful.

Updated by anonymous

savageorange said:
This seems like something that should be automatically fixable -- or at least automatically detectable. Like

select T.name from alias as A
     join implication as I on A.tag_id=I.implied_tag_id 
     join tag as T on T.id=A.tag_id

, off the top of my head, with a rough guess at E621's database schema.

The problem with developing e6 has never been figuring out how something should be coded; it's always been figuring out how to remove old code so it doesn't ruin the good code.

For instance, the alias is stored as a name rather than a tag id (a tag ID need not necessarily exist to make an alias).

The simple solution to this problem would probably be to simply process implications before aliases since implications can only add tags. This is probably going to be my next project now that I have time after the holidays.

Also, the tag_type_count crap should be fixed now.
TL;DR Race Conditions

Updated by anonymous

Furrin_Gok said:
Holy crap there's another admin!

I'm only an admin because I haven't bothered making a Developer role yet.

Updated by anonymous

spight said:
I'm only an admin because I haven't bothered making a Developer role yet.

Ahh the developer. The writer of programs; a harmless drudge, that busies themself in tracing the stack, and detailing the signification of pointers.

Updated by anonymous

spight said:
Also, the tag_type_count crap should be fixed now.
TL;DR Race Conditions

Well I've got both good news and bad news.

The good news:
arttags:[number here] seems to work now for all numbers (except 0). Both with range syntax and without range syntax. Excellent! Thanks.

A quick test of copytags:[number here] seems to be working with all numbers (except 0) and it seems to be working with range syntax. Thanks!

The bad news:
Using arttags:0 is still broken. In fact trying to search for 0 on any of these tag type count tags gives random broken results.

tagcount:[number here] still is broken, gives random results.
gentags:[number here] is still broken, random results.
(Note: I didn't bother checking if range syntax worked since the basic request is obviously not working on either of them.)
chartags and speciestags are also broken.

Testing things like chartags:5 (for example) seems to have a much higher rate of accuracy than it used to, but it still gives results like post #504336 (which actually has 7 char tags) and post #504713 (which actually has 4 char tags). So "chartags:" still broken.

A quick test of speciestags:[number here] also seems to be working with all numbers (except 0) and seems to be working with range syntax. Also thanks! Some seem to work, and some don't. So I guess it's not fixed yet. for example speciestags:1 has a few accurate results near the top of the page, but when you scroll down there's a ton of bogus results as well. speciestags:5 is what I originally tested, and it is mostly accurate, but on closer examination, it does still bring back a few false results like post #504561 which actually has 6 species tags. So speciestags: works better than it did, but isn't completely fixed yet. It makes me wonder if arttags and copytags are also more inconsistent than they first appeared to be. Not sure.

=/

Updated by anonymous

furrypickle said:
Well I've got both good news and bad news.

The good news:
arttags:[number here] seems to work now for all numbers (except 0). Both with range syntax and without range syntax. Excellent! Thanks.
A quick test of speciestags:[number here] also seems to be working with all numbers (except 0) and seems to be working with range syntax. Also thanks!
A quick test of copytags:[number here] seems to be working with all numbers (except 0) and it seems to be working with range syntax. Thanks!

The bad news:
Using arttags:0 is still broken. In fact trying to search for 0 on any of these tag type count tags gives random broken results.

tagcount:[number here] still is broken, gives random results.
gentags:[number here] is still broken, random results.
(Note: I didn't bother checking if range syntax worked since the basic request is obviously not working on either of them.)

Testing things like chartags:5 (for example) seems to have a much higher rate of accuracy than it used to, but it still gives results like post #504336 (which actually has 7 char tags) and post #504713 (which actually has 4 char tags). So it's still broken.

=/

I just tried speciestags:1 mammal and it doesn't seem to be working for me. I can't seem to find any connection between the posts that don't work and the ones that do.

They still work better than speciestags:0 and are definitely more predictable than -speciestags:<-1 and various searches I tried to do to magically convince it to show me 0 species tags.

Updated by anonymous

parasprite said:
I just tried speciestags:1 mammal and it doesn't seem to be working for me. I can't seem to find any connection between the posts that don't work and the ones that do.

They still work better than speciestags:0 and are definitely more predictable than -speciestags:<-1 and various searches I tried to do to magically convince it to show me 0 species tags.

You're right. I didn't test it very thoroughly the first time. And testing more attempts with using "speciestags:" leads to me getting the same problems you are. So I updated my report. Apparently searching for some numbers works better than others, and the percentage of accurate results on some numbers has gone up, but still not anywhere close to 100% accurate results. I think it was doing that before too, but it just never made sense to me why it does that. I am curious if copytags and arttags are also still broken in some way but the few tests I've run with them seem to work fine. Or whether the percentage of accuracy is high enough that I didn't notice any mistakes in the results on those yet.

Updated by anonymous

From what I can see, the tag count does work now.
BUT everything that was posted while it was broken still has wrong count. And blank edits don't seem to reset that anymore, you have to actually change some tag for it to fix itself.

And since there's tens of thousands of such posts, I imagine that it'd take ages to fix those if we do it one by one.

Is there any way for you admins to manually refresh every post?

Updated by anonymous

Genjar said:

Is there any way for you admins to manually refresh every post?

1. Get coffee
2. Use a script to add and remove &&&&&&12345&&&&&& to every single post.
3. Wait for server to start responding again.

...But hopefully there's a more convenient way than that.

Updated by anonymous

parasprite said:
1. Get coffee
2. Use a script to add and remove &&&&&&12345&&&&&& to every single post.
3. Wait for server to start responding again.

...But hopefully there's a more convenient way than that.

*writes it, sips coffee and waits while tag edits count skyrocket*

Updated by anonymous

Genjar said:
Is there any way for you admins to manually refresh every post?

That's the second thing I wrote for this project, right after the fix synchronizes the tag count. And yeah, I already ran it successfully on every post.

furrypickle said:
[Lots of great information with examples of failures and pretty colors]

Looks like implications are breaking it for some reason. post #130842

The good news:
The tag-counting stuff is now modular and easy to edit.

Edit: Looks like I was dumb and forgot some key things about making sure I reloaded all posts. I read from the last key, I deleted the last key after I was done with it, but... I forgot to set the last key whenever I finished saving a post. (This was at 3 in the morning last night...). Pushing a fix for it and re-running it now.

Implications still seem to be dumb, though.

Updated by anonymous

Lance_Armstrong said:
Bug: Deleted images alt text overruns 150x150 thumbnail box on pages such as https://e621.net/comment/search?query=user%3Aname

Reproduce: Find a user who commented on an image before it was deleted. Search the name and find it in the list.

Fix: Go to hexagon.css or other theme, add "overflow:hidden" to "img.deleted {}"

Can you screenshot what you are seeing? I haven't been able to reproduce this in any browser I've tried.

Updated by anonymous