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.