DL loops on QNAP NAS using Transmission v1.92

[Razorax]

Hi.

I've searched extensively, but haven't been able to find a solution to my current problem.

The Problem
I have recently installed a version of Transmission to my NAS storage (v1.92 it claims).
And everything SEEMS extremely fine (I really like Transmission).

But, when I try to "seed" existing torrents, Transmission just begins downloading from scratch.
I then tried downloading a completely new torrent, and here it got really spicy.
I selected 3 files (out of app. 72) and started the DL ~ 22Mb of data.
What it seems to be doing, is repeatedly downloading the same segments.
Note: I've tried using different torrents on different trackers!

The Hunch
I've really tried digging through it all, but what it boils down to now, is the gut-feeling I get too many transmission-daemons, and that they somehow keeps corrupting each other files.
(Since the tracked lists me as leeching the above torrent with two clients).

Data

Code: Select all

[~] # uname -a
Linux NASLF 2.6.12.3 #49 Tue May 5 17:38:18 CST 2009 ppc unknown
[~] # transmission-remote -V
Transmission 1.92 (10363)
[~] # ps -gf | grep transmission
 1125 transmis   2484 S   /share/MD0_DATA/.qpkg/Optware/bin/transmission-daemon
 1126 transmis   2484 S   /share/MD0_DATA/.qpkg/Optware/bin/transmission-daemon
 1127 transmis   2484 S   /share/MD0_DATA/.qpkg/Optware/bin/transmission-daemon
 1128 transmis   2484 S   /share/MD0_DATA/.qpkg/Optware/bin/transmission-daemon
 1182 administ    264 S   grep transmission

settings.json

Code: Select all

{
    "alt-speed-down": 50, 
    "alt-speed-enabled": false, 
    "alt-speed-time-begin": 540, 
    "alt-speed-time-day": 127, 
    "alt-speed-time-enabled": false, 
    "alt-speed-time-end": 1020, 
    "alt-speed-up": 50, 
    "bind-address-ipv4": "0.0.0.0", 
    "bind-address-ipv6": "::", 
    "blocklist-enabled": false, 
    "dht-enabled": false, 
    "download-dir": "\/share\/MD0_DATA\/Qdownload", 
    "encryption": 1, 
    "incomplete-dir": "\/share\/MD0_DATA\/Qdownload\/Incomplete", 
    "incomplete-dir-enabled": true, 
    "lazy-bitfield-enabled": true, 
    "message-level": 2, 
    "open-file-limit": 32, 
    "peer-limit-global": 240, 
    "peer-limit-per-torrent": 60, 
    "peer-port": 6750, 
    "peer-port-random-high": 6700, 
    "peer-port-random-low": 6800, 
    "peer-port-random-on-start": false, 
    "peer-socket-tos": 0, 
    "pex-enabled": true, 
    "port-forwarding-enabled": true, 
    "preallocation": 1, 
    "proxy": "", 
    "proxy-auth-enabled": false, 
    "proxy-auth-password": "", 
    "proxy-auth-username": "", 
    "proxy-enabled": false, 
    "proxy-port": 80, 
    "proxy-type": 0, 
    "ratio-limit": 3.0000, 
    "ratio-limit-enabled": true, 
    "rename-partial-files": false, 
    "rpc-authentication-required": true, 
    "rpc-bind-address": "0.0.0.0", 
    "rpc-enabled": true, 
    "rpc-password": "{060b03dc69325fd1527a58720535ebd528f37b82lPcmcCZU", 
    "rpc-port": 9091, 
    "rpc-username": "transmission", 
    "rpc-whitelist": "*", 
    "rpc-whitelist-enabled": false, 
    "speed-limit-down": 100, 
    "speed-limit-down-enabled": false, 
    "speed-limit-up": 100, 
    "speed-limit-up-enabled": false, 
    "umask": 18, 
    "upload-slots-per-torrent": 14, 
    "watch-dir": "\/share\/MD0_DATA\/Qdownload\/Watch", 
    "watch-dir-enabled": true
}

