You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 18, 2024. It is now read-only.
When listing the contents of a torrent with many files of which one is missing, listing is incomplete, and rclone_RD makes a whole lot of delete and re-download requests that do not seem to help retrieving the missing file.
As an example, consider a torrent with files A, B and C.
If I unrestrict links on real-debrid.com I get links for A and C, but for B I get the message
For such a torrent, rclone_RD version v1.58.1-rd.2.1 displays only A. This happens both when mounting the debrid + listing the folder or serving it as HTTP + accessing the folder from the browser. Additionally, rclone_RD prints "Redownloading dead torrent X" to the logs. It then makes a whole bunch of delete requests and re-adds the torrent to real-debrid.
Seemingly, behavior is as follows (possibly not fully correct):
rclone_RD tries unrestricting all the files in the torrent; this works fine until it encounters B
as soon as rclone_RD encounters B, the torrent is marked as bad
rclone_RD then issues DELETE requests for every file following B (B, C and so on)
rclone_RD then issues a DELETE request to the torrent itself
rclone_RD then issues a new download request for the torrent
The torrent I am accessing has the same fault for file B after re-adding it, so this results in a lot of superfluous requests and weird behavior, at even the files preceding B (A) seem to become unavailable after the DELETE request is made.
Desired behavior for me would be one of the following:
I see all files in the torrent except for the missing one.
Alternatively, I see all the files and can access all of them, except the missing file.
rclone_RD is a lot faster for me than rclone+WebDAV, so thanks a lot for creating this software!
The text was updated successfully, but these errors were encountered:
hey thanks for reporting this! I will not be able to add this to the newest bug fix update, but I will try to keep this in mind for the broader update that is coming soon. This broader update will allow file renaming and moving, and development for it will continue at the end of april.
hey thanks for reporting this! I will not be able to add this to the newest bug fix update, but I will try to keep this in mind for the broader update that is coming soon. This broader update will allow file renaming and moving, and development for it will continue at the end of april.
Hey, any update on this?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When listing the contents of a torrent with many files of which one is missing, listing is incomplete, and rclone_RD makes a whole lot of delete and re-download requests that do not seem to help retrieving the missing file.
As an example, consider a torrent with files
A
,B
andC
.If I unrestrict links on real-debrid.com I get links for
A
andC
, but forB
I get the messageFor such a torrent, rclone_RD version v1.58.1-rd.2.1 displays only
A
. This happens both when mounting the debrid + listing the folder or serving it as HTTP + accessing the folder from the browser. Additionally, rclone_RD prints "Redownloading dead torrent X" to the logs. It then makes a whole bunch of delete requests and re-adds the torrent to real-debrid.Seemingly, behavior is as follows (possibly not fully correct):
B
B
, the torrent is marked as badB
(B
,C
and so on)The torrent I am accessing has the same fault for file
B
after re-adding it, so this results in a lot of superfluous requests and weird behavior, at even the files precedingB
(A
) seem to become unavailable after the DELETE request is made.Desired behavior for me would be one of the following:
rclone_RD is a lot faster for me than rclone+WebDAV, so thanks a lot for creating this software!
The text was updated successfully, but these errors were encountered: