I don't know what got changed but for the past few weeks thumbnails do NOT load for me initially. If the page is scrollable(enough results) then I can scroll slightly and the images suddenly load, but on pages with just a few results the thumbs do not load. I get to look at blank images... or placeholders, not broken images, just not loaded at all.

Hovering over a dead image will show the preview, but revert back to nothing after I scroll off it.

Frankly it's annoying... it is doing this between three different PCs that I've tried and all on Firefox.

Had that too, I use noScript and if you block either (or both) e621.net or dragonfru.it then the thumbnails won't load right away.

I have nothing blocked on e621, adblock and noscript are off here.

Problem is known. No solution currently

http://bugs.ouroboros.ws/view.php?id=50

It's called roll back to previous version...

Jaxinc said:
It's called roll back to previous version...

Yeah, but it's roll back of firefox because we didn't change. they did.

Anyhow, We are rebuilding the index pretty soon so please be patient.

Aurali said:
Yeah, but it's roll back of firefox because we didn't change. they did.

Strange, I don't have that bug and I'm using 20.0.1, the version Mozilla says is the newest one.

Used two different versions, don't see any difference.

Jaxinc said:
Used two different versions, don't see any difference.

the bug has been in place since version 17.1 of firefox.

NotMeNotYou said:
Strange, I don't have that bug and I'm using 20.0.1, the version Mozilla says is the newest one.

It's completely dependent on the resolution of firefox's window, sometimes firefox tells the javascript images aren't visible, sometimes it just lies and says everything is invisible. But We are ripping out that system and replacing it with a more modern system, as well as most of our ancient javascript library. That's why it's been a few months, because we just got tired of patching new browsers :p (chrome would break every week)

I take this thread to ask the reason for the sudden loss of bandwidth on e621 (for a few days), this is normal and temporary?

Tauxiera said:
I take this thread to ask the reason for the sudden loss of bandwidth on e621 (for a few days), this is normal and temporary?

Can you rephrase that question? I can't wrap my mind around what you are asking.

Why E621 is become so slow for a few days? The pictures loading is extremely slowly.

Tauxiera said:
Why E621 is become so slow for a few days? The pictures loading is extremely slowly.

picture loading? just double checked, I had 30 thumbs per second.. so it's running as intended (under full load), page loads are still slow at peak times. but that's as expected.

F5

I'm not talking about thumbs but the full size pictures.
For exemple, [this picture] need for me six minutes and 15 seconds for the full loaded !!!

On devianArt, the same picture need for me within 20 seconds...
I'm the only one experiencing this slowness? I find this slowness for a few days only on e621 :/

Tauxiera said:
I'm not talking about thumbs but the full size pictures.
For exemple, [this picture] need for me six minutes and 15 seconds for the full loaded !!!

On devianArt, the same picture need for me within 20 seconds...
I'm the only one experiencing this slowness? I find this slowness for a few days only on e621 :/

Do me a favor, let's do some tests (I am getting 12 mbps from the server)

login to speedtest.net, and trace from where you are to phoenix, AZ. post the results here. I'm thinking it's a routing problem

Aurali said:
login to speedtest.net, and trace from where you are to phoenix, AZ. post the results here.

http://www.speedtest.net/result/2683527799.png

Mario583 said:
http://www.speedtest.net/result/2683527799.png

not you.

http://www.speedtest.net/result/2683675472.png

Aurali said:
not you.

D;;;

Aurali said:
Do me a favor, let's do some tests (I am getting 12 mbps from the server)

login to speedtest.net, and trace from where you are to phoenix, AZ. post the results here. I'm thinking it's a routing problem

I do not know if this is exactly what you would like, I do not see any trace option on speedtest.net
For Phoenix. AZ
http://www.speedtest.net/result/2684347434.png

For my best server
http://www.speedtest.net/result/2684349321.png

Indeed, there is a problem with Phoenix. AZ, I got barely 2.28 Mb/s twenty minutes ago :/

2.11 Mb/s...... http://www.speedtest.net/result/2684426838.png

Jaxinc said:
I don't know what got changed but for the past few weeks thumbnails do NOT load for me initially. If the page is scrollable(enough results) then I can scroll slightly and the images suddenly load, but on pages with just a few results the thumbs do not load. I get to look at blank images... or placeholders, not broken images, just not loaded at all.

Hovering over a dead image will show the preview, but revert back to nothing after I scroll off it.

Frankly it's annoying... it is doing this between three different PCs that I've tried and all on Firefox.

Same problem here, by windowing/maximizing firefox I can get the too short to scroll pages to load.

Aurali said:
the bug has been in place since version 17.1 of firefox.

Present in 17.0 as well

Kaiselius said:
Same problem here, by windowing/maximizing firefox I can get the too short to scroll pages to load.
Present in 17.0 as well

eh, as I said, we are planning on stripping and replacing anyway. But it's gonna be a bit before it's done.

Snowy said:
http://www.speedtest.net/result/2683675472.png

You are delightfully evil.

I was pissed off by this lazy preview fetching, so I did a little script for Scriptish (or Greasemonkey, or Tampermonkey, whatever).
Create a new script, give it any ID and Name, specify two Includes:

http://e621.net/post*
https://e621.net/post*

Make it Run when Window incl. all media is fully loaded and enter the script content:

window.scroll(0, window.scrollY + 1);
window.scroll(0, window.scrollY - 1);

It should look like this. I know it's a dumb way to solve this issue, but works for me. Can't guarantee it will work every time, though.

Snowy said:
http://www.speedtest.net/result/2683675472.png

(So temped to say something.

Aurali said:
the bug has been in place since version 17.1 of firefox.
It's completely dependent on the resolution of firefox's window, sometimes firefox tells the javascript images aren't visible, sometimes it just lies and says everything is invisible. But We are ripping out that system and replacing it with a more modern system, as well as most of our ancient javascript library. That's why it's been a few months, because we just got tired of patching new browsers :p (chrome would break every week)

It sounds like you guys are moving forward, so that's good, but (with respect) if you're facing that many problems between different browsers then it sounds like the code is either too fragile or depending on undefined or implementation-dependent behaviors, neither of which is good. If you're confident it's bugs in the browser Javascript/dom engine, hopefully you've filed bug reports with Firefox/Chromium.

A lot of sites use viewport detection to handle loading of images, and I've never had the problem like what I see 90% of the time I view the thumbnail list on e621. Hopefully the new system is more robust.

By the way, when I first encountered this problem I thought I'd take a look at the JS source to see if anything stood out, but the only thing I found was https://e621.net/javascripts/application.js which is a mess of a bunch of different frameworks all put together (and why do that? Clients will cache the files so the extra couple of initial requests won't make a difference...), and I didn't really want to spend a bunch of time sifting through 20,000 lines of that. If someone wanted to help out with the project, how might they go about it? http://ouroboros.ws/download doesn't seem to be of much assistance :)

Thanks for your efforts :)

DrNick said:
It sounds like you guys are moving forward, so that's good, but (with respect) if you're facing that many problems between different browsers then it sounds like the code is either too fragile or depending on undefined or implementation-dependent behaviors, neither of which is good. If you're confident it's bugs in the browser Javascript/dom engine, hopefully you've filed bug reports with Firefox/Chromium.

A lot of sites use viewport detection to handle loading of images, and I've never had the problem like what I see 90% of the time I view the thumbnail list on e621. Hopefully the new system is more robust.

By the way, when I first encountered this problem I thought I'd take a look at the JS source to see if anything stood out, but the only thing I found was https://e621.net/javascripts/application.js which is a mess of a bunch of different frameworks all put together (and why do that? Clients will cache the files so the extra couple of initial requests won't make a difference...), and I didn't really want to spend a bunch of time sifting through 20,000 lines of that. If someone wanted to help out with the project, how might they go about it? http://ouroboros.ws/download doesn't seem to be of much assistance :)

Thanks for your efforts :)

Well it's because everything is compressed in the end. anyhow.. we are transitioning from prototype (severely broken dead project) to jquery (open and up to date). and with the thumbnail caching system with firefox, it's just gonna be simpler to switch it over :p.

Aurali said:
and with the thumbnail caching system with firefox, it's just gonna be simpler to switch it over :p.

It's not the entire thumbnail caching system, it's missing "show thumbnails" event when a page is loaded.

zeird said:
It's not the entire thumbnail caching system, it's missing "show thumbnails" event when a page is loaded.

We are getting rid of it.

Firefox doesn't like it, it changed pretty damn recently. and I'm replacing the load system with something more like what google has. The lazy load was just a temporary solution to another problem anyway.

Why not use OnScroll event? Attaching it to every image like

<img src="pixel.png" onScroll="pageScroll()" onLoad="if(this.src!='pixel.png'){this.style.opacity='1';}" original="/data/preview/c7/9f/c79f1376615feb4425ffb0b2607c0af2.jpg" />

while pageScroll() being

function pageScroll() {
  var dis = event.target;
 
  // Image is in view (vertically)
  if(dis.offsetTop>=window.scrollTop && (dis.offsetTop+dis.offsetHeight)<=(window.scrollY+window.innerHeight)) {
    dis.style.transition = "opacity 200ms linear 0ms";
    dis.src = dis.original;
  }
}

This may work, if scroll events refer to the whole page being scrolled or just the element. Of course, this'll require some tests. Because I haven't tested it yet :P

I know offsetTop, offsetHeight, scrollY and innerHeight are in both the Element Object and Window Object. Because standards.

/geek

No one's listening to meeeee T.T

Aurali said:
No one's listening to meeeee T.T

Are you really expecting something else on the internet?

They are just trying to help you cook something tasty up, even though you wish to keep it simple they just insist on adding some pineapple, and mustard, maybe even some pudding, also ice cream. Ice cream makes everything better, right?