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

Posted under Site Bug Reports & Feature Requests

since cloudflare seems to be only partially enabled now, you could try

overriding your DNS lookups to skip it entirely …

assuming you have the DNSCache service enabled:

> echo 104.161.43.26 static1.e621.net >> %windir%\System32\drivers\etc\hosts
> ipconfig /flushdns

and restart your browser

once the problem is resolved (e.g. after few weeks), go back and remove the entry from your hosts file.

that IP is what I get right now if I run

> nslookup static1.e621.net 1.1.1.1

so i don't think there's anything sneaky about using it

Updated

That's the same IP resolve I get over here too, but the connections just time out. It's probably a ISP level problem because Tor seems to work reliably. (but I guess that depends on where your exit node was)

Maybe there's some weight to the whole "COVID-19 is breaking the internet" I keep hearing as a result of everyone staying home.

Having the same problem with the images, videos and even thumbnails, not loading. That's only when I am connected to the VPN however and seems to be happening on all the servers I've tried so far. The moment I disconnect from the VPN, the website works normal and everything is visible again.

Hi there, images won't load on my browser, no matter what. It's been like that for a couple of days now.

Something's changed today. I am able to see images again. No complaints, but the randomness of that is just hilarious. The beer virus is trying its best to make life ever more difficult.

No images are loading. I only get error-boxes and tags on the thumbnails.
When i click on stuff, i end up with a blank page.

Guys, it's lockdown corona time. I need to bust a nut.

I having an issue with not seeing most of the images, just a list of tags where the thumbnails should be and the image themselves never loading in when i click on it. curiously, it seems that i can see anything that i personally post though.

bipface said:
what IP does static1.e621.net resolve to for you?
it could be that cloudflare is somehow forwarding the ICMP packets on transparently, so it looks like you're tracing e621's own server

It resolves to 104.161.43.26 which is an ioflood owned ip. No sign of cloudflare. I do use OpenDNS as my dns server but that shouldn't matter as it's the same ip for one.one.one.one and dns.google.

If this is a cloudflare managed domain, then they did not enable caching on the requests and left is as passthrough; I own a couple domains on CF and that is no where close to how they should resolve. If this is supposed to be a cloudflare CDN url, then the fact that is ends up on ioflood is really suspicious; I have never used it so, yeah, no idea there. The only info I can find about them online is ties to advertising servers.

EDIT: I also tested using NordVPN elsewhere in Canada and in the USA. Same issue.

I have a problem with Discord. It only shows the "important" channels (welcome, migration-status, only-poof). I don't see the others. Why is this?

millcore said:
Post the bugs you've found here please, and 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.

Images aren't showing up for me. I've tried three different browsers on both Windows and Mac, but nothing is showing up. Not even the mascot on the front page. All I'm getting is the bar that shows how many favs, upvotes and comments that the images have received.

thrashboi said:
Images aren't showing up for me. I've tried three different browsers on both Windows and Mac, but nothing is showing up. Not even the mascot on the front page. All I'm getting is the bar that shows how many favs, upvotes and comments that the images have received.

It's not a bug, it's a network problem.

And whoops, I clicked wrong button, plz don't ban.

apoapsis said:
Something's changed today. I am able to see images again. No complaints, but the randomness of that is just hilarious. The beer virus is trying its best to make life ever more difficult.

I jinxed it. It's back to dead. Son of a b-

yakigatoniji said:
It resolves to 104.161.43.26 which is an ioflood owned ip. No sign of cloudflare. I do use OpenDNS as my dns server but that shouldn't matter as it's the same ip for one.one.one.one and dns.google.

"one.one.one.one" is CloudFlare's public DNS.

I wonder if someone is DDoS'ing this "ioflood" whoever they are.

kynikossdragonn said:
"one.one.one.one" is CloudFlare's public DNS.

That's exactly my point. Even using cloudflare's own DNS you get the same IP as everywhere else. So yeah... the issue definitely isn't on their side.

kynikossdragonn said:
I wonder if someone is DDoS'ing this "ioflood" whoever they are.

