why would transmission stop working suddenly?

[9millakilla]

i have been using transmission for months without any problems. i am using osx 10.3.9 so i have an older version of transmission. i went away for 1 month, now i have come back and transmission will not download anything, it starts as normal but it is not finding any seeders or peers etc. i have tried downloading new torrents with lots of seeders just as an experiment but i still dont get anything.
if anyone has any suggestions i would very much appreciate the help as im at a complete loss.
many thanks...

9millakilla

[livings124]

Who knows - that version (.61 or lower) is years old.

[chico]

I am also on 10.3.9 and have the same problem. (See my post of a few days earlier) It's only been the last few weeks that this problem seems to have occurred. I can't say it SUDDENLY stopped working, it just seemed more and more torrents didn't work until there was nothing downloading. Since my original post I have managed to find 2 torrents that actually download (after trying perhaps 100), so it's not a problem with the port or anything like that. I'm guessing that maybe the seeders have all disappeared. I've noticed in the last few weeks more and more torrent sites are removing their files. It just seems like a strange coincidence that these things should happen at the same time.

I would say the whole torrent thing is dead, but most people are having no problems so I'm baffled.

[Nausicaa]

I'm having the same (or a similar) problem. I've been using Transmission for years, although I haven't bothered updating in about as long. Things have been running fine. Good download speeds, no problems with trackers or seeders or anything of the sort - until this month. I don't know exactly when or why I started experiencing problems, but I believe it happened after I updated to the latest OSX Leopard. A few days later I tried downloading a torrent through Transmission, and suddenly it doesn't work.

The file shows up fine, and it even says 'downloading' in the status bar, but it shows zero seeders and zero peers with a 0 kbps DL speed. I finally updated the Transmission client, but that didn't help, same trouble. Then, I tried opening the file in Azerus, and I had the same problem. Thinking it might be a network issue, I ran some tests and determined that my ISP wasn't blocking torrent traffic. I never had port forwarding issues before, but just in case I also downloaded Lighthouse to be sure the correct ports for Transmission were open. The file still showed zero seeders and peers with no DL speed.

I'm really at a loss.

I'm on an iMac G5, and I'll post additional specs when I get home from work. Anything important that could help you guys figure out the problem? I just gave up a few weeks ago until I thoght to check here. I'm at least a little relieved other people are having similar problems.

[metaclam]

I'm experiencing this problem right now with 2.32 OS X. I've been using Transmission normally for years, then all of a sudden 5 downloads from 3 different trackers are finding no peers.

I had "ignore unencrypted peers" on, and am using several block lists, one recently updated. I turned off both options, and also updated the block list. No change. Relaunched Transmission several times. Cut my upload bandwidth in half (lower cap), well within normal rates for my ISP.

Uploads go normally, within set bandwidth limits.

Set port is open. Rebooted router just in case. All other internet services work normally.

I have quite a large number of transfers "seeding". I removed several also with no change.

Any brilliant ideas here?

edit:

if it is any clue, one transfer went. it was < 1 MB transfer. However, another transfer from the same tracker is finding 0 peers also. 3 MB.

edit 2:

hours later, several of them started and finished. several others list HTTP response code 0 (no response)

edit 3: downgraded to transmission 2.3.1, and have pretty much the same problem. only difference is one torrent that had reported "result too large" with 2.3.2, started normally at first, before getting that error again. pause and resume starts it again. i've now tested 5 separate private trackers.

edit 4: the torrent mentioned above (huge at > 100 GB, downloading part) is now clipping along normally. That left 6 torrents on 2 trackers that are stalled with 0 of 0 peers. (all of the web sites associated with those trackers list multiple peers). To test further, I just added one more torrent from another tracker, which is now also stuck in the same way. So 7 torrents over 3 trackers stuck.

I've checked all global (normal and turtle mode) and per-torrent bandwidth settings, and they are as expected.

[metaclam]

the torrent mentioned above (huge at > 100 GB, downloading part) is now clipping along normally

