Quote:
Originally Posted by pspzockerscene
In my tests this worked great - please test it 
|
Yup, works great for me, too. Tested with 2 accounts and 2 IPs enabled for ul.to.
Both free accounts used my direct connection, and an unregistered download started on direct and proxy. (Since I have unregistered in the same grouping as account in the account usage rules.)
No extra captchas displayed after any of them finished.
However, when it came time to start the next round of downloads, only the free accounts started (both on the direct connection again, as they should). Unregistered on direct and proxy didn't start then.
timeline:
- time 0: 4 DLs start: 2 free accounts (direct), unregistered (direct and proxy)
- all of those DLs finish
- time +3H from time 0: 2 free accounts start (direct). (problem: unregistered should have started now but didn't)
- time +3H 25mins from time0: one of those free account finishes, triggering an unregistered download to start on the proxy.
- the other free account finishes, but still no unregistered (direct) download starts
current state: unregistered running on proxy, nothing running on direct (even though it should be out of waittime for unregistered.)
A link is sitting there showing 2h:25m reconnect-waittime "Download limit has been reached" gateway=direct, mode=free account: (one that is still on cooldown).
I guess the "download mode" column isn't very meaningful for downloads that are in reconnect-waittime, because after resetting that link, it's showing gw=direct, mode=Free, but the waittime is 2h:44min now.
Checking with a browser, an unregistered download was possible. (too bad you can't browser-check without actually starting a download and using up your slot.)
So it looks like free accounts are getting used correctly, but unregistered is getting mishandled.
I haven't hit the per-IP cap for free accounts yet, so I still haven't tested what happens then.