This seems likely to me as well. In that case, e621 admins should contact them and explain the situation. Hopefully for them, they have an SLA as this has been quite the downtime :D

With that, there is nothing else we can do by ourselves. :'(

I literally cannot see anything none of the images show up all I see is like ratios and favorites

Could this problem be caused by Cloudflare's recent update; blocking adult content.
I tested to see if e926.net had the same problem, and it works fine.

For the past few months I came here, I noticed that the videos and images on the site won't load up. It would just show all the tags and show a broken window as if the loading failed for it. When I click on it, the video or image doesn't display and only shows tags in the area where the content is supposed to be. I've went on different sites to see if the problem would occur on them as well (testing to see if it's my internet). They all worked fine. This is the only site that's doing it. I can't play videos because they won't pop up. The images are the same. Even my favorites is doing it. Might wanna look into that.

hentairobot123 said:
For the past few months I came here, I noticed that the videos and images on the site won't load up. It would just show all the tags and show a broken window as if the loading failed for it. When I click on it, the video or image doesn't display and only shows tags in the area where the content is supposed to be. I've went on different sites to see if the problem would occur on them as well (testing to see if it's my internet). They all worked fine. This is the only site that's doing it. I can't play videos because they won't pop up. The images are the same. Even my favorites is doing it. Might wanna look into that.

Yeah I know right, this is the same for me, since 5 days.

None of the images load in Firefox everything is just a blue dot. I dont even get the mascot on the initial screen.

shodori said:
None of the images load in Firefox everything is just a blue dot. I dont even get the mascot on the initial screen.

Images don't seem to be loading on Chrome or Edge either. If I were to guess, it's possible that either e621 or it's server host switched to Cloudflare 1.1.1.1 for Families, which blocks all adult content. I would think if that was true though, it would probably block the whole website and not just the pictures.

timeswordsman said:
If I were to guess, it's possible that either e621 or it's server host switched to Cloudflare 1.1.1.1 for Families, which blocks all adult content. I would think if that was true though, it would probably block the whole website and not just the pictures.

your line of thinking is reasonable, however i don't believe it's related; all the symptoms i've seen reported here are either 522 Origin Connection Time-out error pages or requests timing-out with no response,
whereas the 'for Families' nameserver appears to resolve the domain to an invalid IP address which would undoubtedly cause requests to fail instantly.

timeswordsman said:
Images don't seem to be loading on Chrome or Edge either. If I were to guess, it's possible that either e621 or it's server host switched to Cloudflare 1.1.1.1 for Families, which blocks all adult content. I would think if that was true though, it would probably block the whole website and not just the pictures.

That's not how dns resolution works. Clients are the one doing DNS resolutions, not servers. The websites give you a URL for pictures that are hosted on static1.e621.net. Your machine then resolves that domain, using your DNS configuration, to an IP address. The website has nothing to do with the DNS you use.

millcore said:
Post the bugs you've found here please, and 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.

Not sure if this is the correct place to post this but none of the images are loading for me. No thumbnails, no full images, nothing. I've cleared my browsing data and cache but nothing. It happened briefly yesterday but then randomly some of the images came back, my favorites or images I'd clicked on previously but nothing new. Now nothing loads at all.

Well... it looks like the network issue might be resolved. static1.e621.net is now responding again. Here is a traceroute that shows the normal path, for the curious.

