Closed hieronymu closed 2 years ago
I had the same issue occur today
This seems to happen when the torrent is downloaded to the root-folder of premiumize - e.g. if the corresponding mkv/mp4 file is NOT contained in a folder itself, but just sits in the root folder like this:
I'm not able to reproduce this issue.
I have the same issue. Doesn't always happen, but when it does it happens with files that will be downloaded into the root-folder, like @verfehlix mentioned. Premiumizer then downloads the whole cloud storage instead of just the one file :/
Also happened to me a few times. Didn't know if it was PM or Medusa doing screwy post processing and copying stuff around
@neox387 Do you have any idea? I can't reproduce with single files on root as the cause is described above.
Unfortunately I'm having this issue now every day as well. I already turned on debug logging but couldn't see anything suspicious. If I can provide something useful to solve this issue please let me know.
Seems that may be a premiumize.me issue after all and not premiumizer's fault. Just noticed the same bug happening while on the premiumize.me website - it listed all of my cloud files inside just one folder.
@ujellyx Would you be so kind to file an incident at premiumize.me and keep us posted here?
Had a look few days ago but could not reproduce it, just noticed a finished download with the same problem just now because I left some files on the cloud.
After the last api faillure #320 I am not suprised :/
If they don't already know it would indeed be best of someone opens a ticket that they can investigate. We use this to get the folder items to download: https://www.premiumize.me/api/folder/list
For categories where mostly the transfer name = filename could add a workaround to stop downloading other named files... Not ideal
Occurred around 5 times to me, first time around 2-3 weeks ago.
I don't agree with @verfehlix, this bug occurred to me several times with directories.
In my experience, it was usually the second download at the earliest where this happened. Never the first. But not 100% sure of that.
Because premiumizer became unusable for me due to this bug, I spend some time debugging it, so we hopefully can work out this issue.
The worst part is, that I'm still not 100% sure how to reproduce it, but at some point it just occured in my debug enviroment. Unfortunately I can't completely solve it, maybe someone else can step in.
I'll just post what I found so far.
First, it is a problem with the API, I'm just not sure how and where it happens. Premiumizer gets the _folderid in the update method from the post request to the site. When I use the api in my browser I get alot less information then premiumizer gets in its response.
Nevertheless this is the point where the bug begins.
In some cases a download folder gets the _folderid of the root folder. This leads to _processdir being called with a subdownload directory and _dircontent has the root folder content of the pm account, which is then downloaded completely into the subfolder.
Hopefully anybody can make something useful out of this.
And in case I should provide specific additional information when the bug occurs, please let me know.
Had a look few days ago but could not reproduce it, just noticed a finished download with the same problem just now because I left some files on the cloud.
After the last api faillure #320 I am not suprised :/
If they don't already know it would indeed be best of someone opens a ticket that they can investigate. We use this to get the folder items to download: https://www.premiumize.me/api/folder/list
For categories where mostly the transfer name = filename could add a workaround to stop downloading other named files... Not ideal
Ok found it. I looked at the above mentioned url, but in the code I found: https://www.premiumize.me/api/transfer/list and when I look there, I can find a download where the folder_id is the root folder and this leads to problem described in my previous post.
Can you post the reply from that API call please?
After some time, it changes to a different/correct api response and I can download it.
This is how it looks at the beginning. Later (maybe after some post processing it changes to a suitable folder_id.
{"status":"success","transfers":[{"id":"7IYka_Ub74jIgZkkr_P23A","name":"MyDownload.nzb","message":null,"status":"finished","progress":0,"folder_id":"MYROOTFOLDERID","file_id":null,"src":"https:\/\/www.premiumize.me\/api\/job\/src?id=7IYka_Ub74jIgZkkr_P23A"}]}
I just pushed a fix for this. Please pull in the latest code and report if this fixes your issue.
Unfortunately not. I think the problem occurs in the else part of the code section you modified. There it assigns all the wrong folders to _dircontent
For your interest, I was able to more deterministacly recreate the problem on the site. So the problem is within the site not the software, but I have no idea, when/if they are going to fix that.
Steps to reproduce:
@Flobbes Do the files of your step 1 and 2 need to be downloads that contain a single file, without a directory structure? Does this auto correct itself after a few seconds (if you would wait setting the categories to initiate the local download)? (check the https://www.premiumize.me/api/folder/list before and after)
I have contacted Premiumize and they have confirmed its a regression bug from their side.
I think we can expect file_id always to be filled from the /api/transfer/list
call when it's a single file.
I'll update when I hear more.
It does not matter how many files are in the folder.
It corrects the folder_id, when I add another download or remove a download (and maybe other actions with the site have the same effect).
Thank you very much for contacting them! Hopefully they will look into and fix the problem soon.
Edit: I removed the comment that its only nzb related, because it just happened with a torrent as well.
Premiumize:
_ looks like it was a caching issue on unfinished jobs. This has been fixed today.
Can you check if it's ok now and we caught the correct bug?_
@Flobbes @hieronymu Please retest and confirm that this is now resolved (use new dl tasks).
I tested several different dls and couldn't reproduce anymore. I think the issue is solved. Thanks
New issue cropped up in the last few days. When the download starts the local download phase, it downloads every file from my premiumize storage.
For instance, it'll trigger premiumize to download a 2 gig file. Then it will download 325 gigs worth of stuff to my computer.