Transmission

What fixes it is this:

# pkg_delete -f libevent-1.4.14b_2
# portinstall devel/libevent2
# pkgdb -Ffu
# portupgrade transmission-*

And that is all. The world is good again. Running daemon headless happily once more.

Thanks all.

Sorry, I misread - libevent not libnotify.

I confuse easily on a Sunday.

How is that solved? I don't want libnotify at all.

I run a gui-less headless FreeBSD server that I used to run transmission-daemon on. Do I now have to install all of gtk20 and all its little wizards, transmission-gtk etc just to do the same job as I was doing just fine last week without it?

Daemon will seed whatever it has left active. What you need is a startup script.

I'm guess someone will have written one for your debian.

I pipe mine through dummynet to limit total upload of transmission, not just the torrent upload.

Because every protocol has overhead. TCP/IP uses upload to get downloads, so the faster you download the more upload bandwidth gets used. Transmission does not include this overhead in its max upload ...

Awesome.

Job Done.

open a terminal and type:
the directory shown right after "-g" will show you where settings.json lives.

At least, that's how it works with transmission-daemon.

You might have to delete the corresponding files in both the torrents dir and the resume dir of your transmission dir (where settings.json lives).

Try that and let me know if it works.

reinstall curl?

http://trac.macports.org/browser/trunk/ ... l/Portfile

http://curl.darwinports.com/

First thing you want to do is verify that the files on your debian are the same as when they left your windows.

If they are identical (using crc32, md4, md5 hashes or whatever), check the file permissions and make sure everything is readable by the user running transmission.

Assuming obvious stuff ...

cgimusic wrote:If it does create a fully valid resume file then why isn't Transmission using it the first time you resume a magnetized transfer?

I'd say that's your bug right there then

Hi devs and all

How about including an option to limit total upload bandwidth rather than just the torrent upload so that I don't have to pipe all traffic through dummynet to keep my network usable when leeching heavily? :)

At the moment, overhead is added to the max upload bandwidth (rather than ...

Out of interest, watch the logfile (tail -f) as you add a magnet link and see what it does. Then pause it and watch to see if it then, and only then, writes a resume file.

If it's only able to get the torrent hash after it's started the download (torrent files have that stuff written in them), and ...

My guess would be that transmission needs to verify data every time because it stores resume info in a file named for the .torrent file hash.

Which magnet links don't have, right?

That'd be my guess.