[ElCho]

Hello, I have realized of this behavior long time ago now and finally had the time to report it. Basically, while in "free mode", each time JD2 stops downloading a file because a "quota" or an "account missing" related message is shown, stopping and restarting the download queue will have not effect at all; forcing downloads on spare files neither. JD2 will not retry downloading any MEGA files, even if I have tried some workaround after seeing the messages, like getting a new IP or trying with a new proxy's IP. Under such circumstances, I have found only two things will make JD2 effectively retries to download files:

1- Restarting JD2. This way, it will retry to download the files after starting the queue again, or any of the files individually. This will last till one of the previously mentioned messages shows up again.

2- Resetting any MEGA's link. This have the advantage of not having to restart the whole program, but at the expense of reverting the files' progress to "0%". So, in order to use this workaround but without getting any partially downloaded link reset, I added a "disposable" MEGA link, which I can reset freely, just to trigger the rest of downloads' retries after some of the messages show up.

Is there a chance you make JD2 retries to download MEGA's links in such conditions, without having to resort to said workarounds?

Thanks.

[pspzockerscene]

Hi,

1. You'd have to use a proper reconnect script in JD so it knows that you have a new IP (e.g. when switching from one to another proxy) - then a restart wouldn't be required.

2. JD is supposed to auto-handle this.
Either our handling is wrong or you did perform an IP-change "outside" JD without using a reconnect script -> JD never checks for a changed IP -> Limit never gets removed until timeout is reached.

Other than that you could always use EventScripter scripts to build workarounds for such situations but it really shouldn't be required!

-psp-

[ElCho]

In the first video, I show you an example of what I talked about in point number "1":

**External links are only visible to Support Staff****External links are only visible to Support Staff**

If there is at least "one" of the "limited" to download files in the queue, and it is started
before any of those who can actually be downloaded ("non-limited" ones), they will be wrongfully
limited by JD2 as well. Disabling the problematic file and trying again will have not effect at all;
the "Bandwidth..." (or "Skipped - Account is Missing" in other cases) message will be keep showing up.
Then, after restarting JD2 and disabling the "limited file" so it doesn't trigger the limitation again,
the non-limited files can be downlaoded normally (either by starting the queue or individually).

In the second video, I show you an example of what I talked about in point number "2":

**External links are only visible to Support Staff****External links are only visible to Support Staff**

In this case, after trying to initiate the download queue and even after disabling it, a "limited" file
will keep triggering the caution message for the rest of "non-limited" files as well. So, to avoid using
the "restart" workaround, I simply have to reset a disposable random file I left around just for these cases,
which will somehow remove the incorrectly limtated downloadable files.

Note that in none of the cases I tried to use a new IP, or a new proxy connection.

Would it be feasible JD2 handles these kind of cases correctly? I mean, applying the limitation and showing the
resultant message, but specifically only for the files that actually are somehow limited to be downloaded in free
mode; while, at the same time, leaving free of such inconvenience those who can be downloaded normally.

Thanks.

[mgpai]

One workaround is to set download priority based on host + file size, either using packagizer rule or script. Set higher priority for smaller size files, and lower priority for large size files.

[pspzockerscene]

@ElCho
So you are saying that this limit is based on each file and not global?
This would actually mean that even using a new IP wouldn't allow the download of such files, am I right?
This would also mean that our current handling would definitely be wrong!

How long do you usually have to wait so that such "limit exceeded" files get unblocked?
Do you have example URLs for such files for me?

@mgpai
We'll try to solve this without workarounds.
Are you familiar with the MEGA system?

I'm using mega only sometimes so I don't really know their limits ...

-psp-

[mgpai]

Originally Posted by pspzockerscene

Are you familiar with the MEGA system?

As per their FAQ, seems it depends on various factors:

Transfer quota is provided over a dynamic sliding window that is typically less than 24 hours but depends on time of day, ISP, country etc. Once you exhaust your Free account’s allowance you will have to wait to accrue more

I downloaded from mega a few months ago using their app. For me the quota was 2GB/ 6hours. Seems they use more than just the IP to identify the downloader, because the wait time did not change even with a new IP. Their app shows the usage for the last 6 hours, while the control panel on the website shows just the used total.

If the size of the file you are about to download is more than the available quota, the browser will allow the download to start, but will warn that the download might be interrupted. The app on the other hand will stop the download and display a pop-up with an offer to upgrade to premium plans. The download will be automatically resumed when the quota is replenished.

