Bug report: tor->isRunning not always saved to .resume file

[dairiki]

I've just discovered transmission. Wow! Great work!

I'm using transmission-daemon to seed a large number of torrents. I have a cron script which periodically checks the scrape results
and starts/stops torrents based on number of leechers and the seeders/leechers ratio. At any given time, the transmission-daemon
has a large number of torrents loaded, with most of them paused and a few of them running (seeding).

I noticed that when I stop then restart the daemon, the list of torrents started out seeding seemed to be somewhat random.

I haven't actually tried hacking the code yet, but I've looked though it (very clean --- great work!) and I think what's going on
is that tor->isDirty is not being set by either tr_torrentStop() or tr_torrentStart(), with the result that the .resume file
doesn't get updated (unless isDirty gets set due to other actions) when the torrent is (un)paused.

I'm running 1.75, but from perusing the code, I think the problem exists in trunk as well.

If it would help if I worked up a patch for the problem, let me know.

Thanks!

PS: I tried filing a ticket on the trac (as suggested at http://trac.transmissionbt.com/wiki/Support), but got rejected
with "Error: Forbidden TICKET_CREATE privileges are required to perform this operation". (I did register and log in.)
(If I should report this bug in some other manner, let me know.)

[rb07]

I noticed that when I stop then restart the daemon, the list of torrents started out seeding seemed to be somewhat random.

That's a new bug I noticed with version 1.75 (but I haven't done real testing, it was just the one time when I changed versions and restarted).

Are you also taking into account that the enumeration changes every time you restart? That is the usual operation, the daemon creates the list of torrents from scratch so you cannot rely on the numbers to keep status or something.

[dairiki]

That's a new bug I noticed with version 1.75 (but I haven't done real testing, it was just the one time when I changed versions and restarted).

I haven't used anything before 1.75, so I can't comment on that.

Are you also taking into account that the enumeration changes every time you restart? That is the usual operation, the daemon creates the list of torrents from scratch so you cannot rely on the numbers to keep status or something.

No, that's not it. I realize the torrent ids change on every restart.

----

Here's how to reproduce the bug.

• Have transmission-daemon running and seeding a torrent (or several).

• Look at the .resume file for the torrent and verify that paused is set to 0.

• Use transmission-remote to stop (pause) the torrent

• Wait two minutes to give transmission-daemon a chance to save the .resume file for the torrent.

• Look at the .resume file, and note that paused is still set to 0. (It should be set to 1, since the torrent is now paused.)

• Now use transmission-remote to change the seedratio setting for the torrent. (This will set the dirty bit.
  It would work just as well, I think, to change e.g. the torrent priority or ul/dl speed limits.)

• Wait another two minutes for the resume file to be written.

• Now examine the .resume file again. Note that paused is now correctly set to 1.

When transmission-daemon starts, it correctly honors the setting of paused in the resume file. The problem
is that while the daemon is running changes of the isRunning state don't always get propagated to the resume file.

Upon further investigation, it looks like there is no problem in the reverse direction. When a paused torrent is started,
the dirty bit gets set by tr_torrentResetTransferStats(). It's only when a running torrent is stopped that there's a problem, I think.

[rb07]

That makes no sense. If the daemon is stopped then transmission-remote just tells you so, the operation is not carried out.

So what you describe is really that your daemon never stopped, and that explains what you are seeing, not a bug, just the daemon didn't stop when you thought it did.

[dairiki]

That makes no sense. If the daemon is stopped then transmission-remote just tells you so, the operation is not carried out.

Maybe I'm not being clear. Nowhere in the above "how to reproduce the bug" description did I stop the daemon; I just stopped (or paused) a particular torrent which the daemon was seeding.

(Transmission daemon, at least 1.75, writes out the .resume files for any torrents whose .resume files are marked as dirty every two minutes. That's what the "wait two minutes" steps in the description above are for. Instead of waiting the two minutes, you could shut down the daemon, which should also trigger the writing of any dirty .resume files.)

To reiterate, the bug is this: When a running torrent is stopped, the daemon should set the tor->isDirty flag for the torrent, thus causing the state change (from running to paused) to be propagated to the torrent's .resume file.

The isDirty flag is not being set, the result being that the value of the paused attribute in the .resume file does not necessarily correspond to the current state of the torrent (and so, if the daemon is restarted for some reason, currently paused torrents can be (incorrectly) restored to the running state.)

[dairiki]

Here's a patch (on svn trunk r9311) which fixes this bug.

Code: Select all

Index: libtransmission/torrent.c
===================================================================
--- libtransmission/torrent.c	(revision 9311)
+++ libtransmission/torrent.c	(working copy)
@@ -1444,6 +1444,7 @@
         tr_globalLock( tor->session );
 
         tor->isRunning = 0;
+        tr_torrentSetDirty( tor );
         tr_runInEventThread( tor->session, stopTorrent, tor );
 
         tr_globalUnlock( tor->session );

[dairiki]

Now that I've figured out why I couldn't open a ticket on the trac, I've filed a ticket on this.

See http://trac.transmissionbt.com/ticket/2520