Tracing route to static1.e621.net [104.161.43.26]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  setup.ubnt.com [192.168.1.1]
  2    <1 ms    <1 ms    <1 ms  removed.static.videotron.ca [removed]
  3    11 ms    11 ms     8 ms  10.50.16.1
  4    11 ms     9 ms    10 ms  10.170.183.61
  5    11 ms    11 ms     9 ms  216.113.122.210
  6    11 ms     9 ms     9 ms  hu0-3-0-2.ccr21.ymq01.atlas.cogentco.com [38.104.226.225]
  7    18 ms    19 ms    16 ms  be3259.ccr31.yyz02.atlas.cogentco.com [154.54.41.205]
  8    23 ms    25 ms    28 ms  be2993.ccr21.cle04.atlas.cogentco.com [154.54.31.225]
  9    31 ms    30 ms    30 ms  be2717.ccr41.ord01.atlas.cogentco.com [154.54.6.221]
 10    54 ms    52 ms    51 ms  be2831.ccr21.mci01.atlas.cogentco.com [154.54.42.165]
 11    64 ms    62 ms    64 ms  be3035.ccr21.den01.atlas.cogentco.com [154.54.5.89]
 12    92 ms    92 ms    92 ms  be3046.ccr21.elp01.atlas.cogentco.com [154.54.0.45]
 13    92 ms    92 ms    92 ms  be2930.ccr32.phx01.atlas.cogentco.com [154.54.42.77]
 14    93 ms    98 ms    93 ms  be3408.rcr21.b023003-0.phx01.atlas.cogentco.com [154.54.28.146]
 15    75 ms    74 ms    75 ms  38.104.116.130
 16    79 ms    76 ms    76 ms  we.love.servers.at.ioflood.net [148.163.87.9]
 17    76 ms    75 ms    75 ms  we.love.servers.at.ioflood.net [104.161.43.26]

Trace complete.

I'm starting to believe 148.163.87.9 is a load balancer and it might have been got stuck on a dead server. My guess is that someone noticed at ioflood.net and fixed their configs/hardware.

Updated

The site used to not show any picture until like 10 minutes ago, now it works perfectly. Yay for the recovery of e621!

Discord only shows the "important" channels (welcome, migration-status, only-poof). I don't see the others. Why is this?

Our provider has made additional tweaks to their network to try and work around the issues that have been going on. If you continue to have problems please post a traceroute to static1.e621.net so that we can investigate further and continue trying to work around the issue.

kiranoot said:
Our provider has made additional tweaks to their network to try and work around the issues that have been going on. If you continue to have problems please post a traceroute to static1.e621.net so that we can investigate further and continue trying to work around the issue.

what ever the provider changed seems to work, i can see thumbnails and load art the first time in days. <3 good job

We are aware of delays in processing search updates. The queue is currently about 45 minutes behind and slowly recovering. Additional workers have been added to help cope with the increased load. We should hopefully reach realtime updates again in about an hour. Sorry for the confusion that this may cause. Things that are impacted by this are searching for favorites, pool/set updates in the search system, and changes to tags and tag categories not correctly reflected in the search system. Favorites and post scores may also be behind when using them in search queries.

Update April 7 18:40 UTC-4: The queue is now about 35 minutes behind realtime and still coming steadily down. It's not a uniform decrease in latency at this point in time, so may catch up more suddenly later on.

Update April 7 19:21 UTC-4: The queue is now about 17 minutes behind realtime and is picking up in speed slightly. Thank you for being patient while this resolves.

Update April 7 20:22 UTC-4: The queue has been resolved and the current workers are keeping pace with the normal functioning of the site and the generated background jobs. I will continue to monitor the situation to help ensure that things do not relapse.

Updated

There are problems with editing Inactive / Deleted artists. Regular users aren't allowed to edit those artist pages. I want to update source links to https, and add missing sources if necessary, but it doesn't allow me to.

Artists that have additional names aliased behave strangely. One artist alias can have one status, and another could have a different status.

I tried to edit this page to update the links. https://e621.net/artists/4122 Notice that there's no indication that there are any aliases associated with this tag on this page. I managed to create an artist wiki on one of the aliases that was listed as Active instead. https://e621.net/artists/4348

One may think that you could access the view wiki page to see aliases, but this link doesn't show if there isn't a wiki page. It only appears for that artist page, because I searched for the artist through Tags instead of Artists, and it let me create a wiki page, but it did not allow me to update the source links through that page.

Example: Deleted artist page without wiki page

https://e621.net/artists/31008

This makes it very difficult to tell what is aliased. An alternate name could very well be a different artist entirely.

Updated

komuros said:
The following metatag searches are currently not working correctly:

