Originally Posted by rver01

i have an uploaded.to premium account. All my downloads on this service are done using JD2.
Yesterday, the downloads have stopped (traffic exhausted). I have taken an extension of 100 Gbytes which is now exhausted.

Have you tried via web browser, to make sure it's not a problem with your account or the site?

[pspzockerscene]

@rver01
Try via browser - can you download there?

@Llamatron
I changed the waittime back to 3 hours - update is already released.

[rver01]

I have the same problem via the browser. hence the message in my mail.
For now, the download are working again. I suppose that my traffic allowance is upgraded every day and that I am in the next day, which mean that my problem will reappear shortly.

I have also send a request to uploaded, bit not yet received an answer.

[pspzockerscene]

As long as its the same via browser it is no JD issue and you will have to contact- and sort that out with the uploaded support!

Originally Posted by pspzockerscene

@Llamatron
I changed the waittime back to 3 hours - update is already released.

Did you change it to 3 hours from the END of the previous download? Because that's the behaviour I'm seeing right now. (#1 and #2 checked, free account in use.)

ul.to allows a new download to start 3 hours from the START of the previous download, for unregistered and for free accounts.

I know you have to keep track of over 3000 plugins, so it's got to be hard to remember which hoster works which way. I mostly download from only 4.

I was able to work around it (get JD2 to start a download instead of waiting for another 2h:45) by adding a second free account. I'll see if option #1 lets another download start right after one ends, by switching accounts.

[pspzockerscene]

The waittime was always from the end of the peviously finished download.
Are you really sure that they count from the start?
If not, I can at least make a "BETA" setting so you/we can easily do further testing without destroying the plugin for other users!

Again as said before, no need to change 3000 plugins as uploaded is the only host with such special rules.
For most of the others, the hosts will return the remaining waittime in their html code before having to enter a captcha so the waittime JD shows will usually be correct.

Originally Posted by pspzockerscene

The waittime was always from the end of the peviously finished download.

I think before the uploaded.to plugin update, with #1 and #2 checked, a download would finish and the wait time would go to time until start + 3h. Often only 15 mins, since a download of a 660MB file takes just over 2.5 hours at 70kB/s.

Are you really sure that they count from the start?
If not, I can at least make a "BETA" setting so you/we can easily do further testing without destroying the plugin for other users!

Yes, I'm 100% sure. It's been this way for a couple months at least, since before I started using JD2. Since I had to keep track of the timing myself to start browser DLs, it was certainly something I remembered. And since I don't use a captcha exchange service in JD2, I'm also 100% sure that it still works this way, because downloads only start when I put in a captcha.

Most of the ul.to downloads I've made have been within an hour of the previous one finishing, because most of the files I've DLed have been big enough to run for over 2 hours. It's very noticeable when you load a small file and then ul.to is idle for a couple hours.

When I didn't have the "experimental waittime" setting enabled, and was getting spammed every 5 minutes by ul.to captchas when it wasn't downloading, it really made me notice exactly how the timing worked.

Again as said before, no need to change 3000 plugins as uploaded is the only host with such special rules.

I was just trying to say I understand why you missed what I was saying earlier, about how the timer counts from the start of the previous download.

I have an easy time remembering exactly how all 4 hosters I use work, but I'd miss things too if I had 3000 hosters to think about, and a boatload of forum conversations to bounce between.

After latest update Downloads tab shows Hoster name as jdownloader.org for uploaded links. Links are alive and open in browser works correctly. Also linkgrabber no longer recognizes uploaded links.
**External links are only visible to Support Staff****External links are only visible to Support Staff**
Win 7 spi jre 8u11 x64.
Thank you.

[pspzockerscene]

Merged ul threads.

@zele
Your link works fine here.
What do you mean by "no longer regognized..."?

[pspzockerscene]

@Llamatron
For the next update (available in 10 minutes):
-Fixed small bug
-Improved overrall remaining waittime calculation
-Time nuw runs time from the timestamp when the download was started! Thanks for the hint!

GreeZ psp

Ok. I'll make sure it works with #1 and #2 enabled, then test with them disabled to make sure the captcha-every-5-minutes spam is gone for the out-of-the-box default setup.

I still have many days worth of ul.to links queued up.

edit: test result: #1 & #2 checked: wait time calculated perfectly. Well, it's going to wait almost exactly one minute longer than needed. Only mentioning this since you're looking at it anyway, since one minute doesn't usually matter.

My previous download was created on disk at 17:23:14UTC, while "now + waittime" is 20:24:13UTC [1]. I think the 3 hour interval is checked at the end of the 30sec timer after solving the captcha. I think I remember doing this in a web browser: click to bring up the captcha at about 2h:59min. solve it. By the time ul.to is done with the extra waiting, 3h have passed so the download can start.

If you think you can change the code to start the captcha process at 2:59:35 or something without risking going too soon, then go for it. If it's simpler, cleaner, safer, and more maintainable not to do that, I guess don't bother

[1] I calculated with date -d 'now + 35min + 40sec', hit return just as the waittime in the GUI crosses 35:40.

Same problem as Zele here. And my uploaded premiun account is gone.

Originally Posted by Llamatron

Ok. I'll make sure it works with #1 and #2 enabled, then test with them disabled to make sure the captcha-every-5-minutes spam is gone for the out-of-the-box default setup.

It looks like switching free accounts enables back-to-back downloads on the same IP.

I tested with #1 and #2 both unchecked (before starting a ul.to download). So:

1. uncheck #1 and #2, before the captcha got displayed for the next ul.to link (to make sure these options would be in effect for this download, to control behaviour at the end.)
2. start a download of a 431MiB file
3. download finishes after about 1:50, so I'd normally have a 1:10 wait time
4. JD2 tries to download the next ul.to file right away: a captcha pops up
5. I solve it (fairly sure I got it correct), but the DL doesn't start after the 30 sec countdown finishes. I think this captcha was for a download with the same account that just finished, as that explains being blocked.
6. ANOTHER captcha pops up. (I assume from the other account)
7. I solve it, and the download starts!

file timestamps to prove I started 2 downloads less than 3 hours apart:
stat file*
File: ‘file1’
...
Access: 2015-03-28 20:25:53.000000000 +0000
Modify: 2015-03-28 22:11:14.345000000 +0000
...
File: ‘file2.part’
Access: 2015-03-28 22:12:26.558114581 +0000
Modify: 2015-03-28 22:31:15.048090417 +0000 # now
...

Since I mount my filesystems with noatime, "Access" is set when the file was first created, and not changed after. "Modify" records the last write. For file1, which finished, the mod time is when the DL finished (the last write.)

And a log, in case anyone wants to check which account actually got used:
28.03.15 17.22.18to28.03.15 18.21.24 jdlog://2233917486241/


And yes, I'm 100% sure my IP did not change. Other downloads stayed running, and my IP right now is the same as it always is.

The plugin options/help should probably suggest making multiple ul.to free accounts, since it seems to work perfectly. Probably each account has its own 3h timer.

Also, I will test with only a single free account enabled, to see how bad the captcha spam is. With a single free account, the 3h from start of previous download wait-time calculation should probably just be on by default, and not marked as experimental. I don't think switching between a free account and unregistered helped at all for ul.to.

edit: we should move the plugin dev chat to a new thread, so it's not mixed in with support requests.

https://board.jdownloader.org/showth...755#post328755

@Zascan: Do you think JD2 did something that used up your account in a way you weren't expecting? If so, post details. Either that or you're posting as a warning to others that ul.to premium might be having glitches ATM?

There's nothing JD2 can do to work around your account not working in a web browser.

edit2: Apparently my attempt to start a new thread about ul.to got ninja-moved back into this thread automatically. It was extra confusing for a while, because the new thread showed up in my subscribed threads list, and clicking it gave me a "permission denied to view this thread".

For a while I thought I must have accidentally replied instead of posting a new thread, so I tried again and editted this message down to nothing. Good thing there's edit history.

Anyway, back to ul.to:


Update: ul.to parallel DLs are possible. Just use multiple free accounts.

I just tried from a browser with a 3rd account. I'm downloading a file in my browser while JD2 is still downloading on another account.

My guess is that free accounts will each have their own 3h interval, and are completely independant regardless of what IP you're coming from.

I guess they do this to make it not suck for multiple people behind a single NAT firewall. I almost feel bad exploiting that... almost. Do hosters typically monitor for anomalous usage? I don't want them to notice and change their setup by over-doing it with 50 accounts.

update2: there must be some kind of per-IP cap, since I did manage to hit a block. Even a freshly created accound isn't letting me download, even via a web browser.

Oh, but while I was editting this, I can DL again. I'm not sure exactly how long I was blocked for, but at least 3 hours. I wasn't trying the whole time, in case it was going to be longer. So yeah, probably some kind of cap that doesn't care about accounts, on top of the per-account 3 hour thing. I started a parallel DL in a web browser, and it worked fine using a diff. account from the one JD2 picked.

During the time I was blocked, JD2 spammed captchas every 5 minutes for one of my accounts, and longer intervals for my other accounts.

Hi Llamatron. What i mean is that JD2 don't recognize uploaded links. If i try to upload links from linkcrypt or relink, it works with all the others server links, but uploaded links doesn't show. With individual Links happens that JD2 show them as if they are offline, even if links are alive and open in browser works correctly. And is not that i have lost my uploaded account, is just that it has been remove from JD2 settings and if i try to add again, uploaded doesn't show in the server list.
Sorry but i can't explain better. I made a new post on spanish support but nobody answer yet.
Thank you

Originally Posted by zascan

Hi Llamatron. What i mean is that JD2 don't recognize uploaded links. If i try to upload links from linkcrypt or relink, it works with all the others server links, but uploaded links doesn't show. With individual Links happens that JD2 show them as if they are offline, even if links are alive and open in browser works correctly. And is not that i have lost my uploaded account, is just that it has been remove from JD2 settings and if i try to add again, uploaded doesn't show in the server list.
Sorry but i can't explain better. I made a new post on spanish support but nobody answer yet.
Thank you

I think I understand what you're saying. When JD2 checks added links, it thinks ul.to links are invalid / expired or something, and they never show up in the linkgrabber?

Have you tried getting all the way to ul.to in your web browser, for a file you want, and then copying the URL from there? Maybe something is going wrong for ul.to when you give JD2 the linkcrypt or relink URL.


I'm still pretty new to JD2 myself, and I'm not a dev so I can't do much more than that. To debug it, they're going to need a log, so click:

help->create a log

and then post the jdlog:// url here. That way the JD devs can see exactly what was happening. (logs aren't public, so only official devs will see the filenames you were downloading, and your account info.) Once you post that, you'll be all set for the official support people to help you.

Originally Posted by Llamatron

I think I understand what you're saying. When JD2 checks added links, it thinks ul.to links are invalid / expired or something, and they never show up in the linkgrabber?

When add a DLC, uploaded links are not shown, they simply disappear all other links from other server (offline and inline) are there, but no uploaded links.

Originally Posted by Llamatron

Have you tried getting all the way to ul.to in your web browser, for a file you want, and then copying the URL from there? Maybe something is going wrong for ul.to when you give JD2 the linkcrypt or relink URL.

Yes, i tried that, and when i add the URL they are shown as offline, even if they are alive and open in browser works correctly.

I made a log, hope devs can help me.
Thank you for your help by the way.

jdlog://2863917486241/

[tony2long]

Your log shows many duplicate files (e.g. file-id: 855iemo8), so no new link was added.
To proof it, open in browser, copy file name, use it to search in JD.

Your log also shows that you downloaded many files with your premium account, so it's not gone.

Ok, i have uninstalled and installed again JD2 and now it works.

[pspzockerscene]

@Llamatron
1. The behavior you posted with these settings unchecked is exactly correct:
JD tries via account --> Limit --> Next account --> Limit --> next account

With the settings enabled, JD compares the timestamps on the account (or also on the plugin itself) before asking for captchas.

From what you write it looks as if it is all working as desired
EDIT
By the way, the additional one minute waittime was intended...if you know I can change it to 10 seconds or so but I don't know how exact the uploaded system counts

GreeZ psp

Originally Posted by pspzockerscene

@Llamatron
1. The behavior you posted with these settings unchecked is exactly correct:
JD tries via account --> Limit --> Next account --> Limit --> next account

With the settings enabled, JD compares the timestamps on the account (or also on the plugin itself) before asking for captchas.

From what you write it looks as if it is all working as desired

Yes, I think so. With the settings unchecked, the timeout on one of the accounts (the first one I added a while ago, not from this recent testing) usually is set to 5 minutes after a failed attempt. This is what makes JD2 horrible to use (captcha spam) with ul.to free accounts out of the box. (the waittime options default to off. Changing them to on-by-default would help.)

One thing that isn't working as desired is trying to use multiple accounts in parallel, like the datafile.com plugin does. The limits for this need to be explored more, but the worst that happens if you do too much in parallel is that downloads from your IP get blocked for something like 3 hours (possibly from the end of one of the downloads, rather than the usual start.) I changed my log settings to keep 60 days of old logs, but I need to do the parallel DLs from inside JD2 for it to all get logged in the same place. I'd rather just have logs than have to manually make notes of when every DL started.

Also, with multiple connections enabled, ul.to won't start a download on my proxied-to-another-IP connection unless I uncheck "direct" temporarily, so it sees the proxy as the only available connection, and then realizes it's not downloading on it. (even though there's still a "direct" download running.)

datafile and rapidgator were leaving the extra connection underutilized, too. k2s seemed to be starting new DLs on it as soon as possible, though.

EDIT
By the way, the additional one minute waittime was intended...if you know I can change it to 10 seconds or so but I don't know how exact the uploaded system counts

GreeZ psp

I think 0 seconds is enough. Even negative 30 seconds would work, because I think the 180min limit is checked at the end of the 30-sec wait after bringing up the captcha.

I'd recommend 0 seconds, though, because being a few seconds early is WAY worse than a few seconds late. The captcha wait-time alone is enough to make sure the next download starts after the 180min limit, with 30 seconds of safety margin.

[pspzockerscene]

1. As said, the uploaded plugin is not designed to start multiple free downloads at all but with the new JD2 controlling every account has its own download slots (jd intern) so that makes it possible - which is fine!
For the uploaded unregistered free mode, it is limited to max 1 download at the moment!

2. Okay, I removed the 60 extra seconds...waiting for your feedback then
And the idea that they probably check the waittime after the captcha is good!

GreeZ psp

Originally Posted by pspzockerscene

1. As said, the uploaded plugin is not designed to start multiple free downloads at all but with the new JD2 controlling every account has its own download slots (jd intern) so that makes it possible - which is fine!

Ah, I see, so JD2 kind of runs multiple instances of the plugin, one for each account.

That's not what JD2 is doing for me, in practice, though. I have waittime options #1 and #2 checked. I've never seen JD2 even try a second download on the same IP when one is already running. (with #1 and #2 unchecked, too.) And to get it to start one on the proxy connection, I have to disable my "direct" connection, so the proxy i the only connection left.

I haven't restarted JD2 for over 24 hours, so maybe an on-the-fly plugin update is behaving badly, and will work right after a restart. (Or maybe I confused something when I added a connection to a simple proxy that didn't support HTTPS, without first disabling HTTPS in the ul.to and k2s.cc plugins. I also tried adding a "direct gateway" and a "socks" connection, but neither of those worked. I'll post a new thread about that. But after messing around with a bunch of stuff, I went with tinyproxy on the non-default gateway on my network.)

Hmm, I guess I could run multiple proxies to trick JD2 into doing more parallel DLs, but much better to just get it working the right way.

2. Okay, I removed the 60 extra seconds...waiting for your feedback then
And the idea that they probably check the waittime after the captcha is good!

I'm pretty sure they don't check the waittime until after the 30-sec countdown, so even if you solve the captcha really fast, you still have that margin. I think that's what i remember figuring out once, after setting a timer for myself before I was using JD2.

[pspzockerscene]

As said, inside the uploaded.net plugin free downloads are limited to 1.
Same way it was with datafile but I did change that.

Originally Posted by pspzockerscene

As said, inside the uploaded.net plugin free downloads are limited to 1.
Same way it was with datafile but I did change that.

Did you see my post earlier about ul.to allowing parallel downloads from the same IP, on different accounts?

I tried to start a new thread for this topic, but the forum auto-moved my post into this thread: https://board.jdownloader.org/showth...745#post328745

From a single IP, it's possible to actually have 3 or 4 downloads running at once, not just skip wait times between downloads, by using multiple free accounts. There's still some kind of limit you can run into, which I guess is per-IP, but there are still huge throughput gains easily available.


Also, I just restarted JD2. Even with a clean restart, it won't start a download from my proxy while one is running from direct connection. So is it just that plugin limit being set to 1 that's preventing separate downloads on separate connections, too? Because even without this newly-discovered ability to download from ul.to in parallel on a single IP, that was limiting JD2's multi-connection capability.

[pspzockerscene]

Hi
1. As said, unregistered mode is hardcoded limited to 1 - so are free accounts.
2. Because I never use proxies I can't really tell you anything about JDs behavior with proxies but I guess every connection has its own limits at least that would make sense and no, plugins don't interfere with that!

Then again, how did you start simultan downloads?
Is it also possible without using multiple free accounts (as unregistered user)?
How long is the minimum waittime between downloadstarts?

GreeZ psp

Originally Posted by pspzockerscene

Hi
1. As said, unregistered mode is hardcoded limited to 1 - so are free accounts.

This is why I'm telling you it shouldn't be... The current wait-time behaviour is perfect for each account separately, though.

2. Because I never use proxies I can't really tell you anything about JDs behavior with proxies but I guess every connection has its own limits at least that would make sense and no, plugins don't interfere with that!

Ok, well something is putting an unnecessary limit on starting dowloads through different connections, because JD2 doesn't even try for uploaded.net. I think k2s does work, and I have gotten rapidgator to start parallel DLs after some prodding (enable / disable one connection or the other.)

If you can connect multiple computers to your cable modem or DSL and your ISP gives them each a different global IP address, then you can run tinyproxy on one, and point JD2 to it. (Only works if you get two real IPs, not _http://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces 10.*, 192.168.*, or 172.16.0.0/12 behind a NAT firewall like some ISPs hand out. Luckily mine hands out real IPs for up to a few connected machines that aren't behind a NAT firewall, aka router.)

Then again, how did you start simultan downloads?
Is it also possible without using multiple free accounts (as unregistered user)?

Unregistered no. Free account yes. (Actually, you can do unregistered at the same time as a free account, but you need at least one free account to get any parallelism. And unregistered has a gimped bandwidth, so it's best to just let users add enough free accounts. With a free email provider that lets you add aliases that all come to the same inbox, like gmx.com, it's pretty easy to make several accounts.)

How long is the minimum waittime between downloadstarts?

zero seconds, AFAIK. Like I said in https://board.jdownloader.org/showthread.php?p=328745, every account appears to have its own 3h timer.

I tested with firefox's "new private window", so I could log in on one ul.to account while making another. relogging to change accounts after starting a download works, too.

Or just browser-login with a different account than the one JD2 is using.

[pspzockerscene]

Hm some time ago this was different - I'm sure!
...but anyways - if you are right the current handling should be fine for multiple accounts and there should be no issues!

About multiple connections:
Jiaz is the man for that - he can answer all your questions about this

GreeZ psp

Originally Posted by pspzockerscene

Hm some time ago this was different - I'm sure!
...but anyways - if you are right the current handling should be fine for multiple accounts and there should be no issues!

You mean after you lift the hardcoded one download at a time across all free accounts limit it currently has, right?

But then yes, I think the current wait-time handling should work well. If it already tracks wait-time per account, then it should be able to avoid wasted captchas by not trying accounts that are still on cooldown.

[pspzockerscene]

No why lift it?
...or were you able to start multiple free downloads with ONE account?
At the moment:
Unregistered: 1
Free account: 1 (per account)

Originally Posted by pspzockerscene

...or were you able to start multiple free downloads with ONE account?

no

At the moment:
Unregistered: 1
Free account: 1 (per account)

Well JD2 is only ever doing one download globally for me. Not per-account or per-IP, just one, ever. It can start another one right away after that finishes, but won't start a new one while one is still running.

So maybe I guessed wrong about the cause being the plugin's hardcoded limit applying across accounts, instead of per account. But there's a problem somewhere. Logs for this will be in with the datafile.com logs I PM you, if I can figure out how to add an attachment to a PM.

I have
max chunks = 1
max simultaneous DLs = 20
max per hoster = 5

[pspzockerscene]

Hm didnt it work fine for other plugins with 1 per account?
I m not sure about that either!

Let's get the ul.to plugin working for parallel downloads using multiple accounts on one IP. Then worry about using multiple connections / triggering reconnects when hitting a per-IP instead of per-account limit.

[pspzockerscene]

Enabled simultan usage of uploaded accounts - try again after the next update!
For me it worked fine.

Originally Posted by pspzockerscene

Enabled simultan usage of uploaded accounts - try again after the next update!
For me it worked fine.

Working perfectly so far. All 5 accounts queued up a download. They all finished before 3 hours, and all 5 accounts queued up a second download at 3 hours.

They all used my direct connection, not via the proxy, which is the desired behaviour. I'll have to see what happens if I run into a per-IP cap. Hopefully attempts that run into unexpected waittime on the primary connection will fall back to trying other connections, in case it's an IP block rather than the account being used outside of JD2.

Setting the "account usage rules" to bump unregistered up into the same group as my free accounts, JD2 popped up a download start on each of my 2 connections (direct and proxy). The "direct" one disabled itself right away, without even a captcha. (I'm not sure if that's correct. I thought ul.to gave unregistered it's own 3hour timer, like it was an account.)

Thanks for taking the time to get this plugin working really nicely, based on my testing of hoster behaviour.

Oh, another thing I could do for testing: use JD2's "pause" button to make downloads run so slowly that the 3h timer would be up while a download is still running. There aren't per-hoster throttles, though. I don't have QoS throttling / priority set up on my router, either, so it'd be an effort to set that up. :/

Per-hoster rate limits is probably only useful for testing, so not maybe worth implementing in JD2. Although if you were confident your connection was stable, you could use it to get a crapton of datafile.com downloads running, starting one per hour, by preventing the earlier starts from finishing and triggering the block.

[pspzockerscene]

Per Hoster or individual link speedlimit will be available in the future - but not exactly the near future!
Thanks for your feedback!

Ok, so after DLing 5 files in parallel, then another 5 after 3 hours, the attempt to start another set failed.

Browser testing with one of the 5 free accounts confirms that it's blocked on the IP JD2 used. However, the same account is fine to download on another IP, but JD2 didn't try.

31.03.15 12.06.59to31.03.15 17.45.39 jdlog://5652027486241/

Look at around 3:08 to 3:10pm in the log for the attempt to connect.

The 5 accounts each put link a link into captcha state, IIRC, but after solving them, the DLs didn't start. (since that IP was blocked.) The account manager showed all 5 free accounts temporarily disabled for 5 minutes, with an unkown error.

Then after 5 minutes, without another ul.to connection attempt, the accounts went to "ok", and reconnect-waittime appeared in the ETA column for 3 of the 5 links. Gateway = direct for all 5, and Download Mode = different account for each of the 5 next ul.to links in my list. The reconnect-waittime is counting down to 3 hours from when the captchas came up and they got temp-disabled. However, the waittime in the ETA column is EXACTLY the same for all 3 accounts (and for unregistered via the proxy, which makes no sense for that to be linked). Each account should have a separate waittime. I assume this is just the GUI failing to display different waittimes from the same hoster well.

Another "unregistered" download was able to start, but it hasn't shown up in the log file. I think the logging code must do some buffering so lines from different threads don't get mixed together, but the filename and the url from the currently running ul.to download don't appear in uploaded.to.log.0 at all.

IDK if any relevant stuff about errors with the 5 accounts is missing from the logs, too.


Oh, important point: browser testing showed that while the account I tested was blocked from the IP JD2 used it on, the other IP I have access to was able to download a file with that account.

So when the ul.to plugin hits an error trying to start an account it expects should be able to start, it should do whatever is needed to get JD2 to try the same account on another connection, before giving up on the account for 3 hours.

[pspzockerscene]

Reconnect waittimes sit on the hoster and also each account has only one timestamp of the last download which is not depending on the connection.
What you re trying to do here is simply crossing the boundaries of what is possible with JD.
JDownloader is made to improve free- and premium mode of one click hosters and direct links but the cases you re doing here are quite abnormal.

Also, whenever a reconnect wait is shown, it sits on the host and all links of a host (excluding the ones which are still being downloaded at that time) get the wait.

The "Unknown error" in the account is just a bug instead of displaying the real message but as you correctly discovered, after 5 minutes the accounts will get an ok state again and new download attempts can be performed - if the waittime still exists the account will got into error state again.
If you want I can also set the timeout to the total waittime so in such a case accounts would be temporarily disabled (yelloe color) for 3 hours instead of 5 minutes.

I agree that JD should try the other connections but this is a thing you have to ask jiaz.
Its also no uploaded issue but more (if there is an issue...) a controlling design issue/bug.

GreeZ psp

Originally Posted by pspzockerscene

I agree that JD should try the other connections but this is a thing you have to ask jiaz.
Its also no uploaded issue but more (if there is an issue...) a controlling design issue/bug.

Ok, thanks for the quick explanation on JD2's design for tracking wait-times.

So it's sort of a design limitation, preventing trying other connections, I guess.

It's a limitation that only affects ul.to and any other rare hosters with a limit model that mostly tracks timers per account, not per client IP. So it affects ul.to, but getting the ideal behaviour would require core changes, not just this plugin, right?