So, the problem would appear to not involve Transmission. Likely, you have managed to pick out some torrents with a perhaps temporarily unconnectable swarm or trackers that are dead or unresponsive.

That would seem plausible. But 7 different torrents on 3 different trackers that have never had such problems before, each torrent well seeded?

Edit: so last night I rebooted cable modem. in morning they were all finished. now i added 3 more from yet another tracker (not even attempted previously), and as with the others they are also "stuck" while uploads proceed normally. I'm now wondering if total number of transfers (now 2,019) has something to do with it?

Edit 2: ok, so those 3 mentioned in Edit 1 started and finished normally 4 hours later. (without requiring a modem reboot). But it's still an issue why they take so long to go now when they never did before.

Edit 3: now have another torrent that hasn't started for over a day. At the end of rope here. Any hints really appreciated. Is it related to this?:

viewtopic.php?f=4&t=11717&start=30

Edit 4: I updated all blocklists with same result. (BTW turning off blocklists completely did not help; though I'm not sure when they load/unload? I did notice a lot of "banned IP xxx.xxx.xxx.xxx tried to connect to us" messages in log.)

[metaclam]

ok, so just to test, I downloaded uTorrent (stable version 1.02).

I set the same port, and all similar settings (force encryption = ignore unencrypted peers; NAT/UPnP off; disabled Distributed Hash Table and Peer Exchange).

The torrent that has been stuck with Transmission for over a day mentioned in Edit 3 above immediately started and finished before I finished typing this.

So there is CLEARLY a problem with either Transmission itself or some corrupted settings files, or the number of torrents I have going there. Transmission error logs kept saying "could not connect to tracker". uTorrent did so immediately.

So please, guys, what gives? I don't plan to switch to uTorrent, and I don't want to lose the library of torrents I'm seeding through Transmission. (Did that once already when switching from Azureus to Transmission)

Edit: back in transmission, removed all blocklists, quit, relaunched. 4 newest torrents still stuck at 0%. sigh.

[srmatto]

ok, so just to test, I downloaded uTorrent (stable version 1.02).

I set the same port, and all similar settings (force encryption = ignore unencrypted peers; NAT/UPnP off; disabled Distributed Hash Table and Peer Exchange).

The torrent that has been stuck with Transmission for over a day mentioned in Edit 3 above immediately started and finished before I finished typing this.

I did this same thing today, independent of metaclam and before I came to these forums, and had the same result. I was able to download two torrents during that time.

I don't want to switch to uTorrent because I enjoy the minimalism of transmission, but it isn't working anymore and I'm afraid I may have to.

[metaclam]

Come on guys! Some tips from pro users or devs would really come in handy here.

[Jordan]

meta, could you test drive some of the previous Transmission releases to try and figure out when this problem was introduced? I'm not seeing any connectivity problems here.

[metaclam]

Thanks, Jordan.

I already did try 2.31, 2.22, and 2.32+ (nightly as of a couple days ago), with the same result. I'm willing to go back further if you say I should.

My current theory is that something in 2.31 or 2.32 corrupted some settings or resume files. Possibly after a forced quit (power interruption or system freeze).

Normally I would try to trash the pref .plist file, but I'm afraid of what might happen to my files. When I downgraded from 2.32 to 2.31, all the torrents that were partial (those for which I had intentionally unchecked some files), started again from 0. I had to pause them and manually verify data for each.

Can you suggest a way to test anything like that without risking data loss or corruption?

[metaclam]

Same result with build r12545. I mostly use private trackers anyway, and all torrents referred to above are on private trackers.

Here's the log from my test on two private trackers. #1 shows 52 peers on the tracker's web site, #2 shows 3. Both are also not starting as above:

Code: Select all

2011-07-13 13:47:06 -0400 utils.c:443 [Debug] Transmission: Couldn't read "/Users/myname/Library/Application Support/Transmission/Resume/torrent_from_private_tracker_#1.009ba2c87153746c.resume": No such file or directory
2011-07-13 13:47:06 -0400 resume.c:686 [Debug] torrent_from_private_tracker_#1: Couldn't read "/Users/myname/Library/Application Support/Transmission/Resume/torrent_from_private_tracker_#1.009ba2c87153746c.resume"
2011-07-13 13:47:06 -0400 bencode.c:1721 [Info] Transmission: Saved "/Users/myname/Library/Application Support/Transmission/Torrents/torrent_from_private_tracker_#1.009ba2c87153746c.torrent"
2011-07-13 13:47:06 -0400 verify.c:260 [Info] torrent_from_private_tracker_#1: Queued for verification
2011-07-13 13:47:06 -0400 verify.c:218 [Info] torrent_from_private_tracker_#1: Verifying torrent
2011-07-13 13:47:06 -0400 verify.c:61 [Debug] torrent_from_private_tracker_#1: verifying torrent...
2011-07-13 13:47:06 -0400 verify.c:155 [Debug] torrent_from_private_tracker_#1: Verification is done. It took 0 seconds to verify 20846124 bytes (20846124 bytes per second)
2011-07-13 13:47:06 -0400 Controller.m:1725 [Info] Transmission: restarting download torrent in mac queue
2011-07-13 13:47:06 -0400 Torrent.m:322 [Info] torrent_from_private_tracker_#1: restarting via startTransfer
2011-07-13 13:48:03 -0400 bencode.c:1721 [Info] Transmission: Saved "/Users/myname/Library/Application Support/Transmission/Resume/VA - Tradi-Mods Vs Rockers - Alternative Takes on Congotronics.ad2bf157fa32927b.resume"
2011-07-13 13:48:03 -0400 bencode.c:1721 [Info] Transmission: Saved "/Users/myname/Library/Application Support/Transmission/Resume/India.mpg.23c55701e3992bc4.resume"
2011-07-13 13:48:03 -0400 bencode.c:1721 [Info] Transmission: Saved "/Users/myname/Library/Application Support/Transmission/Resume/torrent_from_private_tracker_#1.009ba2c87153746c.resume"
2011-07-13 13:48:03 -0400 bencode.c:1721 [Info] Transmission: Saved "/Users/myname/Library/Application Support/Transmission/stats.json"
2011-07-13 13:48:25 -0400 peer-mgr.c:2074 [Debug] Transmission: Banned IP address "85.17.27.88" tried to connect to us
2011-07-13 13:48:42 -0400 peer-mgr.c:2074 [Debug] Transmission: Banned IP address "85.17.27.69" tried to connect to us
2011-07-13 13:51:44 -0400 utils.c:443 [Debug] Transmission: Couldn't read "/Users/myname/Library/Application Support/Transmission/Resume/torrent_from_private_tracker_#2.72045b71c9ad8a88.resume": No such file or directory
2011-07-13 13:51:44 -0400 resume.c:686 [Debug] torrent_from_private_tracker_#2: Couldn't read "/Users/myname/Library/Application Support/Transmission/Resume/torrent_from_private_tracker_#2.72045b71c9ad8a88.resume"
2011-07-13 13:51:44 -0400 bencode.c:1721 [Info] Transmission: Saved "/Users/myname/Library/Application Support/Transmission/Torrents/torrent_from_private_tracker_#2.72045b71c9ad8a88.torrent"
2011-07-13 13:51:44 -0400 verify.c:260 [Info] torrent_from_private_tracker_#2: Queued for verification
2011-07-13 13:51:44 -0400 verify.c:218 [Info] torrent_from_private_tracker_#2: Verifying torrent
2011-07-13 13:51:44 -0400 verify.c:61 [Debug] torrent_from_private_tracker_#2: verifying torrent...
2011-07-13 13:51:44 -0400 verify.c:155 [Debug] torrent_from_private_tracker_#2: Verification is done. It took 0 seconds to verify 7498092 bytes (7498092 bytes per second)
2011-07-13 13:51:46 -0400 Controller.m:1725 [Info] Transmission: restarting download torrent in mac queue
2011-07-13 13:51:46 -0400 Torrent.m:322 [Info] torrent_from_private_tracker_#2: restarting via startTransfer

of course I notice for both it says "no such file or directory" for the resume files:

permissions are 755 for the directory:

Code: Select all

~/Library/Application Support/Transmission/Resume/

There are 2,019 files in that directory.

I checked the directory for the second file, and it does exist:

Code: Select all

MacPro:Resume myusername$ ls -la | grep private
-rw-------     1 myusername  staff     695 Jul 13 13:54 /torrent_from_private_tracker_#2.72045b71c9ad8a88.resume

That is, created today, same ownership and perms as other .resume files.

[Jordan]

I already did try 2.31, 2.22, and 2.32+ (nightly as of a couple days ago), with the same result. I'm willing to go back further if you say I should.

Can you suggest a way to test anything like that without risking data loss or corruption?

Yes, I think you should try 2.20 and the version before 2.20 as well.

Unfortunately the .resume file formats changed slightly over these releases, so to run a test you'll probably want to back up the resume directory, then restore it before each test, and also verify all the torrents after you start up in 2.1x and 2.2x. That's cumbersome, but is the best way of ensuring that your resume data is correct when cycling back and forth between these versions.

[metaclam]

The important question is, are the trackers responsive, and if not what Inspector messages do you see? If they are responsive, how many peers (seeds/leeches) do they give you? Again, only a few (or none) of those may be connectible or capable of sharing at any given time.

I can guarantee you 100% that the trackers are all fine and have sufficient peers. All the messages I posted above show this: a) multiple trackers all with the same issue (6+ different trackers which have in the past been completely reliable and fast); b) in testing I've picked torrents with plenty of seeds; c) I can ping a sample of the trackers just fine with no loss or delay; and d) a quick test with two of the problem torrents previously, using uTorrent, showed no issue, quick connection, and normal speed. This was verified also by another user above.

