Opened 9 years ago

Closed 9 years ago

#5135 closed Bug (duplicate)

rare resume file corruption prevents seeding

Reported by: user967 Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.73
Severity: Normal Keywords:
Cc:

Description

After using transmission pretty heavily for almost 3 years, I have encountered this problem no more than 5 times. I hope that this time, I might help determine the cause, or have a better idea of what to look for next time.

A single peer wants to leech from my client, they are connectable, and listed by the tracker. No data is transferred, after several days. Stopping and starting the torrent, verifying etc have no effect. The torrent did not appear to have any setting that would prevent seeding.

After removing the torrent, and re-adding it, seeding began immediately. This time, I saved the original .resume file. Perhaps it would be useful in tracking this down.

Best I can tell, the most significant difference between old and new .resume file is that the old one lacks any "peers" key. That is true of a bit more than 15% of my seeding torrents though.

I have attempted to attach the two .resume files, with filesystem paths replaced with "0"s.

Attachments (1)

old-new-resume.zip (983 bytes) - added by user967 9 years ago.
sample resume files

Download all attachments as: .zip

Change History (9)

Changed 9 years ago by user967

sample resume files

comment:1 Changed 9 years ago by user967

Sorry, based on further experiment, this issue is not actually correctly described.

I once again encountered such a 'stuck' seed (same downloader). This time, after backing up the .resume file, and the removing the torrent from my client, I copied the old .resume file back into place before re-adding the .torrent.

I verified that the old .resume file has been used, as all the stats are preserved, etc, but once again, the torrent began seeding immediately after the torrent was reloaded.

So, this issue appears to have nothing in particular to do with .resume files.

Let me know what might help next time, to track this down.

comment:2 Changed 9 years ago by livings124

It is likely just the luck of the drawing. A single peer isn't necessarily going to be consistent.

comment:3 Changed 9 years ago by user967

If you can tell me this must be a problem with the tracker (or remote peer), I would accept that.

To be clear, though, the peer was connected to the tracker for days. The tracker showed both peers. No connection was ever established. Stopping and starting the torrent had no effect.

After removing the torrent, and re-adding it, connection was established within seconds. As far as I know, from the tracker's point of view, that would be the same as stopping/starting?

Again, if there is anything helpful I could provide next time, let me know.

comment:4 Changed 9 years ago by x190

FWIW, I've seen this happen when doing multiple runs of the same torrent during testing. I've no idea what's going wrong though.

comment:5 Changed 9 years ago by user967

The title of this ticket is not correct, as I do not know what causes this.

Updating, because I think it is possible that this is related to the current µTP issues. When I read https://trac.transmissionbt.com/ticket/5002#comment:17, I decided to switch off µTP for safety, though I had not experienced any issue I attributed to it. After disabling it, several torrents that had either not started or not completed for some days soon started transferring and completed. Could be a coincidence, I had not noted anything specific about those stuck torrents, but seemed worth mentioning as another potential explanation.

I will update this if I ever see a torrent that will only start after reloading the .torrent, when µTP is not enabled.

comment:6 Changed 9 years ago by livings124

user967: should this be closed in favor of #5002?

comment:7 Changed 9 years ago by user967

yes, that will be fine. hopefully it will prove to be cleared up along with that issue.

comment:8 Changed 9 years ago by livings124

  • Resolution set to duplicate
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.