Topic: General bug report thread - bugs here, bugs there, bugs everywhere, come here and report your bugs

Posted under Site Bug Reports & Feature Requests

TonyCoon

Former Staff

Link previews in Telegram seemed to stop working a couple of months ago. Now links don't generate any previews. Still works in Discord and the og tags are definitely there. Research implies that other sites having this issue with Telegram result from either the og tags not being shown or preview images returning 403 to Telegram user agents. Is this the case with e621?

tonycoon said:
Link previews in Telegram seemed to stop working a couple of months ago. Now links don't generate any previews. Still works in Discord and the og tags are definitely there. Research implies that other sites having this issue with Telegram result from either the og tags not being shown or preview images returning 403 to Telegram user agents. Is this the case with e621?

Funny how this has been broken for months with nobody saying anything, and then in the past 24 hours it gets mentioned both in the Discord server and here.

But yeah it's returning a 403 to the Telegram user agent, TelegramBot (like TwitterBot). It seems like any user agent containing TwitterBot gets rejected, actually.

Excluding Safe and Questionable ratings from search doesn't actually have an effect.

EG: https://e621.net/posts?tags=-rating%3Aquestionable+-rating%3Aexplicit+fox

Questionable still shows up. I tried with -rating:Q, -rating:q, and -rating:Questionable. Still the same thing: https://imgur.com/a/rSEMqQr

Same for Safe: https://e621.net/posts?tags=-rating%3Asafe+-rating%3Aquestionable+fox+order%3Arandom

Safe still shows up. I tried all the capitalizations again. Still same thing: https://imgur.com/a/Jd2ZMlQ

kobaj said:
Excluding Safe and Questionable ratings from search doesn't actually have an effect.

EG: https://e621.net/posts?tags=-rating%3Aquestionable+-rating%3Aexplicit+fox

Questionable still shows up. I tried with -rating:Q, -rating:q, and -rating:Questionable. Still the same thing: https://imgur.com/a/rSEMqQr

This is working as intended as the site expects that metatags should only have one value, and uses the last rating provided in the list. Safe and questionable can be excluded just fine when used alone - see -rating:q or -rating:s. Luckily, only having 3 ratings, it's possible to get any desired combination of ratings with just one metatag.

Your example query is actually the same as searching -rating:explicit as the rating:questionable gets overwritten by rating:explicit being later, which is why all the results are rated either Q or S. If you're looking to exclude both questionable and explicit images you should instead search rating:s.

Same for Safe: https://e621.net/posts?tags=-rating%3Asafe+-rating%3Aquestionable+fox+order%3Arandom

Safe still shows up. I tried all the capitalizations again. Still same thing: https://imgur.com/a/Jd2ZMlQ

Same goes for this one, -rating: questionable is overwriting -rating:safe and resulting in only questionable and explicit images. If you don't want questionable or safe posts, searching rating:e would give the results you want.

Updated

kobaj said:
Excluding Safe and Questionable ratings from search doesn't actually have an effect.

EG: https://e621.net/posts?tags=-rating%3Aquestionable+-rating%3Aexplicit+fox

Questionable still shows up. I tried with -rating:Q, -rating:q, and -rating:Questionable. Still the same thing: https://imgur.com/a/rSEMqQr

Same for Safe: https://e621.net/posts?tags=-rating%3Asafe+-rating%3Aquestionable+fox+order%3Arandom

Safe still shows up. I tried all the capitalizations again. Still same thing: https://imgur.com/a/Jd2ZMlQ

It looks like it does work, but you can't have more than one negated rating tag in a search. If you have more than one, only the last one takes effect.

Fortunately, there are only three ratings, so this doesn't cause any actual loss of functionality.

EDIT: Ninja'd

faucet said:
This is working as intended as the site expects that metatags should only have one value, and uses the last rating provided in the list. Safe and questionable can be excluded just fine when used alone - see -rating:q or -rating:s. Luckily, only having 3 ratings, it's possible to get any desired combination of ratings with just one metatag.