I've seen some issues that seems like this when completing a download (close to 100%) related to clients sending garbled data - and a bug in Transmission, but it should be fixed in v1.92, and it doesn't explain the reseed problem.

Any one able to help? (big question)
Any one able to say if 4 x daemons is as expected? (smaller question)
Any further questions? (I'd be happy to provide additional info - but these posts get really big, really fast!)

[Razorax]

Seems to be a checksum error.
Seems weird if ALL torrents I try to download with Transmission have checksum errors. And none when using uTorrent.

Here's a fragment from the log-file.

Code: Select all

[19:43:59.826] 160 Optical Illusions Piece 0, which was just downloaded, failed its checksum test (peer-mgr.c:1384)
[19:44:00.823] 160 Optical Illusions Piece 12, which was just downloaded, failed its checksum test (peer-mgr.c:1384)
[19:44:02.824] 160 Optical Illusions Piece 5, which was just downloaded, failed its checksum test (peer-mgr.c:1384)
[19:44:04.832] 160 Optical Illusions Piece 0, which was just downloaded, failed its checksum test (peer-mgr.c:1384)
[19:44:05.829] 160 Optical Illusions Piece 18, which was just downloaded, failed its checksum test (peer-mgr.c:1384)

The above mentioned code (peer-mgr.c:1384) refers to inout.c:330, which hasn't changed from v1.92 to the current version (so not a code-problem).
The pieces are downloaded (there are files and folders in the Incomplete folder - with size > 0).

Can it be because I use the below setting?

Code: Select all

settings.json
"rename-partial-files": false

- No: Still bugs with partial-files = true.

Or is it simply because there are some weird problem with byte-order or something with the storing vs. check-sum check of the files?
- No: I even tried mounting the data-drive with smbmount (I know, it's CRIMINAL with regard to performance).

Any suggestions as to how to proceed?

[Jordan]

What version of libc do you have installed? At first blush this sounds like https://trac.transmissionbt.com/ticket/3826

[Razorax]

Thank you for the fast reply.

And you are probably right (I think I remember seeing somewhere that the NAS uses that exact version of uClibc).

Yup:

Code: Select all

[/lib] # ll *Clib*
-rwxr-xr-x    1 administ administ    20352 Aug  4  2005 /lib/ld-uClibc-0.9.27.so
lrwxrwxrwx    1 administ administ       19 Jun  1  2009 /lib/ld-uClibc.so.0 -> ld-uClibc-0.9.27.so
-rwxr-xr-x    1 administ administ   325232 Aug  4  2005 /lib/libuClibc-0.9.27.so
[/lib] #

Then I'd better head over to QNAP forums and troll for how to upgrade that!
Thanks again! You got me closer (after 14 hours of facerolling on the keyboard).

EDIT: Ouch, uclibc cannot really be updated (without a new firmware release). So... crap... need to go the chroot way instead ... sigh

[Razorax]

Well.

I finally managed to get Transmission 2.13 up and running on my QNAP NAS TS-201.
Believe me, it was a struggle!
We're talking: coLinux, Ubuntu, buildroot, a zillion apt-get installs, followed by a trillion adjustments to various download-site-urls.
On the busybox it all repeated (more or less), ipkg install configure, and serious LD_LIBRARY_PATH and PATH hacking.

But, I succeeded!
Only to discover the https://trac.transmissionbt.com/ticket/3826 isn't fixed in 2.13
(Glad I had the source-code, and had just compiled it ).

Well, now to the follow-up question.

It seems I now (libtransmission/fdlimit.c) don't use pread/pwrite, but when I move my .torrents from the PC to the NAS (the actual content stays on the NAS), not all parts are correctly checksummed.
I have content varying from 9-12 Gb per torrent, and they ALL have parts (not all parts mind you) that doesn't "check out" to 100%

Meaning I get around 93-98% completed after verify has run.

I saw somewhere else on the forums something similar (can't find it now), but that was regarding "stalling at 98% due to contiously downloading the failing part".
This one IS already downloaded, but the check fails - and when i Resume the torrents they download the missing 2-8% and start seeding.

Any one knows what bug this is? And where the fix can be found? (make && make install )