[pspzockerscene]

Ohh very confusing.
Thanks for quoting their FAQ.
I admit I didn't check it as I assumed they wouldn't give out any of that information.

... so this means if we knew the quota we could decide based on that but also, if a limit is reached and they really do not return the reason there is only one way: Add a setting so the user can decide what to do whenever such a limit is reached e.g. set wait status only on current file or reconnect.

Jiaz will for sure also check this once he finds the time and we'll figure out what to improve.

-psp-

[ElCho]

Well, as you said before, it is really confusing and it seems there is a diversity of factors intervening regarding how the downloading limit is applied. Out of experience, I could tell you that while sometimes I can't download determined files, I still can download others; as is shown on the previous videos. And for those which can't be downloaded at a given time, some could still be started by getting a new IP, while others will keep refusing to be downloaded. The limitation related messages will also vary (even for the same files), according to the used IPs as well; sometimes the "Bandwidth..." one will be shown, while others the "Skipped..." one. Then, I noticed that for those files who kept refusing to be downloaded, I eventually could download them after a few days or weeks of random attempts. And those files which previously allowed to be downloaded right away while others don't, could refuse to be downloaded once again anytime. Finally, while having just a few specific files who kept showing the limitation message, I could keep downloading hundreds of GBs at the same time; and eventually downloading those which previously refused after some days. So, it's really a mess to get a common pattern out of this.

Anyway, beyond how the MEGA's limitation works, the thing is JD2 should be able to deliver the exact reason to why a specific file couldn't be downloaded a given time. And each file should get its own "status" checking, so there is no files getting a "replicated" false positive limitation message, inposed by another file which has a real limitation status. That way, from a bunch of files, eventually some could be downloaded, while others could not, but since each file will show its real state, no reset/restarts or other workarounds will be needed at all.

In case you need some links, I have some that despite being currently limited, they weren't a few days ago when I could download them. And might be able to find some that can still be downloaded, coexisting with the limited ones. But will take me sometime to figure out which is which.

[pspzockerscene]

Originally Posted by ElCho

sometimes the "Bandwidth..." one will be shown, while others the "Skipped..." one.

As far as I know, files > 5GB can only be downloaded with a MEGA free account which means if you do not have such an account in JD, you will get that "skipped" message.

Originally Posted by ElCho

Anyway, beyond how the MEGA's limitation works, the thing is JD2 should be able to deliver the exact reason to why a specific file couldn't be downloaded a given time. And each file should get its own "status" checking, so there is no files getting a "replicated" false positive limitation message, inposed by another file which has a real limitation status. That way, from a bunch of files, eventually some could be downloaded, while others could not, but since each file will show its real state, no reset/restarts or other workarounds will be needed at all.

Yap agree that should be improved.
I will have to wait for Jiaz' response on that ...

Originally Posted by ElCho

In case you need some links, I have some that despite being currently limited, they weren't a few days ago when I could download them. And might be able to find some that can still be downloaded, coexisting with the limited ones. But will take me sometime to figure out which is which.

Yes, please ...

-psp-

[ElCho]

As far as I know, files > 5GB can only be downloaded with a MEGA free account which means if you do not have such an account in JD, you will get that "skipped" message.

Well, that's certainly not the case, not for all the files or all the time at least. I do know there is a known limit regarding bandwidth use, it being a "5 GB" daily cap, but even that's a relative one. In the first video I uploaded, you can see how I'm still able to download two files which are beyond this "5 GB" cap, and not only I didn't get any "quota" related message, but neither a "skipped" related one. Although as I commented earlier, isn't something like a fixed rule at all, so I could still get one of those messages while trying to download any of the same files at another time.

These are the same files as shown on the above videos; they weren't limited at the time I downloaded them, but they are now:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

**External links are only visible to Support Staff****External links are only visible to Support Staff**

Then, two new ones, which despite being quite big and being stored also on "free" accounts, can be downloaded at the time I'm making this post:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

**External links are only visible to Support Staff****External links are only visible to Support Staff**

And a new video, which shows the explained above:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

I noticed that the limitation's messages could vary, according to the used IP. Thus, for the same files, using a determined IP will show the "Bandwidth..." one; while if using a different IP, the "Skipped..." one will be shown. That's at least one of the diverse factors they are using to limit the downloads or not. But as shown before, it seems the limitation is also tied to the files themselves somehow, since those which can't be downloaded at a given time, will retain the same condition, even if moved to another account or trying with different IPs. But, at the same time, others could still be downloaded.