date:month..year - No relative terms (ex: day, week, month, etc) currently return results for this. Absolute dates do work.
comments:## - No value in place of ## will return results.
speciestags:## - No value in place of ## will return results.
date:decade - Returns results from ten or more years ago, instead of from the last ten years.
source:example.com - I'm not sure if this is a bug, but this only returns posts with a source field starting with "example.com", not posts with a source field simply containing it.
notes:whatever - No word or string in place of "whatever" currently returns results.
delreason:whatever - No word or string in place of "whatever" currently returns results.
hideanon:true/false - Both currently return all posts.
hidegoogle:true/false - I don't know what is hidden from Google crawling, but if something is supposed to be hidden, both of these still return all posts.
order:desclength - Both this and the _asc variant currently return all posts in the default order.
order:comments - Both this and the _asc variant currently return all posts in the default order.

Side notes:
- I think the documentation for the ago syntax could be clarified. Ex: it currently seems to say that date:5_weeks_ago will return posts that were posted within the last 5 weeks, but it actually returns posts from whichever day was exactly 5_weeks_ago.
- On the cheatsheet, "notelocked:true" has an extra colon in it.

I am also (and still) experiencing this issue

The date changes may be intentional, as the age: metatag replaces much of its functionality. The presently correct way of writing the two 'date' queries listed by komuros are (after adding 'rating:safe' to pare the results down to <750 pages):

The docs are still wrong last I checked. I got the impression there was some more uptodate docs on discord, but meh, discord..

It's just a minor thing, but the tabindex on the login page prioritizes the announcements banner before the username input, and the same on the posts page with putting the announcements banner before the search bar.

Blacklist posts still appear in search results. And it shows that the black listed tags are black listed, it just doesn't get rid of them.

Edit: This bug only seems to be appearing when using Brave Browser, this doesn't happen in the latest version of Firefox (as of April 11th, 2020).

Updated

I don't know if it is a bug; but i recently uploaded a drawing with a jug shaped as a rooster and tried tagging that; which turned into the system thinking i had a bird-character in the image and added some tags which are misleading... since there are no bird-characters in the image, just the jug.

So, i don't know if it counts as a bug or not, or are we not supposed to tag items shaped as animals or creatures...?

The hotkeys, for next/previous post, work when you're viewing a Pool, but they do not work for a Set (even though you can still use the navigation links at the top)

ranthos said:
The hotkeys, for next/previous post, work when you're viewing a Pool, but they do not work for a Set (even though you can still use the navigation links at the top)

Can't confirm this.
For me (FF 74, Arch Linux x86_64):

  • Pool navigation using <- / -> : doesn't work
  • Set navigation using <- / -> : doesn't work
  • Pool navigation using a / d : works
  • Set navigation using a / d : works

EDIT:

Just a reminder to anyone seeing this: If you are posting a bug, please take the time to mention your browser, OS, and hardware platform. Browsers are super complex and any given bug often manifests only in very particular conditions. It makes it much easier for others to confirm and for devs to fix.

Updated

savageorange said:
Can't confirm this.
For me (FF 74, Arch Linux x86_64):

  • Pool navigation using <- / -> : doesn't work
  • Set navigation using <- / -> : doesn't work
  • Pool navigation using a / d : works
  • Set navigation using a / d : works

EDIT:

Just a reminder to anyone seeing this: If you are posting a bug, please take the time to mention your browser OS, and hardware platform. Browsers are super complex and any given bug often manifests only in very particular conditions. It makes it much easier for others to confirm and for devs to fix.

My bad. I should've remembered to give specs--I'm a developer for other things, myself.
I'm running Chrome 81.0.4044.92 64-bit on Windows 10 (64-bit).

  • Pool/set navigation with arrow keys: doesn't work
  • Pool navigation using a / d: works
  • Set navigation using a / d: doesn't work

goodusername said:
It has fixed itself now

This is probably a bad order of operations involving updating pools and the posts in them quickly. I'll have to see if there is a better way to organize this so that it's more stable. I have noticed that pools are a bit more error prone with the new search integration.

Not sure if this was mentioned before, but DText custom titles aren't working for tags or lists of tags.

This image is of the DText help page showing custom titles working for wiki pages and anchors but not tags.

In the example it displays "a list of tags|Some Text" instead of just the words "Some Text".

It does this with custom tag titles on profile text sections as well.