Your example query is actually the same as searching -rating:explicit as the rating:questionable gets overwritten by rating:explicit being later, which is why all the results are rated either Q or S. If you're looking to exclude both questionable and explicit images you should instead search rating:s.

Same goes for this one, -rating: questionable is overwriting -rating:safe and resulting in only questionable and explicit images. If you don't want questionable or safe posts, searching rating:e would give the results you want.

Thanks for the quick reply!

I understand that I can search rating:s which would be equivalent to -rating:q -rating:e. However, my usecase is rather specific. I have a Telegram bot that queries e621, and it only works based on negative values. So there is no way to specify rating:s, only -rating:q -rating:e. Given that this is not a bug, is it possible for me to make a feature request to support the multiple negative ratings functionality then?

Wildcards seem to be at least partially broken.

How to reproduce:

  • Consider the approximate count of posts listed for sentient* tags -- 900 to 1000 posts at a guess
  • Compare to the query sentient* which claims to have the maximum number of pages (750). Maybe check some of the posts and verify they don't have any such tag.
  • Compare to an empty query . There is some difference in the returned results, but I don't know if that is just due to caching or what. Maybe wildcard terms are being treated as literally nothing.

kobaj said:
Thanks for the quick reply!

I understand that I can search rating:s which would be equivalent to -rating:q -rating:e. However, my usecase is rather specific. I have a Telegram bot that queries e621, and it only works based on negative values. So there is no way to specify rating:s, only -rating:q -rating:e. Given that this is not a bug, is it possible for me to make a feature request to support the multiple negative ratings functionality then?

You're free to make a feature request - but I personally feel like the real solution is to just modify your code to support this way, it shouldn't be too hard to add logic that can translate the input into the way that e621 expects to receive it and not have to change the way end users have to specify the ratings at all.

savageorange said:
Wildcards seem to be at least partially broken.

How to reproduce:

  • Consider the approximate count of posts listed for sentient* tags -- 900 to 1000 posts at a guess
  • Compare to the query sentient* which claims to have the maximum number of pages (750). Maybe check some of the posts and verify they don't have any such tag.
  • Compare to an empty query . There is some difference in the returned results, but I don't know if that is just due to caching or what. Maybe wildcard terms are being treated as literally nothing.

Wildcards include aliased tags, and sentient_feral is aliased to feral, so all the results for feral are being included in this query too. By comparison sentient* -feral only returns ~1.1k results, but this isn't really ideal either since it'll be excluding valid results too.

This feels more of a problem with how we alias tags than an actual issue with the website. Results for sentient_tail -> living_tail also appear in the results - which is relevant and fitting for the search and shouldn't be regarded as a problem.

The feature works perfectly if we assume that the antecedent tag is a synonym of the target, but aliases have increasingly been used to remove invalid tags so the antecedent and consequent tags aren't necessarily 1:1 with their meanings. A similar issue is going on with *feral where it just gives results for both male and female because male_feral and female_feral have both been aliased to their respective gender tag.

faucet said:
This feels more of a problem with how we alias tags than an actual issue with the website. Results for sentient_tail -> living_tail also appear in the results - which is relevant and fitting for the search and shouldn't be regarded as a problem.

Hmm. Logical but definitely makes wildcards untrustworthy.

Suppose that there was a property in aliases that specified whether the alias was reductive (male_feral -> male being reductive, sentient_tail -> living_tail being non-reductive). Then it seems to me logical that wildcard searches could then ignore wildcard matches that have been reductively aliased away (possibly with a warning that these terms were excluded), while processing other aliases normally.

Trying to approve my own replacement on post #4388 causes the replacement to create a backup, then fail with the following message.
{ "success": false, "message": "Validation failed: Body is too long (maximum is 1000 characters)", "code": "54de1836-8ea3-49ad-9a72-276b83b60484" }

Not sure if this is a bug, but if you type Fav: then someone's username, you can see what the person has favorited. Not sure if this is a big deal or not, though.

anyile_bloomin said:
Not sure if this is a bug, but if you type Fav: then someone's username, you can see what the person has favorited. Not sure if this is a big deal or not, though.

This is a feature, if you want to hide your favorites from other users you can toggle "Enable privacy mode" in your advanced user account settings.

lafcadio said:
Trying to approve my own replacement on post #4388 causes the replacement to create a backup, then fail with the following message.
{ "success": false, "message": "Validation failed: Body is too long (maximum is 1000 characters)", "code": "54de1836-8ea3-49ad-9a72-276b83b60484" }

Should work now.

wolfhusk said:
Ayo my favorite count is on -211 man i don't know what to do man help me man

Fixed that for you.

It seems like noteupdater:[username] doesn't return all of the applicable posts. Specifically, I was looking for this one in noteupdater:chestercat, and it's just not there.

Doesn't look like a blacklist issue, that post shows up just fine when I search with other tags; I was wondering if noteupdater isn't returning posts where the user edited an existing note instead of adding a new one, so I tested that and that doesn't seem to be it either.

I'm experiencing repeated long outages on the image server today, usually about a minute at a time. The rest of the website seems to be working fine (so I can load search results, I just can't see them).

kora_viridian said:
I tried it just now and it worked OK for me. Make sure hyper is on one line, all by itself, in your blacklist.

i did. even put a space at the end of the tag like the autofill does. then added several of the sub hyper_* tags on their own lines when that didnt work. best i get is that it works with some.

I've noticed posts not coming up in a search for tags I added to those posts, and posts still coming up in a search for tags they don't have anymore. Also the tag autocomplete is misbehaving, not providing tags that it should (e.g. typing in fluffy_c doesn't give anything, but fluffy_ does, including fluffy_chest which should fit the former). Is there some heavy background processing going on?

I'm quite curious to know what the exact nature of the "database corruption" mentioned in one of the downtime placeholders was. That sounds worrying.

Judging by some of the reports above me, it looks like there is some kind of issue with things being slow to update any new edits/changes. So this may be more of the same.

But I noticed that some recently deleted images were still showing up in the normal searches alongside normal images (as if it was status:any even though it was just a normal search). I also noticed that running those same searches with status:deleted did not show the recently deleted images at all.

They are deleted, but the searches are just not updating right away. This was at least an hour after they had been deleted, and the searches still not updated. (source) Although I suspect that example may eventually fix itself if given enough time, so it's more the 'slow to update after a change is made' etc part that is the issue, and not so much that specific image search example. Just as a heads up on what else it is affecting.

sexygaydragon said:
Uh I can't look at my comments. Everytime I try this happens. It didn't happen before the maintenence.

Just to add some information to this comment:
Clicking their regular comments link on their profile works fine: https://e621.net/comments?group_by=comment&search%5Bcreator_id%5D=459466
But clicking their "mentions [in comments]" link is what throws up the error: https://e621.net/comments?group_by=comment&search%5Bbody_matches%5D=SexyGayDragon

Checking other links on profiles, nothing else seems to be throwing up an error. Just the 'mentioned in comments' link on profile pages throws up an error.

furrypickle said:
Just to add some information to this comment:
Clicking their regular comments link on their profile works fine: https://e621.net/comments?group_by=comment&search%5Bcreator_id%5D=459466
But clicking their "mentions [in comments]" link is what throws up the error: https://e621.net/comments?group_by=comment&search%5Bbody_matches%5D=SexyGayDragon

Checking other links on profiles, nothing else seems to be throwing up an error. Just the 'mentioned in comments' link on profile pages throws up an error.

It seems to be issues with searching the content of the comments specifically. If you search for a common word, such as hello, it gives the results you expect. If you instead search for a less common word, such as alabama, it times out. Similar things happen for post searches.

My hypothesis is: months ago a change was made that caused some slow down, which in turn caused less common searches to time out more quickly. This wasn't noticeable before, but once the slow down happened, it made it much more noticeable.

sexygaydragon said:
Uh I can't look at my comments. Everytime I try this happens. It didn't happen before the maintenence.

furrypickle said:
Just to add some information to this comment:
Clicking their regular comments link on their profile works fine: https://e621.net/comments?group_by=comment&search%5Bcreator_id%5D=459466
But clicking their "mentions [in comments]" link is what throws up the error: https://e621.net/comments?group_by=comment&search%5Bbody_matches%5D=SexyGayDragon

Checking other links on profiles, nothing else seems to be throwing up an error. Just the 'mentioned in comments' link on profile pages throws up an error.

jmvryt said:
It seems to be issues with searching the content of the comments specifically. If you search for a common word, such as hello, it gives the results you expect. If you instead search for a less common word, such as alabama, it times out. Similar things happen for post searches.

My hypothesis is: months ago a change was made that caused some slow down, which in turn caused less common searches to time out more quickly. This wasn't noticeable before, but once the slow down happened, it made it much more noticeable.

I suspect the index isn't being used correctly anymore, probably something with how the queries get planned between postgres 12/15. I'll take a look at that soon.

watsit said:
I've noticed posts not coming up in a search for tags I added to those posts, and posts still coming up in a search for tags they don't have anymore. Also the tag autocomplete is misbehaving, not providing tags that it should (e.g. typing in fluffy_c doesn't give anything, but fluffy_ does, including fluffy_chest which should fit the former). Is there some heavy background processing going on?

furrypickle said:
Judging by some of the reports above me, it looks like there is some kind of issue with things being slow to update any new edits/changes. So this may be more of the same.

But I noticed that some recently deleted images were still showing up in the normal searches alongside normal images (as if it was status:any even though it was just a normal search). I also noticed that running those same searches with status:deleted did not show the recently deleted images at all.

They are deleted, but the searches are just not updating right away. This was at least an hour after they had been deleted, and the searches still not updated. (source) Although I suspect that example may eventually fix itself if given enough time, so it's more the 'slow to update after a change is made' etc part that is the issue, and not so much that specific image search example. Just as a heads up on what else it is affecting.

Post updates didn't get processed for the last 4 hours for a reason I'm not going to get into right now. That's fixed and it'll go back to normal soon enough.

wat8548 said:
I'm quite curious to know what the exact nature of the "database corruption" mentioned in one of the downtime placeholders was. That sounds worrying.

When the database server got unexpectedly shut down by our host when they physically moved it we saw an increase in performance issues right around that time, which is a bit suspect. That's about the extend of that.

On Safari, no WebM videos will load. They all display the timer as 0:00 - 0:00 and just display the background colour. No video appears. Don't know if this is because of site traffic, the server upgrade, or because Apple/Safari sucks. Kind of annoying though.

Hey, very unsure if I'm even in the right place, but the tag suggestions that appear as you type in tags is no longer working for me after the site went down last time.

karasstash said:
On Safari, no WebM videos will load. They all display the timer as 0:00 - 0:00 and just display the background colour. No video appears. Don't know if this is because of site traffic, the server upgrade, or because Apple/Safari sucks. Kind of annoying though.

Definately not Safari. Some work for me some don't. It isn't limited to Apple either because other platforms are having issues with webms too. Oddly enough at least for me it's only on this site.

earlopain said:
I suspect the index isn't being used correctly anymore, probably something with how the queries get planned between postgres 12/15. I'll take a look at that soon.

I 'preciate it. I like to be punctual when replying to replies to my comments.

sexygaydragon said:
Definately not Safari. Some work for me some don't. It isn't limited to Apple either because other platforms are having issues with webms too. Oddly enough at least for me it's only on this site.

Odd. Guess it's just a maintenance oversight. Hope it's fixed.

karasstash said:
Odd. Guess it's just a maintenance oversight. Hope it's fixed.

I don't know. Don't get your hopes up. I've been having this issue since last year and it's yet to be fixed. It's funny because supposedly it's a user issue yet more and more users are having issues with webms. Almost as if I was right the whole time.

sexygaydragon said:
I don't know. Don't get your hopes up. I've been having this issue since last year and it's yet to be fixed. It's funny because supposedly it's a user issue yet more and more users are having issues with webms. Almost as if I was right the whole time.

(For the benefit of anyone else reading this, he keeps banging on about this when it's literally just him and he's already had the answer explained to him. Funny how he never mentions the fact that he eventually bedgrudgingly conceded that his problems with the mentioned videos were in fact fixed in these rants.)

wat8548 said:
(For the benefit of anyone else reading this, he keeps banging on about this when it's literally just him and he's already had the answer explained to him. Funny how he never mentions the fact that he eventually bedgrudgingly conceded that his problems with the mentioned videos were in fact fixed in these rants.)

Cause they weren't. The answer wasn't explained at all. It is definately a site issue since more and more people keep having this issue that you conveniently keep ignoring. When it's only happening here it's definately an issue on the site not the users. Also if you could read the janitor said only two of the three videos I linked to were fixed. There's still plenty more that don't work. Keep making excuses though.

Not sure if this is a bug or if it’s because I’m on mobile but when I uploaded an animated gif (#3930797)
It somehow converted it to a static jpeg file.

kora_viridian said:
When you posted it to e621, did you upload the original .GIF from your mobile phone, or did you post the .GIF somewhere else first (FurAffinity, Weasyl, etc) and then give e621 the URL to the post on FA (or other site)?

I uploaded it straight from my phone.

I gonna keep this brief I’m on mobile and for a while now for some reason when I log the site changes to what I’m pursuing to be the desktop/ computer form of the side and not the mobile version and it’s not a site thing when I log out and reopen the site it goes back to the mobile version so maybe I quick fix should be able to fix everything

jabberstherabbit said:
I gonna keep this brief I’m on mobile and for a while now for some reason when I log the site changes to what I’m pursuing to be the desktop/ computer form of the side and not the mobile version and it’s not a site thing when I log out and reopen the site it goes back to the mobile version so maybe I quick fix should be able to fix everything

Enable mobile mode support

For the past while on mobile every time I try to view an image it says "Updating Post" and then "Error:" and I don't know what to do to try and fix it.

voidina said:
For the past while on mobile every time I try to view an image it says "Updating Post" and then "Error:" and I don't know what to do to try and fix it.

Sounds like you've accidentally changed your mode. If you're on mobile, scroll to to the bottom of the page and change the dropdown box beneath the "Mode" heading to "View".

On desktop you can find this directly beneath the search box.

faucet said:
Sounds like you've accidentally changed your mode. If you're on mobile, scroll to to the bottom of the page and change the dropdown box beneath the "Mode" heading to "View".

On desktop you can find this directly beneath the search box.

Thanks for that, didn't even know it even happened to begin with, if it happens again I'll keep this in mind.

It seems my most recent upload is not viewable on mobile devices. It is a WebM file with H.264 compression. Someone has flagged it for review as a result of not being viewable on mobile, and I'm not sure what is causing it. I rendered with "high adaptive bitrate" because that was the default option. Could that be the issue?

raiandraws said:
It seems my most recent upload is not viewable on mobile devices. It is a WebM file with H.264 compression. Someone has flagged it for review as a result of not being viewable on mobile, and I'm not sure what is causing it. I rendered with "high adaptive bitrate" because that was the default option. Could that be the issue?

Opening the post on my Android phone with Chrome caused 0 issue, so unless this is an iPhone issue (iPhones have had problems with WebM forever) or a different browser issue (which, looking at a compatibility chart, tells me that Opera Mini is the only big browser that doesn't support it).

jmvryt said:
Opening the post on my Android phone with Chrome caused 0 issue, so unless this is an iPhone issue (iPhones have had problems with WebM forever) or a different browser issue (which, looking at a compatibility chart, tells me that Opera Mini is the only big browser that doesn't support it).

Thank you for the response! It seems like whatever the issue was has been fixed. Maybe it really was just iPhones being weird.

millcore said:
Post the bugs you've found here. Please be as specific and as constructive as possible; the more info about the issue you include the easier it will be for us to fix it.

Other forums you can check:
https://e621.net/forum_topics/25717 - List of changes that are NOT bugs
https://e621.net/forum_topics/25748 - Quick FAQ/Q&A thread
https://e621.net/forum_topics/25718 - For documentation problems
https://e621.net/forum_topics/25716 - The theme/aesthetic issues (please read the main post before using)

If you find other bugs floating around in the forum you can post a link to those forums here so they don't get lost.
If you already made another thread for a bug then please go edit [Bug] at the start of the title so it's easy to spot.

Greetings, I got an issue that was more intriguing than anything else.
One of my uploads that was previously approved, suddenly was put back in pending queue. Is this a bug or intended?

The picture in question: #3925065

ucumarrey said:
Already approved pics can be unnaproved? i didn't know that.
There's any particular reason? can't find anything related in the page wiki to clarify it.

Likely they second-guessed whether it's site relevant. The character does look exceptionally human, even if they're supposed to be humanoid, the non-human elements are pretty vague and questionable if it's anatomy or an accessory. You can always message them to ask why they unapproved it, though.

watsit said:
Likely they second-guessed whether it's site relevant. The character does look exceptionally human, even if they're supposed to be humanoid, the non-human elements are pretty vague and questionable if it's anatomy or an accessory. You can always message them to ask why they unapproved it, though.

gotta be patient and wait some days before ask for more answers, in case it gets approved again. But certainly is weird, specially gived my other uploads.

jmvryt said:
Opening the post on my Android phone with Chrome caused 0 issue, so unless this is an iPhone issue (iPhones have had problems with WebM forever) or a different browser issue (which, looking at a compatibility chart, tells me that Opera Mini is the only big browser that doesn't support it).

Works on my ipad just fine.

When I try to open an image from any search page on my Android phone using the Firefox app, I get a green window saying "Updating Posts (1 Pending)" followed by a red window saying "Error:", and am unable to open pictures without holding them down and pressing "open link in new tab." The site works normally if I am logged out, but stops working as described when I am logged in. The site also works normally on the PC. This error started occurring less than an hour before this report. It worked normally up until then.

Update: Figured out how to fix it. I had accidentally switched my Mode away from "View." For phone users, this option will be below the image catalog, but above the tags on a search page.

Updated

doctorhauster said:
When I try to open an image from any search page on my Android phone using the Firefox app, I get a green window saying "Updating Posts (1 Pending)" followed by a red window saying "Error:", and am unable to open pictures without holding them down and pressing "open link in new tab." The site works normally if I am logged out, but stops working as described when I am logged in. The site also works normally on the PC. This error started occurring less than an hour before this report. It worked normally up until then.

At the very bottom of the page, make sure your mode is set to "View". Anything else could be causing the issue.

gattonero2001 said:
https://e621.net/forum_topics/25734?page=29#forum_post_357092

Same issue again

https://www.furaffinity.net/view/50712857 -> https://d.furaffinity.net/art/munks/1674426161/1674426157.munks_vl.png

No similar posts found.

post #3828207

The most annoying part is that it only shows up when I finished tagging and the upload is rejected...

Alpha channels are problematic, issue #313

I've become reasonably reliant on Idem's sourcing suite whenever alpha channel images are involved, for the quick and easy md5 search. Doesn't guarantee a variant of the file hasn't been uploaded, but would've saved you time with that since the md5s match.

This seems like a pretty big bug, If you ask Me. I go to watch a video, It's running on flash. I click on it, I see the ruffle emulator pop up, & then it told me to contact a site administrator. TL;DR: Ruffle's Broken, Flash Files Won't Load.

bitWolfy

Former Staff

nrcrpodge said:
This seems like a pretty big bug, If you ask Me. I go to watch a video, It's running on flash. I click on it, I see the ruffle emulator pop up, & then it told me to contact a site administrator. TL;DR: Ruffle's Broken, Flash Files Won't Load.

E621 does not use Ruffle in any capacity.
Problem's on your side.

bitwolfy said:
E621 does not use Ruffle in any capacity.
Problem's on your side.

so there is no way to see the post flash without having to download them?

faucet said:
Alpha channels are problematic, issue #313

That seems confusing. PR #368 is supposed to have fixed issue #313. #368 is closed (with no particular explanation as to why?). Was PR368 not merged to master, or is there some other thing which means PR #368 was merged but actually didn't fix issue #313?

maicolex said:
so there is no way to see the post flash without having to download them?

Unless you're using the downloaded flash player (which allows you to run flash games from inputting a URL into the "open" prompt), probably not.