Opened 14 years ago

Closed 12 years ago

Last modified 12 years ago

#514 closed Bug (invalid)

Deselected files are still downloaded

Reported by: starburst Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 0.94
Severity: Normal Keywords: file select deselect


Files for which I remove the checkbox in the Files - Torrent inspector are still being downloaded. It seems it happens at a very slow rate but this means that those files are created on disk and can take up as much space as the file you do not want would be.

I am using Trasmission 0.94 for Mac OS X

Change History (17)

comment:1 Changed 14 years ago by marioestrada

  • Priority changed from Normal to Lowest
  • Severity changed from Normal to Trivial

This is normal behavior for all torrent clients, some of the packets received contain data from other files and transmission just puts that data in the right place.

comment:2 Changed 14 years ago by charles

  • Resolution set to invalid
  • Status changed from new to closed

marioestrada is correct.

comment:3 Changed 14 years ago by starburst

  • Cc starburst added
  • Priority changed from Lowest to Normal
  • Resolution invalid deleted
  • Severity changed from Trivial to Normal
  • Status changed from closed to reopened

Normal behaviour? You have to be kidding!

If I tell transmission I do not want to download a certain file guess what that means?

It means: I do not want to download that file. At. All.

Ergo how about just dropping those packets received for files which the user does not want to download?

The reason this is obnoxious is also because transmit actually creates those files with the actual file-size even if it has only received a handfull of bytes of that file. Especially when you download something large it becomes a problem because transmission for instance creates a 4 GB DVD image file that you do not want in the first place which is only ever going to contain a couple of stray packets from other torrent clients.

I have even had the OS come to a screeching halt because transmission insists on filling up my disk with files that I do not want....

Surely this makes sense?

comment:4 Changed 14 years ago by livings124

  • Resolution set to invalid
  • Status changed from reopened to closed

What happens if someone temporarily deselects a file for download. Should it instantly be deleted?

I'm sure that, especially for people on trackers where ratio matters, if they have data that can be seeded, they don't want it removed, regardless if it's what they originally wanted. Also, the nature of bittorrent means that some pieces overlap multiple files, so that data has to stay.

comment:5 Changed 14 years ago by charles

It means: I do not want to download that file. At. All.

You're being very rude. I know how to read, and did read your message. I think, for this ticket to move forward, you need to tell me how Transmission can verify the piece's checksum is correct without downloading the entire piece.

comment:6 Changed 14 years ago by starburst

  • Resolution invalid deleted
  • Status changed from closed to reopened

I am not being rude. I was just clarifying it as I thought you didn't understand what I was reporting.

If someone (temporarily) deselects a file for download maybe you could have a dialog pop up asking the user if he really wants to delete the partly downloaded file? And if the user doesn't want to do that the checkbox is not cleared. Maybe there could also be a preference setting for this dialog to pop up or not.

As for the question about what to do with an piece overlapping multiple files. Can't you just store it in a file the size of the piece? Right now if that piece is part of a 4 GB file transmission creates a 4 GB file. I don't care about small files that are no use to the user being created but I do care about big ones.

