DSM-G600, DNS-3xx and NSA-220 Hack Forum

KyleK, could you tell how you compile? Or give link to post about this
i compiled last version but i've got 7.5MB transmission-daemon
i compiled libevent
patched miniupnp/miniupnpc.c
and compiled transmission

#./configure --prefix=/ffp --disable-gtk --disable-nls --enable-lightweight

(i want to patch transmission about changing top folders for myself)

# ldd /ffp/bin/transmission-daemon
ldd: can't open cache '/ffp/etc/ld.so.cache'
        librt.so.0 => /ffp/lib/librt.so.0 (0x4000e000)
        libevent-2.0.so.5 => /ffp/lib/libevent-2.0.so.5 (0x40018000)
        libcurl.so.4 => /ffp/lib/libcurl.so.4 (0x40051000)
        libssl.so.0.9.8 => /ffp/lib/libssl.so.0.9.8 (0x40090000)
        libcrypto.so.0.9.8 => /ffp/lib/libcrypto.so.0.9.8 (0x400d6000)
        libdl.so.0 => /ffp/lib/libdl.so.0 (0x4020d000)
        libz.so.1 => /ffp/lib/libz.so.1 (0x40218000)
        libm.so.0 => /ffp/lib/libm.so.0 (0x40235000)
        libpthread.so.0 => /ffp/lib/libpthread.so.0 (0x40250000)
        libc.so.0 => /ffp/lib/libc.so.0 (0x4026a000)
        ld-uClibc.so.0 => /ffp/lib/ld-uClibc.so.0 (0x40000000)

@pavelc: I don't really do much different, other than stripping the resulting binaries:

$ make DESTDIR=$HOME/devel/releases/Transmission-2.41 install-strip

I also link libevent statically, just so I don't have to provide another extra package for people to download (Transmission is the only tool I know that uses libevent).


@FunFiler: That is most likely because Transmission now supports queuing, and thus has new "Queued for download" and "Queued for seeding" states. Any 3rd-party tools must be updated accordingly, I guess.
Any other problems to report?

KyleK wrote:

I've updated the first post so everyone knows that Transmission 2.41 is out, after several people told me it works fine

If anyone has problems running this one, please let me know.

KyleK,

Thanks for your awesome work.
I seem to be having issues with 2.41. I have a hard time pausing or removing torrents from the webui.
I can roll back to any of the 2.3x and I do not have this issue.

Any ideas?

TIA.

Looks good so far. Have a DNS-343 and updated from 2.33.

Couple of notes:
"funpkg -u Transmission-2.41-1.tgz" from front page needs update to new version "funpkg -u Transmission-2.41-2.tgz".
Don't forget to force refresh browser in case old files are cached.
Can't see the queue actually working. Multiple torrents started, and all running. (Could be operator issue, of course).

Thanks for the newest release!

sonci wrote:

nUll wrote:

KyleK wrote:

I've updated the first post so everyone knows that Transmission 2.41 is out, after several people told me it works fine

If anyone has problems running this one, please let me know.

KyleK,

Thanks for your awesome work.
I seem to be having issues with 2.41. I have a hard time pausing or removing torrents from the webui.
I can roll back to any of the 2.3x and I do not have this issue.

Any ideas?

TIA.

The same for me,
I cannot pause any torrent, but I can add new ones,
any tip?

I think it just needs several refresh in the browser,
just clear the browser cache

Thanks

Last edited by sonci (2011-10-15 15:36:48)

Kylek,

I've been suffering the OOM killer problem in DNS-323, exactly the same symptoms as Elmor (See http://dns323.kood.org/forum/viewtopic. … 53#p42353, post #1677): plenty of swap space available, web interface becomes unresponsive, SSH slows down a lot, and finally the transmission daemon is OOM-killed by the kernel. I experienced this problem with almost every transmission build since I started tweaking my DNS-323, starting with version 2.30

In the past, I tried re-installing ffp completely and in some cases the issue disappeared, but this last time I rebuilt my DNS-323 the issue appeared again and I could not seem to make it go away. I tried tweaking the settings.json file quite a bit, reducing peer connections, etc... But nothing seemed to help.

And then, I learned about the "open-file-limit" setting. I set this to 20, and the issue appears to be gone now, or at least transmission does not crash every 30 minutes which is a huge improvement. I noticed that your build does not include this setting by default and I'm not even sure if this is the right solution, but if it is, should your build include this setting?

Kylek,

You have a point: The issue is in fact hard to reproduce (I have setup ffp + transmission for a friend who also owns a DNS-323 and cannot reproduce the issue there). I'm ok with setting the open-file-limit myself, but I guess it would be beneficial to include details about this issue somewhere in the documentation and potential configuration tweaks to try to fix it.

Btw, Is there any detailed information on how transmission deals with open-file-limit? I'm using a value of 20-25, but I'm not sure how this affects the number of open connections.

I'm not sure if you are able to configure queuing via the web interface (can't look right now), but I do know that it's currently not possible with transmission-remote.

What you have to do is quit Transmission, and then manually edit the settings.json file in Transmissions data folder.

"download-queue-enabled": true,
"download-queue-size": 2,
"queue-stalled-enabled": true,
"queue-stalled-minutes": 30,
"seed-queue-enabled": false,
"seed-queue-size": 10,

There you can enable or disable download and seeding queues separately and also increase their respective queue sizes.

Transmission 2.42 is out!
lately I've been suffering from lack of peers due to errors in UDP trackers. Apparently the error is this one:
https://trac.transmissionbt.com/ticket/4556

which is fixed in the latest release so whenever you find the time could you please compile and publish that version? your work is greatly appreciated, thanks.

Thanks! that was fast!
It actually seemed to have solved the issue, but after a while I get 'Connection failed...' for all UDP trackers again.

I found these errors in the log, I don't know if it is related:

UDP Failed to set receive buffer: requested 4194304, got 208896 (tr-udp.c:75)
UDP Please add the line "net.core.rmem_max = 4194304" to /etc/sysctl.conf (tr-udp.c:80)
UDP Failed to set send buffer: requested 1048576, got 208896 (tr-udp.c:86)
UDP Please add the line "net.core.wmem_max = 1048576" to /etc/sysctl.conf (tr-udp.c:91)

Well, I'd say this is a rather informative warning message, as it tells you exactly what to do

I'd create a sysctl.conf in /ffp/etc with the lines mentioned in the warning, and then load it prior to starting Transmission:

$ sysctl -p /ffp/etc/sysctl.conf

This message has existed for as long as Transmission had UDP support, so it's nothing new.

Transmission complains that the system's TCP receive and send windows are too small, probably because Transmission (or Bittorrent in general) expects quite a lot of messages coming in from loads of peers.
The tool tries to set application-specific buffers that suit its needs, but this fails if
A) You don't run Transmission as root
B) the max size of those buffers is smaller than the size Transmission wants.

Although I don't think it'll make much difference, you can create a sysctl.conf file with the two parameters Transmission suggests, and then call the above command once when your system boots up (create a new .sh file in /ffp/start, or call it from /ffp/etc/funplug.local).
Then this warning in the Transmission logs should go away.