#1
|
|||
|
|||
tezfiles.com bad implementation can't restart download and double counting bandwidth?
There is a bug for this plugin.
This site has a 50 GB daily download limit for premium, I started downloads leaving 128 MB of bandwidth remaining. Why did I get this error message 60% into the download? Not enough traffic available 2.358 GiB required Is the app trying to deduct another 8.02 GB of bandwidth from the account? There isn't a way to restart that download, the bandwidth error message won't go away. I went to tezfiles and it shows 128 MB traffic remaining but it lets me begin this download because it recognizes that I have an existing download from earlier so it doesn't double deduct the bandwidth for the same file. This hosts implementation doesn't take that into account? I extracted the direct link from the website which begins with **External links are only visible to Support Staff****External links are only visible to Support Staff** It's the same file but Jdownloader doesn't have the feature to change the link to resume the file so I am forced to start from the beginning. But I found a way to resume it using Firefox. I begin the download and pause it, rename the part file from Jdownloader to match the Firefox part file, go back to Firefox and resume. I tried the same thing on this app but it doesn't resume. It didn't even prompt me for what to do but I think it would only rename, overwrite or skip. There isn't a way to add a http link and resume from an existing partial file? |
#2
|
||||
|
||||
@minixbox: many site do deduct the whole file size on download link generation starting 5 10Gb files will require 50GB of traffic. that way you can resume/download it with multiple connection but the file is only counted once. counting each connection and traffic takes much more effort/work and only very few sites do it that way.
Quote:
Quote:
__________________
JD-Dev & Server-Admin Last edited by Jiaz; 25.07.2024 at 12:20. |
#3
|
||||
|
||||
Plugin checks for resumeable/cached link and then "enough traffic check" doesn't apply.
That means that the cached link no longer works/is expired and JDownloader has to create new one and that most likely failed due to not enough traffic Quote:
__________________
JD-Dev & Server-Admin |
#4
|
||||
|
||||
we will check/add support for this to not check for enough traffic if there has been valid link within the last x hours.
__________________
JD-Dev & Server-Admin |
#5
|
|||
|
|||
Quote:
I generated another direct link a few minutes ago and it has this: temp_url_expires=1722011566 That unix timestamp is about 24 hours from when I generated the link |
#6
|
||||
|
||||
I'm aware of this but I was not aware that generating a new link within x hours does not credited on traffic. Can you please test and verify this? eg generating a new link in browser for a file, check remaining traffic and then generate a new link for same file and check remaining traffic again
__________________
JD-Dev & Server-Admin |
#7
|
||||
|
||||
But this would also mean that the website would allow you to generate a fresh direct URL even when your traffic is too low at this moment as long as you've generated one before within the last ~24 hours for the same file?
__________________
JD Supporter, Plugin Dev. & Community Manager
Erste Schritte & Tutorials || JDownloader 2 Setup Download Last edited by pspzockerscene; 26.07.2024 at 10:10. Reason: 4 -> 24 |
#8
|
||||
|
||||
@pspzockerscene: maybe fresh generated links do have shorter expire times? let's wait for feedback/testing from user
__________________
JD-Dev & Server-Admin |
#9
|
||||
|
||||
To be honest I wouldn't introduce any changes to our current tezfiles' plugin behavior unless we got the ability to properly test this.
Atm we do not have a tezfiles premium account but that would be needed to do the mentioned tests.
__________________
JD Supporter, Plugin Dev. & Community Manager
Erste Schritte & Tutorials || JDownloader 2 Setup Download |
Thread Tools | |
Display Modes | |
|
|