To add to zenitix's report, links that jump to anchors on a different page no longer work. Hashtags are being treated as part of the wiki page name instead.

[Bug] Users can't see deleted flags: https://e621.net/forum_topics/25900

I can confirm that I've also experienced this error. My userpage only lists 23 flags, and all of the entries in https://e621.net/post_flags?search%5Bcreator_name%5D=Songbird are either marked as "Deleted - Resolved? false" or "Active - Resolved? true".

Attempting to view https://e621.net/post_flags?search[creator_name]=Songbird&search[category]=deleted results in the following error:

An unexpected error occurred.

Log ID: 6dbad990-39b2-49f8-87a2-5a33cda6cd31

I'm having trouble logging in from my mobile phone. It says "an unexpected error has occurred. Log ID: (none) Can I get some help with this?

I can't seem to find the person who uploaded a thing on this website only the person who approved it, I wanna know who uploaded something because artists post here and they usually post links to there other social media on their accounts. I don't wanna go threw bullshit tags just to see who upload it. its bullshit

bitWolfy

Former Staff

thiggy said:
I can't seem to find the person who uploaded a thing on this website only the person who approved it, I wanna know who uploaded something because artists post here and they usually post links to there other social media on their accounts. I don't wanna go threw bullshit tags just to see who upload it. its bullshit

Not a bug. The change is intentional.
You can whine all you want, this uploader's name is most likely gone for good.

bitwolfy said:
Not a bug. The change is intentional.
You can whine all you want, this uploader's name is most likely gone for good.

but why?

thiggy said:
I wanna know who uploaded something because …

you can still use the API to get the uploader's user ID
e.g. https://e621.net/posts/2066839.jsonuploader_id : 375039https://e621.net/users/375039

thiggy said:
but why?

the main discussion around this change can be found
here: https://danbooru.donmai.us/forum_topics/15088
and here: https://danbooru.donmai.us/forum_topics/15916

About a year ago, Danbooru rolled out a system to obscure the uploader of a post, replacing it with an idea called Top Tagger. The top tagger is whoever adds the most tags to a post. This was an attempt to discourage upload sniping, since credit would be rewarded not to the person who uploads the post first, but whoever supplies the most information

'upload sniping' was the practice of adding posts with (initially) the minimum number of tags, racing against other users who might be trying to upload the same post.
obviously the 'top tagger' field has since been removed.

bitWolfy

Former Staff

thiggy said: but why?

I swear, there was an admin response to that somewhere in this thread, but now I can't find it. There's this snippet from discord.
Essentially, people obsess over having their names out there, to the point of claiming final authority over tags and sources for the images they uploaded.

bipface said:
you can still use the API to get the uploader's user ID
e.g. https://e621.net/posts/2066839.jsonuploader_id : 375039https://e621.net/users/375039

the main discussion around this change can be found
here: https://danbooru.donmai.us/forum_topics/15088
and here: https://danbooru.donmai.us/forum_topics/15916

'upload sniping' was the practice of adding posts with (initially) the minimum number of tags, racing against other users who might be trying to upload the same post.
obviously the 'top tagger' field has since been removed.

Ah i see

but though i think its kinda dumb ngl

Not sure if this is a bug report, a feature request or just a general question because I'm blind, but I'd love a way to disable the images being immediately downloaded and shown in the highest possible resolution (instead of being resized like normally) when logged in. It just takes so much longer and steals so much data. Because like I just said it's only an issue when using an account, I'm assuming it is optional... but it's also nowhere to be found?

incadescence said:
Not sure if this is a bug report, a feature request or just a general question because I'm blind, but I'd love a way to disable the images being immediately downloaded and shown in the highest possible resolution (instead of being resized like normally) when logged in. It just takes so much longer and steals so much data. Because like I just said it's only an issue when using an account, I'm assuming it is optional... but it's also nowhere to be found?

What you're looking for is probably in your user settings. Click on Account in the header and then on Settings.
There should be a option called default image width. Selecting 850px is what you want I assume.

