Strange. Install atop and see how your memory is growing. I've downloaded 50GB torrents w/o problem.
Printable View
Strange. Install atop and see how your memory is growing. I've downloaded 50GB torrents w/o problem.
I've installed atop. I see that when I push 30Gb torrent then transmission CPU% raises till appr. 68% (in normal state it can be 80 either) and then the process is being killed. Which parameters should I use to trace the transmission memory usage?
P.S.What is the size of your swap?
Since upgrading to transmission 1.06+ and push scrape, I always get the error message [......torrent.seeding scrape failed]
It does with both trackers I use.
Up to 1.03 version I had no problems like this and it was also much more stable to keep torrents active.
Any advice?
Scrape is using transmissioncli so you could try this manually. Also there in a btlist -s if you installed libbt to check if scrape works on your tracker. From my findings my patch to libbt works better than that transmission, so please open a ticket at trac.transmissionbt.com to correct this in future releases. Meanwhile I can change CLI to use btlist for scraping.
I am using openwrt-brcm24 feed and not oleg. Swap size is 512MB. R/V grow percentage should be evident in atop.
I've upgraded today to "transmission - 1.06+r5370-1" and the transmission
daemon does not work anymore.
When I push "Watchdog" in the www interface, the transmission watchdog starts, the transmissiond processes also, but they stop immediately.
Do anyone have the same problem?
quote:
[admin@MyAsus root]$ ipkg list_installed | grep transmission
transmission - 1.06+r5370-1 - lightweight BitTorrent client and daemon with WWW interface
yeh got the same problem here... I just upgraded it today (25-march-08)
for some reason it now only downloads 1 torrent at a time.
What i did was remove the .torrent folder, clean out every file in the /tmp/harddisk/torrent folder so only source, work and target would be there.
After that I tried again and now it's working a bit again...
but it's not really stable:(
I've anticipated that. That's why I didn't want to upgrade until I find a time to test the things. Meanwhile bzhou upgraded package as he is constantly doing this for over 1000 packages that he maintains. Some packages eventually broke during this process. It looks like, I must find a tima now to fix a problem. One is how to disable cache files removal. Until then, One might try Clutch and report if it works with latest release?
I've downgraded to r5332 that works well. Upgrade to latest release is postponed until path handling introduced with r5337 is sollved for transmissiond.
Users should use -force-downgrade and -force-reinstall to get this release.
you mean like this?
PHP Code:[root@wpte root]$ ipkg install transmission -force-downgrade -force-reinstall
Reinstalling transmission (1.06+r5370-1) on /opt/...
Downloading http://ipkg.nslu2-linux.org/feeds/optware/oleg/cross/stable/transmission_1.06+r5370-1_mipsel.ipk
package transmission suggests installing thttpd
package transmission suggests installing mini-sendmail
conffile_has_been_modified: conffile /opt/etc/transmission.conf has no md5sum
conffile_has_been_modified: conffile /opt/etc/init.d/S80busybox_httpd has no md5sum
Configuration file '/opt/etc/transmission.conf'
==> File on system created by you or by a script.
==> File also in package provided by package maintainer.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions (if diff is installed)
The default action is to keep your current version.
*** transmission.conf (Y/I/N/O/D) [default=N] ?n
Configuring transmission
Please note that /opt/etc/init.d/S80busybox_httpd is installed for
running CGI interface at http://localhost:8008/cgi-bin/transmission.cgi
See instructions for daemon and WWW interface in /opt/share/doc/transmission
Configure daemon with /opt/etc/transmission.conf
Successfully terminated.
i had the same problem and now after downgrading to r5332 it works well. Thanks oleo ;)
Downgraded to 5332 and it works.
Thank you oleo
New transmission - 1.10-1 seems working fine. Thanks Oleo!
I have a new question -not exactly a problem tho-. Is there any "nice way" of shutting down transmission before a reboot, or shutdown?
I'm cleaning out my installation and thought about to include a command to pre-shutdown to get the same result as "pausing" transmission from the web I/F. Killall transmissiond does not seem to be an elegant way of doing this. :-)
Don't thank me. Upgrade is missing transmissiond. Thats why it's working fine with an old version. It seems that I must take a time and resolve this issue.
. /opt/etc/transmission.conf kill $PIDFILE
shoud be enough. Althouh you must wait or pool the daemon.
When transmission finishes downloading file and the watchdog moves it to the /target/ directory and initiates seeding, the <torrent>.resume file (or that's where I see it) is not updated with the changed path to the file (there still is a reference to the /work/ directory). Messages like "cannot locate ..../work/<torrent>/.status file" start to appear in log file, seeding is not performed.
I can workaround this problem by stopping the seeding for that file, manually changing the path in the <torrent>.resume file, and starting the seeding process again (however, torrent is rechecked before it starts to seed).
If it helps, here is the log file fragment:
This is quite annoying, since a lot of productive seeding time is missed, if I'm not around when download finishes...Code:Apr 17 06:00:25 transmission_watchdog: Starting torrent /tmp/harddisk/torrent/work/Something/Something.torrent
Apr 17 06:00:25 transmissiond[6846]: Starting torrent /tmp/harddisk/torrent/work/Something/Something.torrent
Apr 17 06:15:14 transmissiond[6846]: Stopping torrent /tmp/harddisk/torrent/work/Something/Something.torrent
Apr 17 06:15:15 transmissiond[6846]: Closing torrent /tmp/harddisk/torrent/work/Something/Something.torrent
Apr 17 06:15:35 transmission_watchdog: Moving files to: /tmp/harddisk/torrent/target/Something
Apr 17 06:15:35 transmission_watchdog: Auto seeding /tmp/harddisk/torrent/target/Something/Something.torrent.seeding
Apr 17 06:15:41 transmissiond[6846]: Starting torrent /tmp/harddisk/torrent/target/Something/Something.torrent.seeding
Apr 17 06:30:01 transmissiond[6846]: /tmp/harddisk/torrent/work/Something/.status - No such file or directory
Apr 17 06:45:01 transmissiond[6846]: /tmp/harddisk/torrent/work/Something/.status - No such file or directory
Apr 17 07:00:03 transmissiond[6846]: /tmp/harddisk/torrent/work/Something/.status - No such file or directory
Apr 17 07:15:02 transmissiond[6846]: /tmp/harddisk/torrent/work/Something/.status - No such file or directory
Apr 17 07:30:02 transmissiond[6846]: /tmp/harddisk/torrent/work/Something/.status - No such file or directory
====== now I intervene by Push'ing the torrent... ========
Apr 17 07:32:08 transmissiond[6846]: Stopping torrent /tmp/harddisk/torrent/target/Something/Something.torrent.seeding
Apr 17 07:32:09 transmissiond[6846]: Closing torrent /tmp/harddisk/torrent/target/Something/Something.torrent.seeding
====== now I change the .resume file and Push back the torrent =======
Apr 17 07:32:55 transmissiond[6846]: Starting torrent /tmp/harddisk/torrent/target/Something/Something.torrent.seeding
I am not experiencing such issue.
Transmisisond uses tr_ctorSetDestination( ctor, TR_FORCE, dirname(folder)); when starting torrent.
and TR_FORCE means
Anyone else with such issue?Quote:
typedef enum
{
TR_FALLBACK, /* indicates the ctor value should be used only
in case of missing fastresume settings */
TR_FORCE, /* indicates the ctor value should be used
regardless of what's in the fastresume settings */
}
tr_ctorMode;