rtorrent 0.9.3/0.13.3: Issues with "partially" downloaded torrent. Never finishes, completion percentage.

[FewGaze]

When I download a torrent where some files are set as 'Do Not Download' this can result in that the torrent never finishes and is stuck in a 'Downloading' state indefinitely.

The underlying cause seems to be that the downloading phase is only considered complete when the entire torrent has been retrieved. If some files are set as 'Do Not Download' their data will be discarded and consequently the entire torrent will never complete.

Even though such a torrent is reported to be in the Downloading state in practice no downloading occurs after all desired files are complete. So only uploading of data will occur after that.

---

Another - smaller - issue related to 'partial' torrents is the completion percentage. Currently it seems to be to measure completion against the entire torrent. But if I have deselected a number of files the percentage will be below 100% even though all desired files have been retrieved. In short: Completion should only consider the the files marked to be be downloaded and ignore files set to discard.

---

This issue relates somewhat to issue https://github.com/rakshasa/rtorrent/issues/143

[spectromas]

Is there any chance this could be looked at? It's incredibly annoying as files will never be auto moved and will never be categorized as complete.

[dandersson]

The current approach and presentation seems like the most reasonable in my eyes. The torrent is not complete. A torrent consists of "chunks" rather than "files", and other approaches use abstractions that do not really apply cleanly.

One could argue for wanting a separate presentation tag for torrents that are not complete but also not in download mode, but, well, I am guessing that is in the "patches welcome"-territory :-) .

Auto-moving of semi-complete files could be a valid use-case, though, but still rather complex, and still subject of the chunks/files discrepancy.

[spectromas]

I understand if it is something that is not going to be looked at or is considered to be correct by most people, I just personally can't see why it would ever be desirable.

[Moodkiller]

Maybe there should be an option to override a torrents current state and switch it to "Seeding" or "Completed" when what you have selected to download, has been downloaded.

[spectromas]

That's an interesting idea and would certainly be a welcome improvement.

[GrumpyGourmand]

I've experienced the same issue. The worst part for me is that rTorrent will remain connected to many seeds since it still regards the torrent as incomplete, even though you'll have all the data you've requested it to download. All of those pointless connections will count against whatever maximum is configured, as well as occupying a download slot which also counts against any configured maximum. If you have a lot of partially downloaded torrents, this can become a problem because if too many of these pointless connections are open, it can limit new downloads.

I understand that from a purists' perspective, downloading only part of a torrent may be considered a kind of "hack" of the bittorrent protocol, but from a pragmatic perspective, not supporting this behavior as well as other clients is really quite limiting. I'd love to see rTorrent handle partial downloads/partial seeding a lot more gracefully. It's really the one thing keeping me from being able to rely on it for all my torrenting needs. At it stands, I have to run any partially seeding torrents in another client since rTorrent doesn't "play nice" with them.

[chros73]

I'm working on the fix for this: Let's try to fit partially done downloads into the ecosystem of rtorrent:

• libtorrent already has some code related to this state, e.g. in torrent/data/download_data.h , but it hasn't been really used
• rtorrent already has commands for partially done downloads: d.is_partially_done, d.is_not_partially_done
• every finished download is also partially done!

I. Fixes for mentioned bugs

• it will operate entirely based on selection of files (that's the only thing that makes sense from the user point of view)
• let's use partially done state of a download most of the time instead of finished (when it makes sense)
  • release seeds when a download is partially done in libtorrent:
    • torrent/peer/connection_list.cc , protocol/peer_connection_leech.cc, protocol/peer_connection_base.cc, protocol/handshake_manager.cc
  • let's trigger event.download.finished in rtorrent when a download is partially finished
  • define a new slot and a corresponding method in core/download_list.cc slot_partially_restarted() that will handle client part (also into core/download_list.h)
    • reset choke groups, d.complete, d.connection_current, d.peers_min, d.peers_max
    • it will trigger a new event.download.partially_restarted event
  • don't send complete info to trackers only if a download is truely finished
  • create a new event.download.partially_restarted event that is triggered when a partial download has been restarted
    • e.g. it can be used to assign custom choke groups to downloads
    • add this new event to relevant view filters in main.cc
      • complete, incomplete, seeding, leeching
  • modify d.timestamp.finished.set method in main.cc to be able to be overridden
  • create a new porperty and setter method in libtorrent@torrent/data/file_list.cc for selected_size_bytes
    • will be equal to size_bytes if a download is finished
    • will be equal to completed_bytes if a download is partyally done (and not the slected size of files, since they can be turnd off later!)
    • otherwise calculate the partial size based on the selected chunks of the selected files
    • it's a property in File_list: to don't fire up this expensive calculation all the time
    • save it into session and reload it during restart (similarly to chunks_wanted):
      • required by stopped torrents (update_priorities() method isn't triggered for them upon start)
• it should not break remusing downloads
• it should not break fast resume data
• it should not break hash-checking of a download

II. New commands in rtorrent

• d.is_done : to be able to distinguish between finished and partially done downloads
• d.selected_size_bytes : gets the correct size of a torrent

III. UI changes in rtorrent

• don't change the % , displayed total size (we want to differentiate between partially done and finished downloads), but display done in the place of remaining time if a download is partially done
  • 13.6G / 22.8G Rate: 0.0K / 0.0K Uploaded: 762.4M [59%] done [T R: 0.05 low tardyup]
• on the new compact view: don't change anything (there's no place for it), if a donwload isn't 100% and there's no remaining time that means it's partially finished
• display additional Size info on Info screen: downloaded / selected / total size:
  • Size: 450MB / 712MB / 970MB
• modify Chunk screen also to take into account partial downloads
• remaining time should display the correct amount all the time

[radry]

Bug still persists in 0.9.6

[chros73]

Of course it is: it's almost 2 and a half years old. Here's the proposed fix for it.

[radry]

What do you mean "of course"? This is ridiculous. The original post is 4.5 years old and it's not fixed. The proposed fix is a year old, why hasn't it been merged? rtorrent is unusable like this.

[chros73]

What do you mean "of course"? This is ridiculous.

I meant that my comment above is just about 1 year old and the latest release is way older than that.

why hasn't it been merged?

Maybe it won't even pass the code-review at all :)

rtorrent is unusable like this.

It's a bit harsh but I understand your point (that's why I tried to fix it).

You can try to build rtorrent-ps-ch which includes this fix and try it out and report back here.

[Feriman22]

This issue is still existing and not fixed in rotrrent 0.9.7 and libtorrent20/stable,now 0.13.7

[tommyjohn81]

This is the reason many users have switched to Deluge which operates based on the original poster's view, if a download has completed all requested chunks, its should be viewed as "complete".. what would be the purpose for keep it in downloading state in perpetuity? All chros73's suggestions seem reasonable

[vtopc]

Yea, confusing a bit.

[Woogz-git]

Spent numerous hours setting up Rtorrent/Rutorrent over the last week on my Unraid server and now am going to swap over to Deluge because of this. Shame because Binhex specifically recommends Rtorrent over all other available torrent containers he authors but I'll have dozens of torrents sitting in a perpetual state of download if I use Rtorrent until this is updated.

@chros73 I'm new to non-Windows OS's. Can I use rtorrent-ps-ch in Unraid?