The avatars? It's unlikely that blacklists would apply. If people can't use common sense and only use safe avatars then they deserve a ban.Akio-sama said:
What do you think about 'blacklisted' small image as we could see in comments? Can it be added either with intercept big pic without login? Or you exactly mean that? P.S. English is not my native language. Sorry :)
I'm not sure.
I don't know if intercepting direct links with a disclaimer/warning would work. I'll post it on the bug tracker.
At the end of the day this isn't a work-safe site, and no-one should expect it to be.
The bug that "When adding artist as number of a circle, the alias names of that artist would be cleared" has been fixed. So artist DB contributors now can use member feature more frequently, without worry about this bug.
I will keep announcing fixed bugs or minor changes here if I think they're important for others who don't check the project site often.
I will keep announcing fixed bugs or minor changes here if I think they're important for others who don't check the project site often.
downloading pools using download manager still infinitely redirect to https://moe/user/*
btw, using iGetter 2.9.1
btw, using iGetter 2.9.1
Which particular pool are you using the download manager on?Haekel said:
downloading pools using download manager still infinitely redirect to https://moe/user/*
btw, using iGetter 2.9.1
If you are trying to get them all then please stop being selfish, and PM admin2 as per https://yande.re/forum/show/16720
the problem seems affect all the pool download (*.jpg/*.png)
no, I just use single download at once.
the problem is this
http://i47.tinypic.com/n1s7si.jpg
does domain https://moe/user/* really exist?
seem it's redirected to invalid link infinitely.
btw, network error: 1 means link not found.
no, I just use single download at once.
the problem is this
http://i47.tinypic.com/n1s7si.jpg
does domain https://moe/user/* really exist?
seem it's redirected to invalid link infinitely.
btw, network error: 1 means link not found.
It is trying to redirect you to the login, by not using an actual web browser with a gui to log in, it will just send you in redirect loop, so your download manager is not grabbing your login and userhash cookies etc. Same problem with trying to download a pool via wget, or anything else that doesn't have a gui to login. So you can either just download it normally via your actual browser download manager, or use something that can import cookies.Haekel said:
the problem seems affect all the pool download (*.jpg/*.png)
no, I just use single download at once.
the problem is this
http://i47.tinypic.com/n1s7si.jpg
does domain https://moe/user/* really exist?
seem it's redirected to invalid link infinitely.
btw, network error: 1 means link not found.
Not really a bug, but a feature.
We're now running on jruby. Let me know if you notice anything weird.
I'm now seeing a "Connecting..." delay of 1 to 3 seconds on average in Firefox 18, before page content begins downloading. Previously, page content would begin to load near-instantly as soon as a link was clicked.
Something definitely seems to be causing the server to respond slower than normal at the moment.
Something definitely seems to be causing the server to respond slower than normal at the moment.
same here.Cyberbeing said:
I'm now seeing a "Connecting..." delay of 1 to 3 seconds on average in Firefox 18, before page content begins downloading. Previously, page content would begin to load near-instantly as soon as a link was clicked.
Something is definitely seems to be causing the server to respond slower.
I notice it occasionally, maybe not enough threads. Will be fine tuning.
Threads bumped up to 64, let me know if its still occurring.
Threads bumped up to 64, let me know if its still occurring.
I'm tempted to say these recent tweaks haven't improved this issue at all during yande.re peak times. I'm still occasionally getting hit with a page that gets stuck 2-6 seconds in "Connecting...", waiting for the server to respond. Completely random.
With my FTTH connection and close proximity to the server, it was completely normal for me to never see any type of delay in server response prior to this jruby change. Something is still not right.
tracert to yande.re
<1 ms | 192.168.1.254
<1 ms | ftth.swbr.surewest.net
<1 ms | 172.22.5.13
<1 ms | 172.21.2.13
<1 ms | 172.21.0.250
4 ms | sjo-bb1-link.telia.net [213.248.88.73]
4 ms | xe-1-3-0.sjc10.ip4.tinet.net [173.241.128.109]
13 ms | xe-2-2-0.lax30.ip4.tinet.net [89.149.180.250]
13 ms | as29761.gw.ip4.tinet.net [199.168.63.78]
13 ms | 96.44.180.2.internal.quadranet.com [96.44.180.2]
13 ms | yande.re [72.11.139.2]
Edit, 30 minutes later with slightly higher site load:
I was experiencing uniform 1-3 second "Connecting.." delays on every page load for ~5 minutes straight. But then it went back to occasional delays like described above.
With my FTTH connection and close proximity to the server, it was completely normal for me to never see any type of delay in server response prior to this jruby change. Something is still not right.
tracert to yande.re
<1 ms | 192.168.1.254
<1 ms | ftth.swbr.surewest.net
<1 ms | 172.22.5.13
<1 ms | 172.21.2.13
<1 ms | 172.21.0.250
4 ms | sjo-bb1-link.telia.net [213.248.88.73]
4 ms | xe-1-3-0.sjc10.ip4.tinet.net [173.241.128.109]
13 ms | xe-2-2-0.lax30.ip4.tinet.net [89.149.180.250]
13 ms | as29761.gw.ip4.tinet.net [199.168.63.78]
13 ms | 96.44.180.2.internal.quadranet.com [96.44.180.2]
13 ms | yande.re [72.11.139.2]
Edit, 30 minutes later with slightly higher site load:
I was experiencing uniform 1-3 second "Connecting.." delays on every page load for ~5 minutes straight. But then it went back to occasional delays like described above.
database pooling was not configured correctly, should be fixed now.
we're back on MRI due to obscure bugs showing up due to multithreading.
No wonder everything felt like it was loading even quicker right now. MRI certainly seems superior as far as server responsiveness goes.
Though I'll just throw out there that after you fixed the jruby database pooling, the site did seem to be working decently otherwise. You could still occasionally feel a slight lag, but it was usually no more than a half-second, often less. I'd say it was within an acceptable range, but I was planning to withhold final judgment until weekend peak time.
So does that mean jruby is now off the table for a stable Windows implementation of moebooru, or is the multi-threading bug something you've reported upstream and expect to be fixed eventually?
Though I'll just throw out there that after you fixed the jruby database pooling, the site did seem to be working decently otherwise. You could still occasionally feel a slight lag, but it was usually no more than a half-second, often less. I'd say it was within an acceptable range, but I was planning to withhold final judgment until weekend peak time.
So does that mean jruby is now off the table for a stable Windows implementation of moebooru, or is the multi-threading bug something you've reported upstream and expect to be fixed eventually?
It should be able to work on windows with MRI, I'll be doing some testing this weekend
SPDY enabled
zips fixed
Let me know if you see anything weird
zips fixed
Let me know if you see anything weird
Using Firefox 18, I was downloading images (3 simultaneous) from page 1 of a pool, while this was ongoing I clicked next for page 2. Loading stalled before the page numbers on the bottom were shown.
I clicked stop -> refresh, and now yande.re seems to have blocked/banned me [an error has occurred] from downloading original images and samples... First time I've ever had this happen, but I assume it's temporary and will lift in a few minutes?
Edit: Still blocked 8 hour later...
I clicked stop -> refresh, and now yande.re seems to have blocked/banned me [an error has occurred] from downloading original images and samples... First time I've ever had this happen, but I assume it's temporary and will lift in a few minutes?
Edit: Still blocked 8 hour later...
I've restarted nginx, I think when connections get interrupted they linger forever.
Believe there is a bug that leaves "writing" connections open --> http://munin.yande.re/yande.re/ayase.yande.re/nginx_combined_localhost.html
As you can see when I restarted it.
Believe there is a bug that leaves "writing" connections open --> http://munin.yande.re/yande.re/ayase.yande.re/nginx_combined_localhost.html
As you can see when I restarted it.
That nginx restart seemed to fix my image loading errors.
That sounds like a rather major bug. I guess I'll just need to hope Firefox doesn't stall again.
That sounds like a rather major bug. I guess I'll just need to hope Firefox doesn't stall again.
Still having problems with page loading stalling in Firefox 18 while I'm downloading images. In the past few minutes it occurred multiple times, and seems easily reproducible. Luckily, so far I haven't gotten blocked yet.
Edit: Disabling SPDY in Firefox seems to resolve the page load stalling while downloading issue.
Edit: Disabling SPDY in Firefox seems to resolve the page load stalling while downloading issue.
Attempted an additional test with only SPDY v2 enabled and a minor change from the Fx Nightly about:config settings, and now I'm blocked again...
Original images and Samples [an error has occurred]
Original images and Samples [an error has occurred]
I've turned it off for now.
tag list in sidebar is now sorted by categories.
Can we just do a 'survey' before any non-technique changes?edogawaconan said:
tag list in sidebar is now sorted by categories.
in /post/ interface, it's totally useless now. With the old one I can easily see what artists' images just get massive uploaded recently, or what characters are most related with a copyright. With this alphabetic new one, I can do nothing. It still needs to be sorted by count as before, at least secondly.
The change in /post/show/ pages is not that bad, since it originally only ordered alphabetically. But now it just doesn't match the order in edit box. If the edit box also has the order of tag sorted by categories it's more useful (for delete fault tag or something like it).
BTW, what about an artist-circle-copyright-character-general-fault sort? Just like the order in shift-hover info box.
[edited to make it less QQ]
I agree with fireattack.
Sorry, it's actually I mixed up this update and some fixes. But then I thought "whatever".fireattack said:
Can we just do a 'survey' before any non-technique changes?
Reverted for non-/post/show/ (I completely forgot about that). I'll improve it later by sorting it by count first, then categories.fireattack said:
in /post/ interface, it's totally useless now. With the old one I can easily see what artists' images just get massive uploaded recently, or what characters are most related with a copyright. With this alphabetic new one, I can do nothing. It still needs to be sorted by count as before, at least secondly.
I'll fix those later.fireattack said:
The change in /post/show/ pages is not that bad, since it originally only ordered alphabetically. But now it just doesn't match the order in edit box. If the edit box also has the order of tag sorted by categories it's more useful (for delete fault tag or something like it).
BTW, what about an artist-circle-copyright-character-general-fault sort? Just like the order in shift-hover info box.
[edited to make it less QQ]
running with spdy enabled again, hopefully the updated patch solves the hanging problems
Well there are no hangs now, but...
In Firefox (tested 18.0.2 release, 19.0 release build1, 21.0a1 nightly) everything now downloads extremely slow, unless I disable SPDY in about:config. Marginally faster in Chromium 27, but still extremely slow.
SPDY disabled in Firefox: ~4x slower than normal.
SPDY enabled in Firefox: ~8x slower than normal.
SPDY enabled Chromium 27: ~6x slower than normal.
Did enabling SPDY break TCP window scaling, or did something else go wrong? Download speeds were perfect the last time you enabled SPDY (but it had that hanging issue).
In Firefox (tested 18.0.2 release, 19.0 release build1, 21.0a1 nightly) everything now downloads extremely slow, unless I disable SPDY in about:config. Marginally faster in Chromium 27, but still extremely slow.
SPDY disabled in Firefox: ~4x slower than normal.
SPDY enabled in Firefox: ~8x slower than normal.
SPDY enabled Chromium 27: ~6x slower than normal.
Did enabling SPDY break TCP window scaling, or did something else go wrong? Download speeds were perfect the last time you enabled SPDY (but it had that hanging issue).
Are you judging from pool downloads or images?
So far I've seen a speed improvement...
So far I've seen a speed improvement...
Akio-sama
I'm not sure.