[pspzockerscene]

You are absolutely right!
I've just been experimenting with this and working on it for an hour - here is what I've changed for the next update:
- Limited max. limit waittime to 30 minutes
- Limit waittime can now be defined by the user
- Limit mode can now be defined by the user: What you'd probably want to use is: "Per file: Wait"
- Account used traffic/quota now gets displayed in account manager



Happy testing after the next update:

Wartest du auf einen angekündigten Bugfix oder ein neues Feature?
Updates werden nicht immer sofort bereitgestellt!
Bitte lies unser Update FAQ! | Please read our Update FAQ!
---
Are you waiting for recently announced changes to get released?
Updates to not necessarily get released immediately!
Bitte lies unser Update FAQ! | Please read our Update FAQ!

-psp-

[ElCho]

Excellent! The main issue I reported is now fixed, using the "per file" approach.

Every now and then I use an unofficial MEGA's download tool, which despite being also
affected by transfer limits, sometimes it is still able to somehow start and make some
progress on files for which JD2 as well as Chrome browser show the limitation message
right away; and without IPs changing involved. It is this one:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

By the way, I see the "concurrent decryption" option isn't available anymore. Will it be
added again in a next update?

Thanks.

[pspzockerscene]

Originally Posted by ElCho

Excellent! The main issue I reported is now fixed, using the "per file" approach.

Thanks for your feedback!

Originally Posted by ElCho

Every now and then I use an unofficial MEGA's download tool, which despite being also
affected by transfer limits, sometimes it is still able to somehow start and make some
progress on files for which JD2 as well as Chrome browser show the limitation message
right away; and without IPs changing involved. It is this one:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

Sorry I won't be finding time to investivate this.
Without checking it, I can only imagine that it's the time-difference that made it work for you via that tool but not via JD.
See - even if JD waits 15 minutes, sometimes you can start new downloads just 1 minute after the "limit" message appears but sometimes you have to wait longer so it's hard to tell.
... but if, however, you are permanently getting limit messages for files in JD but you can consistently still start downloads with that tool, we should look into that.

Originally Posted by ElCho

By the way, I see the "concurrent decryption" option isn't available anymore. Will it be
added again in a next update?

Sorry I've removed that option by mistake - the functionality is still there.
The option will be back with the next update!

Wartest du auf einen angekündigten Bugfix oder ein neues Feature?
Updates werden nicht immer sofort bereitgestellt!
Bitte lies unser Update FAQ! | Please read our Update FAQ!
---
Are you waiting for recently announced changes to get released?
Updates to not necessarily get released immediately!
Bitte lies unser Update FAQ! | Please read our Update FAQ!

-psp-

[ElCho]

Sorry I won't be finding time to investivate this.
Without checking it, I can only imagine that it's the time-difference that made it work for you via that tool but not via JD.
See - even if JD waits 15 minutes, sometimes you can start new downloads just 1 minute after the "limit" message appears but sometimes you have to wait longer so it's hard to tell.
... but if, however, you are permanently getting limit messages for files in JD but you can consistently still start downloads with that tool, we should look into that.

It's OK, I just mentioned it in case JD2 could be improved regarding how it deals with certain links that could still be downloaded using the other tool, but for which it still shows up the limitation message. As far as I know, it's not about a time difference, but MEGA's servers allowing that tool and not JD2 simultaneously, since I just tried it with a few of those links and while they were started using the tool, they weren't using JD2/browser. Example:

**External links are only visible to Support Staff****External links are only visible to Support Staff**

But yes, MEGA's downloads limits is a kind of messy issue, and it isn't clear exactly why sometimes they block certain IPs, but you can still download random files; or why they block certain applications, while the same files can still be downloaded with other.

Thanks.

[pspzockerscene]

Hi again,

I've asked Jiaz and this is the explanation:
JD requests the complete range (= complete file) from the MEGA servers.
The tool you've linked always only asks for a part for the file (= the currently available range) and thus doesn't run into these limits that fast.

Basically this is a technical limitation of our current downloadsystem and cannot be implemented without a rework of that.
Ticket:


-psp-

[ElCho]

I see, thanks for your explanation about that issue.

[pspzockerscene]

Thank you for your understanding!

As you can see, I've set this thread to "Solved".
If you got more question or you found further design failures of our MEGA plugin, don't hesitate and let me know

-psp-