Premiumizer ignores/loses category
Pokora22 opened this issue · comments
Not 100% sure if I'm not doing something wrong. Have premiumizer watchdir set to my torrent dir with all catogories as subfolders in there. When putting a torrent file in, it'll get taken and the files will be loaded onto my premiumize cloud, but premiumizer will not download it - it's always missing the category.
I enabled debug and checked that the category seems to be applied:
10-05 23:27:30 root : INFO : Added: Candyman.2021.2160p.WEB-DL.x265.10bit.HDR.DDP5.1-NOGRP -- Category: movie -- Type: Torrent -- id: QW46xUs86Q8GDycdtsAAjQ
but it soon is overridden:
10-05 23:27:31 root : INFO : Added: Candyman.2021.2160p.WEB-DL.x265.10bit.HDR.DDP5.1-NOGRP -- Category: -- Type: -- id: OYPb12M5yqccRVwZ2zNcTA
Full debug log is here: https://pastebin.com/4XUgYSfW
I am also getting this for some downloads. For example:
10-05 23:16:47: INFO : New watchdir file detected: /blackhole/tv/Example.Show.S08E03.1080p.WEB.H264-WHOSNEXT[rartv].magnet
10-05 23:16:48: INFO : Added: Example.Show.S08E03.1080p.WEB.H264-WHOSNEXT[rartv] -- Category: tv -- Type: Torrent -- id: yrQZsH9SqHlzzD34TUGyxA
10-05 23:16:57: INFO : Added: Example.Show.S08E03.1080p.WEB.H264-WHOSNEXT[rarbg] -- Category: -- Type: -- id: ghh2pooltYrzE-pZuxv8sw
After setting the category, the download works as usual:
10-05 23:19:30: INFO : Task: Example.Show.S08E03.1080p.WEB.H264-WHOSNEXT[rarbg] -- id: ghh2pooltYrzE-pZuxv8sw -- Category set to: tv
10-05 23:19:34: INFO : Downloading: Example.Show.S08E03.1080p.WEB.H264-WHOSNEXT[rarbg] -- id: ghh2pooltYrzE-pZuxv8sw
It looks like Premiumizer is trying to locate the completed magnet/torrent transfer by the "name" field returned by the /transfer/create Premiumize.me API call. Sometimes the name returned is different than the actual file/folder created in Premiumize.me's cloud storage, so the download task gets lost.
Since Premiumizer scans Premiumize.me's cloud storage regularly, the differently named file/folder gets picked up as a new task and does not automatically have a category because Premiumizer could not associate it with the previous transfer.
Looking at Premiumize.me's API, unfortunately the cloud storage /folder/* calls do not record or return the transfer ID that resulted in the files appearing there in the first place. That would have made it super easy to link a transfer to a file/folder.
The only solution I can think of based on Premiumizer's current API is:
- generate a unique ID and create a cloud storage folder with that same ID, maybe something like
premiumizer/zD34tU - in the
/transfer/createAPI call, supply this unique folder_id so that it becomes the root containing all files of that transfer - now Premiumizer can download from
premiumizer/zD34tUand know for sure that these files are associated with the transfer
What are your thoughts @piejanssens?
A few days ago I started to have the same problem for every Torrent download. It worked fine previously and I didn't change any setting.
Have send a support request they must have changed something in the API since
ID returned by /transfer/list is no longer the same as /transfer/create
If they cant fix this or is on purpose will need to check by returned name instead of id :/
If they cant fix this or is on purpose will need to check by returned name instead of id :/
@neox387 I do not think that checking the name is enough to associate the transfer and file. If you look at my previous example, the name changes from "rartv" to "rarbg". I see this happening on most torrents.
If they cant fix this or is on purpose will need to check by returned name instead of id :/
@neox387 I do not think that checking the name is enough to associate the transfer and file. If you look at my previous example, the name changes from "rartv" to "rarbg". I see this happening on most torrents.
We add the name based on what is in the .torrent file, premiumize.me names it differently based on what it gets from p2p ? We change our task name to be same as API response from transfer/list, this was no problem since the ids remained the same but for unknown reason now they are not, got a standard reply email back that its busy and responds can take longer -_-
They are active on twitter it seems, send them a DM there cant even reach the website atm HTTP ERROR 500 and api errors whole day
https://twitter.com/premiumizeme/status/1446371919649853444
I DM'd them on Twitter and they have noticed the issue and are working on it.
"hi! thanks for letting us now. Somewhere in the internal API it mixes the job ids and we just havent noticed on our implementation because we didnt rely on them.
Will be fixed within the next few days! Obviously the ids are supposed to stay the same within the api endpoints. Sorry about that.
From what i gathered the transfer/list and transfer/create have different IDs now. They are supposed to be the same
Please note that cloud ids where always different. And torrent name we always get from the tracker!"
I included a link to the issue in my DM
Nice, and no I had a response about outage issues but not about the API, I have been using a workaround matching names on my dev builds 🙂
also working on a branch switch feature
I'm facing the same issue.
Would it be possible that you trigger a docker image update with this fix?
That would be very kind.
Worked on a test download for me on the last commit.
I had a sucessfull download today even though I didn't update Premiumizer (because no new Docker image was published 😉). So it seems like Premiumize.me fixed the IDs.
Downloads are working again over here as well (Docker image), no need to manually select a category. @neox387 it is probably safe to revert the changes related to this issue since P.me seems to have fixed the IDs.
It's np still use id matching first and name as alternative 😀
It's np still use id matching first and name as alternative 😀
True. As a backup method, it makes sense to have in case there are API issues again. Thank you for adding it! ❤️