The real life scenario I came across where this was a problem was as follows: Someone made a torrent file of 55 GB comprising multiple DVD images (@#$ I know....). I was only interested in one and unchecked all the others so they wouldn't be downloaded and left transmission alone to do it's thing. Yet imagine my surprise when transmission still created all the other DVD images as well even though "DL" was unchecked and it had only downloaded 0.03% or something like that of each file. When this happened my disk was almost full and the OS didn't like it and became totally unresponsive....

comment:7 Changed 14 years ago by livings124

  • Resolution set to invalid
  • Status changed from reopened to closed

Such is the nature of Bittorrent.

The solution you came up with is needlessly complex and wouldn't work in practice.

comment:8 Changed 14 years ago by eisa01

It's possible to store the extra data in a separate transmission.dat file or something. That's what µTorrent does, works flawlessly. I guess you could put this in the Application Support folder on macs too, which makes it even better for the user.

µTorrent stores it in the folder of the files being downloaded.

comment:9 Changed 14 years ago by starburst

  • Resolution invalid deleted
  • Status changed from closed to reopened

Exactly my idea. I had a longer reply with more suggestions but eisa01 just beat me to it and now that reply is lost :-(

Anyway please don't close this ticket without discussing it and thinking it through!

comment:10 Changed 14 years ago by charlieMonroe

Actually what would make more sense and would be waaaay easier to implement would be to just give those "unwanted" file an invisible flag (I can provide code for making a file invisible). So that those files still are in the directory, thus nothing has to be changed in libtransmission, just making those files invisible.

There would be a problem with storing those data in Application Support folder: when to use them, delete them , etc.

comment:11 Changed 14 years ago by eisa01

Making them invisible sounds fine in theory, but they you get the same problem of when to delete.

Just having it in the same folder is probably fine.

And you don't solve the problem of 1 kB taking up 4 GB space...

comment:12 Changed 14 years ago by charlieMonroe

So: Transmission as any other BT client cannot request data from byte X to byte Y. It has to request it per pieces. Problem with huge torrents is that those pieces are often huge, so there's always some data around that you need to download. If you wouldn't download it, there would be no way to check the data (against the hash). So you're suggesting to create temporary files in application support folder. This would result in: libtransmission being aware *where* to write the data, where to take them from (and in which case) and also have a mapping of that temp file. I think this is a thing that would require huge changes in libT and would result in *most* cases in saving ~100(0) MBs, which is not much compared to the work that would have to be done on libT. That's my opinion and I'm quite sure the devs will have a similar one...

comment:13 Changed 14 years ago by Thinine

What, charlieMonroe? Even the biggest torrents only have a piece size around 1MB, perhaps as high as 10. Fine, you need the whole piece to hash, so download it. It doesn't mean you need to create the entire multigigabyte file on the disk (which Transmission shouldn't even be doing, but that's a separate bug report). Just clip the piece to the bytes needed for the files requested and discard the rest. It's not that hard. And I find it absurd that the devs won't even discuss this extremely annoying bug merely because they can't imagine a solution that isn't as easy to implement as they want.

comment:14 Changed 14 years ago by Waldorf

  • Cc starburst removed
  • Resolution set to invalid
  • Status changed from reopened to closed

Please continue this discussion in the forum. Thought has been put into this (spare pieces in a cache) and may (might) be implemented in due time.
Or if feels like coding it themselves the patch would be welkom.

Footnote: the main idea projected here is against the nature of Bittorrent. Though eisa01 did make a correct observation, for that I created #532.

comment:15 Changed 12 years ago by painpony

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 0.94 to 1.60+

This bug is extremely annoying. Examples that show to which problems it can lead have been given. Don't ignore it, solve it. If it's difficult, solve it anyway.

I'm very sorry, but "Against the nature of Bittorrent" sounds as if you would abuse Bittorrent if you repair this bug. You wouldn't! But as an user I'm interested in that the program works as proposed, not in the imaginary feelings of Bittorrent or if other clients also have this "feature" (wouldn't it be great if Transmission would be the client that solved the problem?). And if downloads unwanted files, this is simply an error to the user.

I understand that packets have to be downloaded if they consist of parts of both a wanted and an unwanted file. But you don't have to save the unwanted file. Check if the packet was received correctly and just write to the wanted file, scrap the other part.

Or at least, please remove this message "No such file or directory" if this file was marked as unwanted. If I delete an unwanted file, it stops the whole download process repeatedly! :(

Please, leave the decision - if he wants to scrap unwanted packages/files - at least to the user ... as you do with other options of this kind. I repeat: For users it's just a bug and can be extremely annoying.

comment:16 Changed 12 years ago by livings124

  • Resolution set to invalid
  • Status changed from reopened to closed

painpony: #532 is a more helpful ticket than this.

comment:17 Changed 12 years ago by livings124

  • Version changed from 1.60+ to 0.94
Note: See TracTickets for help on using tickets.