So, unless you can think of some reason we should seriously still consider the trackers, wouldn't it be better to look at other possible causes?

However, transmission shows the following:

Last Announce: N/A
Announce is Queued
Last Scrape: N/A
Seeders: N/A
Leechers: N/A
Downloaded: N/A

[metaclam]

Unfortunately the .resume file formats changed slightly over these releases, so to run a test you'll probably want to back up the resume directory, then restore it before each test, and also verify all the torrents after you start up in 2.1x and 2.2x. That's cumbersome, but is the best way of ensuring that your resume data is correct when cycling back and forth between these versions.

It would be nearly impossible to do this for me, especially for just a test. I've got 2018 torrents going; can't imagine how long it would take to manually verify each of those. However as noted above, I already did move back and forth between 2.31, 2.22, and 2.32. Did the .resume file format change from 2.22 significantly? Again as noted I had to verify only the ones that were "partial" (or so it seemed). Or have I permanently corrupted some data now?

What I just did right now though is this:

1. Quit Transmission and rename the Transmission folder in ~/Library/Application Support/ and relaunch transmission, without touching (or changing) the Preferences .plist file. (Transmission takes 10 min+ to quit...)
2. redownloaded the last two torrents that were not starting

Result:

As expected they both started immediately and finished within seconds.

(This was using latest nightly as of today, revision # above)

Test #2:

I removed one of those two torrents from list, moved its data out of dl folder, quit Transmission, and copied the previous Blocklist folder from the backup. Again I downloaded the same torrent file. Relaunched T.

Result: Same, worked, and fast.

Conclusion: Not blocklist either

Overall conclusion: Something in the Application Support folder other than blocklists is causing this problem. The current version of Transmission works fine with clean files. Trackers are responding fine.

So now what? Seems to me one of two things need to happen:

1) I can identify the problem file(s)
and/or
2) a revision of Transmission will be able to handle them

Also, it is possible that the sheer number of files is the problem, not corrupted files. Can someone independently test 2000+ torrents? Is T. "rated" for that many?

thanks