"claiming final authority over tags and sources " LOL, sounds like an x,y problem? Attitude adjustments are long-term solution for people like that. The problem is like weeds - what happens when you let them take over the entire neighborhood? Analogy of mowing versus just digging them up comes to mind, as well. Sigh, sometimes the more effective methods of weed control take a lot more effort in the shortterm. Might be an analogy fail?

So, not sure how I didn't notice this, or if I did and forgot. It seems that code for (revealing the) Edit button never gets called to present the interface for tags. I was adding a missing tag and it's not letting me show the interface unless I use Inspector to unhide the "edit" section.

<section id="edit" style="display: none;">

I'm thinking more and more there's bug in either SeaMonkey/Firefox/Palemoon, OR there's a bug in the security addons. I'll have to track this down, but some of these bugs happened to people running even browsers on game consoles that don't have any kind of addons. I think the mobile browsers have yet another entirely different bug. Did the people who make Chrome change some standards for styles that aren't fully supported even on HTML5 browsers and then "code worked on my machine" happened? :/ It's frustrating to debug. I thought this was a basic function of browsers to enable changing styles, going back to like 2010 or earlier. Why did it work with earlier code and not now? Cross-scripting protections? Security issues? Then why does it even work at all in newer versions of Chrome and Firefox that are getting really strict?

If I can find the bug, and a fix, I'll try to submit a patch. Testing it in a bunch of browsers is going to suck, though, hehe. Making filters for UbO and userscripts is very much a short-term solution. It's not solving the underlying problem and only helps me or the 1-2 people willing to install them.

:edit:
Well, I found the problem on at least one browser. They REQUIRE DOM.storage.enabled to be true. This is a browser-wide setting and has nothing to do with running JS to change the style, but some sites apparently use it for other reasons. So annoyed to realize it was yet another feature designed to hide stuff from users being able to control - thanks Google. I guess fix is to just give up and go along with the floodwaters.

Updated

alphamule said:
I guess fix is to just give up and go along with the floodwaters.

i mean… if you already have cookies enabled (since you're logged-in), i don't see any further harm in having dom-storage enabled as well.

earlopain said:
What you're looking for is probably in your user settings. Click on Account in the header and then on Settings.
There should be a option called default image width. Selecting 850px is what you want I assume.

That's it, thanks. I was looking in the "advanced" settings.

bipface said:
i mean… if you already have cookies enabled (since you're logged-in), i don't see any further harm in having dom-storage enabled as well.

Problem I had was trying to do it per-site. Yeah, I think they've mostly fixed that, though? BTW, I read up again after a few years and realized I derped/misremembered. It's not really a 'Google' thing, but way it's implemented helps do the sorts of things people hate them for, so got mixed up in my mind hehe.
http://dev-test.nemikor.com/web-storage/support-test/ Nice place to test it. I can't seem to disable it in uBO, but I'll probably figure out a workaround. I really, really wish they'd make it possible to whitelist these kinds of abusable features.

alphamule said:
Problem I had was trying to do it per-site … but I'll probably figure out a workaround. I really, really wish they'd make it possible to whitelist these kinds of abusable features.

as far as i can tell, the per-site cookie permissions in both firefox and chrome also applies to dom-storage.
see: https://i.imgur.com/fNMNn9k.png

bipface said:
as far as i can tell, the per-site cookie permissions in both firefox and chrome also applies to dom-storage.
see: https://i.imgur.com/fNMNn9k.png

Problem with that is it blocks cookies period? So frustrated especially when things seem to not work as promised, or worse, deliberately don't work.

Well, workaround to make those sites work is to enable DOM storage, then set dom.storage.default_quota to 0. :P I'll need to test it to verify it's doing what it says.

alphamule said:
Problem with that is it blocks cookies period? So frustrated especially when things seem to not work as promised, or worse, deliberately don't work.

Well, workaround to make those sites work is to enable DOM storage, then set dom.storage.default_quota to 0. :P I'll need to test it to verify it's doing what it says.

The expectation of all sites is that if cookies work and the local storage API exists and works, that it should be able to store things in local storage. The site uses local storage because cookies get sent to the server every time, but local storage doesn't. It's a much better way to deal with local settings for users without making all requests larger and more cumbersome. If you start trying to disable it, you'll break many many things.