Opened 6 years ago

Closed 5 years ago

#2858 closed Bug (duplicate)

1.80/83 Headless on QNAP/NSLU failing hash check

Reported by: bushbrother Owned by:
Priority: Normal Milestone: None Set
Component: Daemon Version: 1.80
Severity: Major Keywords: needinfo
Cc: bushbrother, mrfabulous88@…, kosi2801+transmissionbt.com@…, japher@…

Description

I upgraded from 1.76 to 1.80 and now my torrents get to about 1% then "go backwards" to 0.2% then up and down, like it cannot save the first chunk. I compiled the 1.83 tarball and that version does the same, in the end I had to compile 1.76 and go back. Now all is working ok.

The error output to the messages file in /var/log says that the downloaded parts never pass the hash check. You can also see this output in the transmission remote gui error field.

For more information please see the Support forum, specifically this post: http://forum.transmissionbt.com/viewtopic.php?f=2&t=9447#p44519

Attachments (5)

utils_malloc_dbg.patch (577 bytes) - added by KyleK 6 years ago.
verify.c (10.9 KB) - added by bushbrother 6 years ago.
fixVerify.patch (4.0 KB) - added by Longinus00 6 years ago.
fixVerify.2.patch (6.7 KB) - added by charles 6 years ago.
fixVerify.3.patch (6.0 KB) - added by charles 6 years ago.

Download all attachments as: .zip

Change History (111)

comment:1 Changed 6 years ago by bushbrother

  • Cc bushbrother added
  • Component changed from Transmission to Daemon

comment:2 Changed 6 years ago by nberlee

  • Cc berlee@… added

comment:3 Changed 6 years ago by nberlee

Same problem with NSLU2 with unslung using optware (ipkg) packages. My /var/log/messages are full with these messages Feb 4 12:03:02 (none) daemon.err transmission-daemon: somefile.txt Piece 185, which was just downloaded, failed its checksum test (peer-mgr.c:1419)

Where the somefile.txt is the file and Piece part varies.

comment:4 Changed 6 years ago by charles

My first thought is that there is a poison peer sending you bad data. Does this problem persist when you try to download, say, an Ubuntu torrent from http://torrent.ubuntu.com:6969/ ?

comment:5 Changed 6 years ago by charles

  • Keywords needinfo added

comment:6 Changed 6 years ago by nberlee

Unless someone who isn't on the blocklist is poising the edubuntu torrent on torrent.ubuntu.com, I guess it's not poising....

# tail /var/log/messages Feb 4 23:05:42 (none) daemon.err transmission-daemon: edubuntu-9.10-dvd-i386.iso Piece 2576, which was just downloaded, failed its checksum test (peer-mgr.c:1419) Feb 4 23:05:49 (none) daemon.err transmission-daemon: edubuntu-9.10-dvd-i386.iso Piece 3398, which was just downloaded, failed its checksum test (peer-mgr.c:1419) Feb 4 23:05:55 (none) daemon.info transmission-daemon: edubuntu-9.10-dvd-i386.iso Learned 10 peers from DHT (tr-dht.c:620) Feb 4 23:05:56 (none) daemon.info transmission-daemon: edubuntu-9.10-dvd-i386.iso Learned 59 peers from DHT (tr-dht.c:620) Feb 4 23:05:59 (none) daemon.err transmission-daemon: edubuntu-9.10-dvd-i386.iso Piece 463, which was just downloaded, failed its checksum test (peer-mgr.c:1419) Feb 4 23:06:01 (none) daemon.err transmission-daemon: edubuntu-9.10-dvd-i386.iso Piece 3, which was just downloaded, failed its checksum test (peer-mgr.c:1419) Feb 4 23:06:02 (none) daemon.err transmission-daemon: edubuntu-9.10-dvd-i386.iso Piece 1139, which was just downloaded, failed its checksum test (peer-mgr.c:1419) Feb 4 23:06:05 (none) daemon.err transmission-daemon: edubuntu-9.10-dvd-i386.iso Piece 1003, which was just downloaded, failed its checksum test (peer-mgr.c:1419) Feb 4 23:06:05 (none) daemon.err transmission-daemon: edubuntu-9.10-dvd-i386.iso Piece 0, which was just downloaded, failed its checksum test (peer-mgr.c:1419) Feb 4 23:06:08 (none) daemon.err transmission-daemon: edubuntu-9.10-dvd-i386.iso Piece 295, which was just downloaded, failed its checksum test (peer-mgr.c:1419)

comment:7 Changed 6 years ago by bushbrother

Agree with nberlee on this one, it doesnt matter what torrent, they keep failing the hash, I cannot even get 1 part. If I use the exact same torrent file with same peers on 1.76 then it all goes fine.

comment:8 Changed 6 years ago by charles

How odd. I'm not seeing that at all...?

If you exit transmission-daemon, then edit setings.json to set "incomplete-dir-enabled" and "rename-partial-files" to false, then restart the daemon on a fresh ubuntu torrent you haven't tried downloading before, does that make the problem go away?

comment:9 Changed 6 years ago by nberlee

I followed your instructions.... but no sigar... It does not make the problem go away...

comment:10 Changed 6 years ago by mrfabulous

Just registered to say that I have the exact same problem, also with Optware transmission-daemon 1.83 on an NSLU with unslung 6.10 beta. Between this and the forum thread I'm seeing a lot of NSLU users confirming this bug, so it would seem there is something about that platform that is triggering this.

I have tried with a variety of torrents from a variety of trackers and the behaviour is consistent. ie every single piece failing checksum

comment:11 Changed 6 years ago by mrfabulous

  • Cc mrfabulous88@… added

comment:12 Changed 6 years ago by bushbrother

  • Summary changed from 1.80/83 Headless on QNAP failing hash check to 1.80/83 Headless on QNAP/NSLU failing hash check

Can i ask what processor the NSLU uses, is it the same that my QNAP TS-201 uses? My feed for optware is the ts101 powerpc, if they are the same it could be architecture related as I have a friend using the TS-219p who does not have any issues with 1.80, but that box used a different processor feed.

comment:13 Changed 6 years ago by nberlee

The NSLU2 uses a CPU: XScale-IXP425/IXC1100 revision 1

Could you check the kernel version as well? Unslung 6.1 uses 2.4.22-xfs (gcc version 3.4.4) by default

I don't think its related, but i found this on the SHA1 library: "The IA32 (Intel) implementation of SHA-1 makes heavy use of the ‘bswapl’ instruction, which is not present on the original 80386. Attempts to use SHA-1 on those processors will cause an illegal instruction trap. (Arguably, the kernel should simply emulate this instruction.) "

I think there might be something wrong with the SHA1_Init/Update/Finish functions on ARM devices... But I am curious why that didn't popup on 1.76... Or are there other changes to the hash calculation charles (comparing to 1.76) ?

comment:14 Changed 6 years ago by kosi2801

I've got the same error already for some time but at first I didn't recognize it. An idea I had was that maybe the openssl-package was updated too when I switched to transmission 1.80 and that the error is located in that package (as this may have also been updated).

Can anyone maybe try around with different openssl-versions for the NSLU2?

comment:15 Changed 6 years ago by kosi2801

  • Cc kosi2801+transmissionbt.com@… added

comment:16 Changed 6 years ago by nberlee

I can't remember that openssl was updated too.... http://trac.nslu2-linux.org/optware/timeline confirms this see 01/21/10

I am using OpenSSL 0.9.7m 23 Feb 2007 (which is the current default optware package)... Looking at the date, I think that this could not be the problem... And would not explain why it suddenly works when downgrading to 1.76 (reported by bushbrothers)

comment:17 Changed 6 years ago by bushbrother

Interesting thought about open-ssl. I used the latest version when I built mine.

To answer nberlee, my QNAP is using 2.6.12 kernel and gcc 3.4.3, at least I think so, I am not that good at linux! I got most of my info for building here:

http://scratchpad.wikia.com/wiki/Open_Turbostation:Software http://mybookworld.wikidot.com/forum/t-65768/building-transmission-with-optware-dependancies

Anyone get any further on sorting this?

comment:18 Changed 6 years ago by dskchk

No problem here with 1.83 and the cs05q1armel feed.

comment:19 Changed 6 years ago by kosi2801

  • Version changed from 1.83 to 1.91

Problem still present with latest 1.91 on NSLU2 - Unslung.

comment:20 Changed 6 years ago by charles

Does verifying existing torrents (as opposed to newly-downloaded pieces) work on the NSLU2?

comment:21 Changed 6 years ago by kosi2801

Verifying existing torrents did work with 1.83 without problems (except that the already downloaded data was a tad smaller after the check for incomplete files, most likely because the not-yet-finished segments were discarded). For 1.91 now I get SEGFAULT on complete and incomplete files. Trying to examine the coredump with gdb reveals nothing (TM seems to be compiled without any debug info or gdb does not work too well on the NSLU2) except

  (gdb) where
  #0  0x4032d820 in ?? () from /lib/libc.so.6

The address changes with each coredump, but so far it has always been in libc.so.6. Furthermore there are no other threads existing (or reachable from within gdb).

  (gdb) info threads
  * 1 process 626  0x4032d820 in ?? () from /lib/libc.so.6
  warning: Couldn't restore frame in current thread, at frame 0
  0x4032d820 in ?? () from /lib/libc.so.6

comment:22 Changed 6 years ago by charles

For 1.91 now I get SEGFAULT on complete and incomplete files

Just to make sure I'm understanding you -- you mean even when verifying existing torrents?

comment:23 Changed 6 years ago by kosi2801

Yes, even for torrents which have already completed before this error with the hash-check appeared. But the plain segfault is new with 1.91.

comment:24 Changed 6 years ago by charles

oy.

Well if the backtraces aren't working the thing to do is go to the code in libtransmission/verify.c and scatter print statements all over it to find out where it's crashing.

comment:25 Changed 6 years ago by kosi2801

Ok, I'd like to help. Anyone present who can give me hints on how I could set up a development environment to be able to compile the sourcecode for the NSLU2? I'm able to code C/C++, but I've never done that before for the NSLU2.

comment:26 Changed 6 years ago by livings124

  • Version changed from 1.91 to 1.80

comment:27 Changed 6 years ago by charles

I don't have any experience building on the NSLU2. My advice would be to try & find an irc forum that could help.

comment:28 Changed 6 years ago by snort_

Tried to upgrade to transmission-daemon 1.92, using unslung 6.2 on NSLU2. Absolutely the same results. Hash checks failing constantly, no upload, etc. with any torrent. (Also destroyed pre-existing half-downloaded torrents) Had to roll back to 1.76. It is not a problem with .PART files and a the 'incomplete' folder path, those were the first things I changed.

comment:29 Changed 6 years ago by charles

If you can't even verify existing files, I suspect this is an error with the build rather than with Transmission. This is probably not going to get resolved until a programmer running unslung steps up and investigates the problem.

comment:30 Changed 6 years ago by KyleK

Maybe we could create a unit test (similar to the other existing tests) that would test the hashing functions? This way it should be easy to see if that particular machine has an issue with the algorithms.

comment:31 Changed 6 years ago by charles

Given how many people have commented on this ticket, I'm a little surprised that this is still hanging out in space like this.

Could someone try making a build with tr_valloc tweaked s.t. it doesn't use any of the valloc/posix_memalign system calls and instead just uses plain old malloc? I'm wondering if valloc/posix_memalign are doing something odd on these embedded machines.

comment:32 follow-up: Changed 6 years ago by bushbrother

Did anyone manage to try out Charles' request? I really would love to help, and I am will into to try and compile any new versions on my QNAP, but what Charles has written is waaaay over my linux knowledge. If someone can provide the modified files, I can do the configure/make commands on my box.

I would really like to see this get solved, I am stuck at 1.76 with no way forward :(

Changed 6 years ago by KyleK

comment:33 in reply to: ↑ 32 ; follow-up: Changed 6 years ago by KyleK

Replying to bushbrother:

Did anyone manage to try out Charles' request? I really would love to help, and I am will into to try and compile any new versions on my QNAP, but what Charles has written is waaaay over my linux knowledge. If someone can provide the modified files, I can do the configure/make commands on my box.

I would really like to see this get solved, I am stuck at 1.76 with no way forward :(

Use the patch I just attached to modify utils.c This will make Transmission always use the normal malloc() instead of valloc(), just as charles suggested.

Attention: This is patch is only for testing purposes, for those that have problems with Transmission on their NAS! Don't use it if your Transmissio works just fine.

comment:34 Changed 6 years ago by kosi2801

I tried building transmission on the NSLU2 following the guideline at http://trac.transmissionbt.com/wiki/HeadlessUsage/NSLU2 but I always end up with an error during ./configure. I tried to comment out various stuff to get past the error, but so far no luck. Any ideas?

    ...
    checking event-config.h presence... no
    checking for event-config.h... no
    configure: WARNING: using our own libevent from third-party/libevent/
    configure: WARNING: if you are cross-compiling this is probably NOT what you want.
    ./configure: ./configure.lineno: 25826: Syntax error: word unexpected (expecting ")")

comment:35 Changed 6 years ago by KyleK

Well, we would need to know what's at line 25826 now, wouldn't we? :)

Could you upload the configure file somewhere so I might have a look? You can also contact me in Transmission's IRC channel at irc.freenode.net #transmission I have some experience building Transmission on a NAS device.

comment:36 Changed 6 years ago by kosi2801

I've packaged all files which are updated by ./autogen.sh into an archive and will keep it available for some time at http://bit.ly/b0dVrx (shortened link to archive file in public dropbox folder, just to keep the id out of Google).

I tried to comment the block surrounding line 25826 in both ./configure and ./configure.lineno, but the error stays the same (and configure.lineno gets aparently re-generated on each ./configure run so commenting there is useless).

hth.

comment:37 Changed 6 years ago by KyleK

Hm, I can't spot any obvious problems in the configure files. It appears configure errors out because GTK is enabled but NLS is not, but I can see that you explicitly disabled both GTK and NLS when calling configure.

That's why I'm thinking the problem must be somewhere else.

Do you have libintl installed? If not, I would suggest removing the test for it entirely from the configure.ac file. Comment out the block at line ~393 where it says "nls=no", then re-run autogen.sh

Also an idea: Do you have a proper version of 'sed' installed, or is it a symbolic link to busybox? Autoconf uses sed extensively, and the busybox version is not as powerful as the real sed.

PS: We should probably move this discussion to the forums or IRC, as this is not really related to the issue reported here.

EDIT: Have you tampered with the configure.ac file? Your configure file is completely missing the checks for GTK.

This might be the reason why the script thinks you want the GTK client (the default is yes, I believe), but have explicitely disabled NLS. That's why it stops at that error message (even though the actual displayed error message is the wrong one).

I suggest you delete the configure.ac, restore it from SVN, then only remove the section about NLS I mentioned earlier, and rerun ./autogen.sh

Last edited 6 years ago by KyleK (previous) (diff)

comment:38 Changed 6 years ago by kosi2801

I've managed to build transmission-daemon directly on my NSLU2 with the help from KyleK, thanks. My own build does not show the behaviour from the .ipk-package and works correctly when downloading files. No checksum errors or similar odd behavior. I reinstalled the 1.92-ipk package and the errors were back almost instantly.

I then switched back to the own-built version again and noticed, that during the first few minutes there were still checksum errors occouring but they got fewer and fewer over time. After some minutes, there were no checksum errors anymore.

This leads me to the suspection that there is not something wrong with the checksum-algorithm but maybe with the storing of the data itself and the check just detects this really corrupted data.

Nevertheless, I'll also try to get in contact with the creator of the package, maybe he can give some more insight into this issue.

comment:39 Changed 6 years ago by charles

It sounds like this is a build error with the -ipk version.

I'm tempted to close this ticket as invalid since I don't think it's Transmission's problem, but at this point I'm curious hear how the issue gets resolved... :)

comment:40 Changed 6 years ago by charles

Any news?

comment:41 follow-up: Changed 6 years ago by kosi2801

Sorry, forgot to post, thanks for reminding me. I was unable to get in contact with the package maintainer, the provided email seems not reachable (anymore).

comment:42 in reply to: ↑ 41 Changed 6 years ago by elmer91

Replying to kosi2801:

Sorry, forgot to post, thanks for reminding me. I was unable to get in contact with the package maintainer, the provided email seems not reachable (anymore).

You may post a message to Yahoo groups: http://tech.groups.yahoo.com/group/nslu2-linux/messages

comment:43 Changed 6 years ago by charles

  • Resolution set to worksforme
  • Status changed from new to closed

Every indication is that this is a packaging error rather than a Transmission bug. If there's something that needs to be done on the Transmission level feel free to reopen this ticket, but I think at this point the onus is on the packagers...

comment:44 in reply to: ↑ 33 Changed 6 years ago by bushbrother

Replying to KyleK:

Use the patch I just attached to modify utils.c This will make Transmission always use the normal malloc() instead of valloc(), just as charles suggested.

OK, I am a little bit slow on Linux, so how do I use this patch when I do a build?

comment:45 follow-up: Changed 6 years ago by kosi2801

At first, you do not need the patch, because if you build yourself, the resulting binary should work without problems (it's just a problem in the downloaded package, as we think so far).

If you want to apply the patch, you could use the 'patch' tool or just look into the patch and make the changes manually, it's just adding two comment-lines, shouldn't be too much of an issue :)

comment:46 in reply to: ↑ 45 Changed 6 years ago by bushbrother

Replying to kosi2801:

At first, you do not need the patch, because if you build yourself, the resulting binary should work without problems (it's just a problem in the downloaded package, as we think so far).

If you want to apply the patch, you could use the 'patch' tool or just look into the patch and make the changes manually, it's just adding two comment-lines, shouldn't be too much of an issue :)

OK, I am building 1.92 as I write this, however I have tried previous versions with no luck. Once I have built it I will try, if it doesnt work I will re-build with the commented lines and try again. I will report back! BTW - off topic, how do I build my compiled files into a .ipk? Just so I can keep some copies!

comment:47 Changed 6 years ago by bushbrother

OK, compiled with and without the patch, doesn't make a difference! I still get the % going backwards with no pieces ever completing :( How can I get out some logs?

BTW I am not using NSLU2, I am using a QNAP TS-201

Last edited 6 years ago by bushbrother (previous) (diff)

comment:48 Changed 6 years ago by nberlee

  • Cc berlee@… removed

comment:49 Changed 6 years ago by bushbrother

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:50 Changed 6 years ago by bushbrother

Re-opened as there are still issues for me even after trying the fixes listed here, I have built on my QNAP and it still fails. I need some help debugging ...

comment:51 Changed 6 years ago by charles

bushbrother: is this a problem with every torrent, or with some torrents?

For example, if you try to download an Ubuntu ISO does the problem persist?

If you take a torrent that you've already downloaded and know is correct, and run "verify" on that torrent, does the checksum test succeed?

comment:52 Changed 6 years ago by charles

@bushbrother: I'd like to figure out what's causing this bug for you, but I haven't heard back from you in a while. Could you please provide the requested information? Thanks!

comment:53 Changed 6 years ago by charles

  • Resolution set to worksforme
  • Status changed from reopened to closed

comment:54 Changed 6 years ago by bushbrother

@charles: Apologies for the delay, busy with work :( It happens with every torrent, even the Ubuntu ones. As soon as I switch back to 1.76 I can download the EXACT same .torrent file with no issues.

I will try what you suggest for the "verify" just so I know I am doing it right, you want me to download a torrent with 1.76, such as Ubuntu ISO, then install 1.92 and run the verify on the completed torrent? How would I know if the checksum is OK or not? Would it report this via transmission remote? Is there a better way to get error logs?

comment:55 Changed 6 years ago by bushbrother

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:56 Changed 6 years ago by charles

Yes. I would suggest downloading a Linux iso with 1.76 and then try to "verify local data" with 1.93 or 2.00b1 and see how that goes.

comment:57 Changed 6 years ago by bushbrother

@charles - OK, ubuntu-9.10-desktop-amd64.iso is currently downloading on 1.76, 15 mins remaining, I will repost with results of "verify local data" using 1.93 soon.

OK, updated to 1.92-1 (that's the build I have made)and the torrent appears as green (completed) in transmission remote. I then press "recheck", it goes through and turns it all grey, then turns red stating "Can't find local data. Try "Set Location" to find it, or restart the torrent to re-download"

Then it starts to download from the beginning, gets to 1.6% then goes down to almost 0% and up again etc ...

Not really sure what to do about that ...

Last edited 6 years ago by bushbrother (previous) (diff)

comment:58 Changed 6 years ago by bushbrother

Any help, still have the same issue as above post ...

comment:59 Changed 6 years ago by charles

I think this ticket should be closed unless there's a QNAP / NSLU packager or maintainer available to investigate this further. If >= 1.9x really was broken like this s.t. no torrents could be verified, there would be a flood of complaints. Therefore my guess is that this is a build issue that's biting some people.

And, again, I'd be interested to hear if 2.0x behaves any differently.

comment:60 Changed 6 years ago by bushbrother

I do agree with your comments ... I find it odd that there is nobody else with the same problem, I will try latest version over the weekend and let you know. Thanks for your help!

comment:61 Changed 6 years ago by bassie112

Well, I have the same problem. See also this thread: https://forum.transmissionbt.com/viewtopic.php?f=2&t=9447&p=48372#p48372

From builds >1.76 up to the latest build (2.04) the problem persists. It must have something to do with the build as every time I upgrade I get the same problem and as soon as I go back to version 1.76 there is no problem at all. I really don't know what the problem is and I am pretty sure it is not my setup or config...

Really annoying as I do like the newer features of Transmission :(

Last edited 6 years ago by bassie112 (previous) (diff)

comment:62 Changed 6 years ago by bushbrother

I have tried 2.04 and I get the same :( I have even compiled on my QNAP and I get the same result ...

comment:63 follow-up: Changed 6 years ago by charles

I noticed earlier today that QNAP is now doing their own Transmission builds. How do those work for you?

http://forum.qnap.com/viewtopic.php?p=148064#p148064

comment:64 in reply to: ↑ 63 ; follow-up: Changed 6 years ago by bassie112

Replying to charles:

I noticed earlier today that QNAP is now doing their own Transmission builds. How do those work for you?

http://forum.qnap.com/viewtopic.php?p=148064#p148064

Maybe a stupid question, but is it possible to install these qpkg's on the NSLU2? They seem much bigger in size (RAM? CPU?).

I still can't find a workking 2.04 package for the NSLU2. So right now I'm trying to build one myself although I don't have any experience in this :).

EDIT: I can't get the compiler to work. I always get this erro message: "error: no acceptable C compiler found in $PATH". That's probably because there is no gcc package available for an unslung NSLU2... So this is not going to work with my knowledge.

Hopefully somebody can compile a working transmission version (>1.76) for us unslung users.

Last edited 6 years ago by bassie112 (previous) (diff)

comment:65 in reply to: ↑ 64 Changed 6 years ago by charles

Replying to bassie112:

Replying to charles:

I noticed earlier today that QNAP is now doing their own Transmission builds. How do those work for you?

http://forum.qnap.com/viewtopic.php?p=148064#p148064

Maybe a stupid question, but is it possible to install these qpkg's on the NSLU2? They seem much bigger in size (RAM? CPU?).

I have no idea how to install those on NSLU2. I've never used either system.

comment:66 Changed 6 years ago by bushbrother

@Charles - thanks for the link but my QNAP is running a PPC CPU and not ARM so I cannot use their packages. I am thinking this may be a case of outdated HW now as my box is over 4 years old. Perhaps I should just spend some money :)

comment:67 Changed 6 years ago by charles

  • Resolution set to worksforme
  • Status changed from reopened to closed

Okay.

I still stand by my call of 5 months ago that this is a packaging error rather than a Transmission bug. If Transmission were truly unable to verify even existing, known-valid torrents, we would have been flooded with reports.

comment:68 Changed 6 years ago by snort_

You are probably not getting any report is because at the NSLU wiki it is explicitly stated that the last working version of transmission is 1.76, so given that the SLUG community is not that big, and anybody who looks for advice there are bound not to try out later versions, it is quite understandable that we are not flooding you. Anyway I was following this ticket thread in the hopes of somebody turning up with sensible advice. Maybe nobody else is interested, only me and bushbrother :)

Anyway, it seems that the good people at NSLUwiki are pointing at Transmission, while the good people here pointing back at the NSLU packagers. I guess that is all there is to it then.

comment:69 Changed 6 years ago by kosi2801

@snort_ - It's not only you two, I'm also very interested in getting more recent Transmission versions runnable on my NSLU. With the help of KyleK_ some time ago I was able to perform a source build (with minimal changes) from SVN. This build worked without any problems on my NSLU, so I just can agree with charles that everything is pointing to a packaging error.

I tried to get in touch with the NSLU packager for Transmission but failed and got no response. If someone knows that person or has a different contact to him/her, maybe a pointer to this thread would be nice.

Furthermore I also tried to update the build-page which explains building Transmission on the NSLU2 (because the instructions there are also not up-to-date anymore) but failed again as it required a certain privilege to edit the page and I couldn't find another way of contacting anyone who could perform the updates.

Just in case: the configure-command which is required to build Transmission up to 1.96 (or something around that, it doesn't work anymore on later SVN versions as some requirements seem to have changed) on the NSLU2 itself is following:

 ./configure --prefix=/opt --datadir=/opt/share/ --disable-gtk --disable-nls --with-zlib=/opt CPPFLAGS=-DTR_EMBEDDED ZLIB_LDFLAGS=-lz 

Maybe this helps somebody with a custom build...

Last edited 6 years ago by kosi2801 (previous) (diff)

comment:70 Changed 6 years ago by bassie112

Hmm I still get the same compiling error as above for the source versions of 1.76, 1.93, and 2.04. Maybe someone could help in pointing out what I'm doing wrong, I'm pretty new to this stuff :). This is what I'm doing:

1) Installed dependencies (not all available, nonetheless the required ones should be there):

ipkg install unslung-devel crosstool-native crosstool-native-lib crosstool-native-inc crosstool-native-bin crosstool-native-arch-lib crosstool-native-arch-inc crosstool-native-arch-bin gawk build-essential automake autoconf libtool pkg-config libcurl4-openssl-dev intltool libxml2-dev libgtk2.0-dev libnotify-dev libglib2.0-dev libevent-dev gcc libtool gettext intltool automake autoconf OpenSSL libcurl GTK+ libnotify DBUS optware-devel openssl-dev libcurl-dev

2) Remove old transmission versions from NSLU2:

killall transmission-daemon

ipkg remove transmission

3) Transfer transmission source-tarball to root of NSLU2

4) Building (for version 1.76, which should work):

tar xvjf transmission-1.76.tar.bz2

cd transmission-1.76

./configure --prefix=/opt --datadir=/opt/share/ --disable-gtk --disable-nls --with-zlib=/opt CPPFLAGS=-DTR_EMBEDDED ZLIB_LDFLAGS=-lz


I always get this output (or similar):

checking for a BSD-compatible install... ./install-sh -c

checking whether build environment is sane... yes

checking for a thread-safe mkdir -p... ./install-sh -c -d

checking for gawk... no

checking for mawk... no

checking for nawk... no

checking for awk... no

checking whether make sets $(MAKE)... no

checking how to create a ustar tar archive... plaintar

checking build system type... armv5b-unknown-linux-gnueabi

checking host system type... armv5b-unknown-linux-gnueabi

checking for style of include used by make... none

checking for gcc... no

checking for cc... no

checking for cl.exe... no

configure: error: in `/transmission-1.76':

configure: error: no acceptable C compiler found in $PATH

See `config.log' for more details.

Last edited 6 years ago by bassie112 (previous) (diff)

comment:71 follow-up: Changed 6 years ago by charles

Probably best to move this out of the bug tracker to the forums since we're talking about a configuration issue now rather than a bug.

Looks like gcc can't be found. Is it in your path? If not, put it in your path. If it's already there, post your config.log.

comment:72 in reply to: ↑ 71 Changed 6 years ago by bassie112

Replying to charles:

Probably best to move this out of the bug tracker to the forums since we're talking about a configuration issue now rather than a bug.

Looks like gcc can't be found. Is it in your path? If not, put it in your path. If it's already there, post your config.log.

Well, I fixed this, and it now configures well but I still get errors after the make command (for 1.76, 1.93, 2.04). I'm no expert in this so I don't think I'll manage from here.

Looks like few people are willing to use transmission >1.76 on a NSLU2... So my best bet is to just wait for newer versions and hopefully one works. Although I don't think that is going to happen with no builder looking into this.

comment:73 Changed 6 years ago by bushbrother

@charles - I have a working build environment on my NAS and would like to try out some of the different build parameters that might help get this working. Is there anywhere where I can see what these are and what each one does? i.e. for the line:

./configure --prefix=/opt --datadir=/opt/share/ --disable-gtk --disable-nls --with-zlib=/opt CPPFLAGS=-DTR_EMBEDDED ZLIB_LDFLAGS=-lz

I currently understand the --disable commands but the rest are a mystery to me :)

comment:74 Changed 6 years ago by bushbrother

OK, tried building 2.04 again using the following:

./configure --prefix=/opt --datadir=/opt/share/ --disable-gtk --disable-nls --with-zlib=/opt CPPFLAGS=-DTR_EMBEDDED ZLIB_LDFLAGS=-lz

This builds fine and I can run transmission, I told it to output the log file which is full of the following errors when downloading a file:

[14:43:22.550] Filename.avi Piece 275, which was just downloaded, failed its checksum test (peer-mgr.c:1466)

If i leave it running, the percentage keeps climbing and dropping for a while, but overall climbing a little, then the torrent suddenly pauses. The log shows:

[14:48:33.173] Filename.avi write failed for "Filename.avi": Invalid argument (inout.c:154)
[14:48:33.173] Filename.avi Pausing (torrent.c:1513)
[14:48:33.173] Saved "/share/MD0_DATA/Qdownload/.config/resume/Filename.avi.1a1f0a125c483c31.resume" (bencode.c:1651)

Looks to me like "tr_ioTestPiece" is failing by failing "uint8_t hash[SHA_DIGEST_LENGTH]". I also noted when doing "./configure" that fallocate64, posix_fallocate, and posix_memalign all state "no", valloc says "yes" but there is no mention of malloc (as mentioned higher in this thread), do any of these matter?

Any further ideas? I have reached my knowledge limit!

Last edited 6 years ago by bushbrother (previous) (diff)

comment:75 Changed 6 years ago by cfp

RE: 'Hopefully somebody can compile a working transmission version (>1.76) for us unslung users.'

Ready to use compiled version 1.76 for nslu2 here:

http://computerfixpro.com/Transmission-176-NSLU2.zip

Last edited 6 years ago by cfp (previous) (diff)

comment:76 Changed 6 years ago by bushbrother

Anyone got any suggestions on my errors above?

comment:77 Changed 6 years ago by bushbrother

OK, looking further into this, in "inout.c" from 1.76:

recalculateHash( tr_torrent       * tor,
                 tr_piece_index_t   pieceIndex,
                 void             * buffer,
                 size_t             buflen,
                 uint8_t          * setme )
{
    size_t   bytesLeft;
    uint32_t offset = 0;
    tr_bool  success = TRUE;
    uint8_t  stackbuf[MAX_STACK_ARRAY_SIZE];
    SHA_CTX  sha;

    /* fallback buffer */
    if( ( buffer == NULL ) || ( buflen < 1 ) )
    {
        buffer = stackbuf;
        buflen = sizeof( stackbuf );
    }

    assert( tor != NULL );
    assert( pieceIndex < tor->info.pieceCount );
    assert( buffer != NULL );
    assert( buflen > 0 );
    assert( setme != NULL );

    SHA1_Init( &sha );
    bytesLeft = tr_torPieceCountBytes( tor, pieceIndex );

    while( bytesLeft )
    {
        const int len = MIN( bytesLeft, buflen );
        success = !tr_ioRead( tor, pieceIndex, offset, len, buffer );
        if( !success )
            break;
        SHA1_Update( &sha, buffer, len );
        offset += len;
        bytesLeft -= len;
    }

    if( success )
        SHA1_Final( setme, &sha );

    return success;
}

becomes this in 2.04:

recalculateHash( tr_torrent       * tor,
                 tr_piece_index_t   pieceIndex,
                 uint8_t          * setme )
{
    size_t   bytesLeft;
    uint32_t offset = 0;
    tr_bool  success = TRUE;
    const size_t buflen = 1024 * 256; /* 256 KiB buffer */
    void * buffer = tr_valloc( buflen );
    SHA_CTX  sha;

    assert( tor != NULL );
    assert( pieceIndex < tor->info.pieceCount );
    assert( buffer != NULL );
    assert( buflen > 0 );
    assert( setme != NULL );

    SHA1_Init( &sha );
    bytesLeft = tr_torPieceCountBytes( tor, pieceIndex );

    tr_ioPrefetch( tor, pieceIndex, offset, bytesLeft );

    while( bytesLeft )
    {
        const int len = MIN( bytesLeft, buflen );
        success = !tr_ioRead( tor, pieceIndex, offset, len, buffer );
        if( !success )
            break;
        SHA1_Update( &sha, buffer, len );
        offset += len;
        bytesLeft -= len;
    }

    if( success )
        SHA1_Final( setme, &sha );

    tr_free( buffer );
    return success;
}

This is where my box is failing, any way to revert to old method of hash check while keeping 2.04 features? I have tried recompile but I get many many errors!

comment:78 Changed 6 years ago by charles

At a wild guess I'd say replace the tr_valloc() call with a tr_malloc() call and test that.

comment:79 Changed 6 years ago by bushbrother

@charles - just tried that, compiles fine, still the exact same message. I even managed to swap the whole recalculateHash() function from 1.76 into 2.04 and get it to recompile with a few changes in some other .c files to ensure values are passed to the function, still a no go ... I guess I give up.

I have wasted too much of your time (and mine!) :(

I did notice that the "recheck" button in my transmission gui does nothing in versions above 1.76 too, probably related. In 1.76 pressing this puts "checking" against the file ...

Last edited 6 years ago by bushbrother (previous) (diff)

comment:80 Changed 6 years ago by bassie112

Just to let ya all know, the new version 2.10 downloads ok and appears to download correct data. Although after completion the data is not! Also rechecking of data shows that no data is correct, however it is correct because it was downloaded with 1.76!

Strange... but I have the idea a working version is getting closer.

Last edited 6 years ago by bassie112 (previous) (diff)

comment:81 follow-up: Changed 6 years ago by bushbrother

Just compiled 2.10 and indeed it does start to get some pieces, although it is VERY slow and still hash failing most. It IS climbing slowly. I will see what happens if it gets to 100%. So some progress ...

comment:82 in reply to: ↑ 81 ; follow-up: Changed 6 years ago by bassie112

Replying to bushbrother:

Just compiled 2.10 and indeed it does start to get some pieces, although it is VERY slow and still hash failing most. It IS climbing slowly. I will see what happens if it gets to 100%. So some progress ...

I use the optware version for an unslung NSLU2 and the speed is actually ok (same as 1.76). Also the data-checking during downloading is ok. Only when I try to do something with the completed files or try to do a recheck of data is goes wrong. So actually something is not right but is does download with this build.

comment:83 in reply to: ↑ 82 Changed 6 years ago by Longinus00

Replying to bassie112:

Replying to bushbrother:

Just compiled 2.10 and indeed it does start to get some pieces, although it is VERY slow and still hash failing most. It IS climbing slowly. I will see what happens if it gets to 100%. So some progress ...

I use the optware version for an unslung NSLU2 and the speed is actually ok (same as 1.76). Also the data-checking during downloading is ok. Only when I try to do something with the completed files or try to do a recheck of data is goes wrong. So actually something is not right but is does download with this build.

Can you test if the patch in ticket #3622 fixes your verification problem?

comment:84 Changed 6 years ago by bushbrother

I compiled with the revised verify.c file and I get the same results. Before (pre 2.10) I was getting no pieces completing, and I had floods of "hash failed" errors as above. Now if I download a file with ~300 x 512kb pieces I get the first piece within a few seconds, but then the log is full of the same hash check fails and it takes about 3 mins and 20MB of data downloaded to get the 2nd piece. Eventually after about 12 pieces the torrent fails stating invalid argument.

So it has the same issues as my above logs, but its slightly improved and can actually verify SOME data!

comment:85 follow-up: Changed 6 years ago by Longinus00

The patch shouldn't have any affect on downloading, I was hoping it might solve bassie112's verifying problem.

comment:86 in reply to: ↑ 85 Changed 6 years ago by bassie112

Replying to Longinus00: &gt; The patch shouldn't have any affect on downloading, I was hoping it might solve bassie112's verifying problem.

How can I apply this patch? I don't have any experience with this and as you can read in my previous comments I'm also not grade A compiler :p. So if it's not too hard I can give it a try...

Last edited 6 years ago by bassie112 (previous) (diff)

Changed 6 years ago by bushbrother

comment:87 follow-up: Changed 6 years ago by bushbrother

@bassie112, I just modified verify.c to reflect changes outlined in the patch, not sure if that was the right way to do it though! Just download my modified file and replace the verify.c in the folder "libtransmission" and then compile and build again :)

comment:88 in reply to: ↑ 87 Changed 6 years ago by bassie112

Replying to bushbrother:

@bassie112, I just modified verify.c to reflect changes outlined in the patch, not sure if that was the right way to do it though! Just download my modified file and replace the verify.c in the folder "libtransmission" and then compile and build again :)

I tried to build version 2.10 with the patch on my NSLU2. But I still get build errors. The "configure" and "make" logs are below. I have to be honest that I don't know exactly what I'm doing. So in case I'm totally in the wrong direction I will have to stop trying. please give me some advice what to do :).

"Configure"-log:

# ./configure --prefix=/opt --datadir=/opt/share/ --disable-gtk --disable-nls --                                                                             with-zlib=/opt LDFLAGS=-L/opt/lib LIBEVENT_CFLAGS=-L/opt/include CPPFLAGS=-DTR_E                                                                             MBEDDED ZLIB_LDFLAGS=-lz
checking for a BSD-compatible install... /opt/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking how to create a ustar tar archive... gnutar
checking build system type... armv5b-unknown-linux-gnu
checking host system type... armv5b-unknown-linux-gnu
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /opt/bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /opt/armeb/armv5b-softfloat-linux/bin/ld
checking if the linker (/opt/armeb/armv5b-softfloat-linux/bin/ld) is GNU ld... y                                                                             es
checking for BSD- or MS-compatible name lister (nm)... /opt/armeb/armv5b-softflo                                                                             at-linux/bin/nm -B
checking the name lister (/opt/armeb/armv5b-softfloat-linux/bin/nm -B) interface                                                                             ... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 98304
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /opt/armeb/armv5b-softfloat-linux/bin/ld option to reload object fi                                                                             les... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /opt/armeb/armv5b-softfloat-linux/bin/nm -B output fro                                                                             m gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/opt/armeb/armv5b-softfloat-linux/bin/ld) suppo                                                                             rts shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking dependency style of gcc... (cached) gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /opt/armeb/armv5b-softfloat-linux/bin/ld
checking if the linker (/opt/armeb/armv5b-softfloat-linux/bin/ld) is GNU ld... y                                                                             es
checking whether the g++ linker (/opt/armeb/armv5b-softfloat-linux/bin/ld) suppo                                                                             rts shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/opt/armeb/armv5b-softfloat-linux/bin/ld) suppo                                                                             rts shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for inline... inline
checking gcc version... 3.3.5
checking for ANSI C header files... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking for iconv_open... yes
checking for pread... yes
checking for pwrite... yes
checking for lrintf... no
checking for strlcpy... no
checking for daemon... yes
checking for dirname... yes
checking for basename... yes
checking for strcasecmp... yes
checking for localtime_r... yes
checking for fallocate64... no
checking for posix_fallocate... yes
checking for memmem... yes
checking for strtold... yes
checking for syslog... yes
checking for valloc... yes
checking for getpagesize... yes
checking for posix_memalign... yes
checking whether make sets $(MAKE)... (cached) yes
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for library containing cos... -lm
checking for library containing socket... none required
checking for library containing gethostbyname... none required
checking for pkg-config... /opt/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for OPENSSL... yes
checking for LIBCURL... yes
checking for /tmp/dummy1_zlib.h... yes
checking for library containing gzopen... none required
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for lseek64... yes
checking whether posix_fadvise is declared... yes
checking for posix_fadvise... yes
checking sys/inotify.h usability... no
checking sys/inotify.h presence... no
checking for sys/inotify.h... no
checking sys/event.h usability... no
checking sys/event.h presence... no
checking for sys/event.h... no
checking xfs/xfs.h usability... no
checking xfs/xfs.h presence... no
checking for xfs/xfs.h... no
checking how to copy va_list... va_copy
checking for clock_gettime in -lrt... yes
configure: Using user-specified LIBEVENT_LIBS and LIBEVENT_CFLAGS
checking for GTK... Package gtk+-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gtk+-2.0' found
no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating transmission-gtk.spec
config.status: creating cli/Makefile
config.status: creating daemon/Makefile
config.status: creating extras/Makefile
config.status: creating libtransmission/Makefile
config.status: creating utils/Makefile
config.status: creating third-party/Makefile
config.status: creating third-party/miniupnp/Makefile
config.status: creating third-party/libnatpmp/Makefile
config.status: creating third-party/dht/Makefile
config.status: creating macosx/Makefile
config.status: creating gtk/Makefile
config.status: creating gtk/icons/Makefile
config.status: creating web/Makefile
config.status: creating web/images/Makefile
config.status: creating web/images/buttons/Makefile
config.status: creating web/images/graphics/Makefile
config.status: creating web/images/progress/Makefile
config.status: creating web/javascript/Makefile
config.status: creating web/javascript/jquery/Makefile
config.status: creating web/stylesheets/Makefile
config.status: creating po/Makefile.in
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing po/stamp-it commands


Configuration:

   Source code location:                              .
   Compiler:                                          g++

   Build Command-Line client:                         yes

   Build GTK+ client:                                 no

     Optional dependencies for GTK+ client:

      * dbus support:                                 no
      * gio for watchdir support:                     no
      * libnotify for 'download completed' popups:    no
      * libcanberra for 'download completed' sounds:  no
      * gconf2 to register as a magnet link handler:  no
      * libappindicator for an Ubuntu-style tray:     no

   Build Daemon:                                      yes

   Build Mac client:                                  no

"Make"-log:

# make install
Making install in extras
make[1]: Entering directory `/transmission-2.10/extras'
make[2]: Entering directory `/transmission-2.10/extras'
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/transmission-2.10/extras'
make[1]: Leaving directory `/transmission-2.10/extras'
Making install in third-party
make[1]: Entering directory `/transmission-2.10/third-party'
make[1]: Nothing to be done for `install'.
make[1]: Leaving directory `/transmission-2.10/third-party'
Making install in libtransmission
make[1]: Entering directory `/transmission-2.10/libtransmission'
  CC     announcer.o
  CC     bandwidth.o
  CC     bencode.o
  CC     bitfield.o
  CC     blocklist.o
  CC     cache.o
  CC     clients.o
  CC     completion.o
  CC     ConvertUTF.o
  CC     crypto.o
  CC     fdlimit.o
  CC     handshake.o
handshake.c: In function `canRead':
handshake.c:1030: warning: `ret' might be used uninitialized in this function
bitset.h: At top level:
bitset.h:46: warning: inlining failed in call to `tr_bitsetReserve'
bitset.h:127: warning: called from here
  CC     history.o
  CC     inout.o
  CC     json.o
  CC     JSON_parser.o
JSON_parser.c:291:3: warning: "/*" within comment
  CC     list.o
  CC     magnet.o
  CC     makemeta.o
  CC     metainfo.o
  CC     natpmp.o
  CC     net.o
net.c: In function `tr_netSetCongestionControl':
net.c:240: warning: unused parameter `s'
net.c:240: warning: unused parameter `algorithm'
  CC     peer-io.o
  CC     peer-mgr.o
peer-mgr.c: In function `pieceListSort':
peer-mgr.c:839: warning: `compar' might be used uninitialized in this function
bitset.h: At top level:
bitset.h:46: warning: inlining failed in call to `tr_bitsetReserve'
bitset.h:127: warning: called from here
  CC     peer-msgs.o
peer-msgs.c: In function `tr_generateAllowedSet':
peer-msgs.c:621: warning: cast increases required alignment of target type
gcc: Internal error: Terminated (program cc1)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [peer-msgs.o] Error 1
make[1]: Leaving directory `/transmission-2.10/libtransmission'
make: *** [install-recursive] Error 1

comment:89 follow-up: Changed 6 years ago by bushbrother

Hmmm, I am no expert either I am afraid :( It configures fine, so there must be something odd going on at build. You could try to delete all the .o files created and build again, other than that perhaps someone else can assist ...

comment:90 in reply to: ↑ 89 ; follow-up: Changed 6 years ago by bassie112

Replying to bushbrother:

Hmmm, I am no expert either I am afraid :( It configures fine, so there must be something odd going on at build. You could try to delete all the .o files created and build again, other than that perhaps someone else can assist ...

Btw is it possible to simply overwrite a file (or a portition of code) for a transmission install with your (verify.c) patch? In other words, applying it to an install instead of a build.

comment:91 in reply to: ↑ 90 Changed 6 years ago by bushbrother

Replying to bassie112:

Replying to bushbrother:

Hmmm, I am no expert either I am afraid :( It configures fine, so there must be something odd going on at build. You could try to delete all the .o files created and build again, other than that perhaps someone else can assist ...

Btw is it possible to simply overwrite a file (or a portition of code) for a transmission install with your (verify.c) patch? In other words, applying it to an install instead of a build.

As far as I understand, yes, as if you make a mistake in a .c file then run ./configure it will error out in compile, so it reflects what you have changed in the .c file.

comment:92 Changed 6 years ago by bassie112

I think I'm going to setup my Popcorn Hour A-200 as a Transmission torrent machine as my private tracker has banned versions lower than 1.93 of transmission :(. And I can't do anything more with my limited building knowledge...

Hopefully in the (near) future there will be a working version of transmission for my NSLU2 but till then I need to jump ship.

Last edited 6 years ago by bassie112 (previous) (diff)

comment:93 Changed 6 years ago by Longinus00

I have a new patch for you guys to try.

Changed 6 years ago by Longinus00

comment:94 Changed 6 years ago by Longinus00

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:95 follow-up: Changed 6 years ago by bushbrother

@Longinus00, is there an easy way to convert the .patch to a modified .c file without doing it manually? Sorry, bit new to this stuff ... THANKS!

comment:96 in reply to: ↑ 95 Changed 6 years ago by Longinus00

Replying to bushbrother:

@Longinus00, is there an easy way to convert the .patch to a modified .c file without doing it manually? Sorry, bit new to this stuff ... THANKS!

From the root of the source directory

patch -p0 < fixVerify.patch

Changed 6 years ago by charles

comment:97 follow-up: Changed 6 years ago by charles

Longinus00: fixVerify.2.patch addresses the changes I mentioned in IRC. Seems to be working in testing but needs another pair of eyes. :)

comment:98 in reply to: ↑ 97 ; follow-up: Changed 6 years ago by Longinus00

Replying to charles:

Longinus00: fixVerify.2.patch addresses the changes I mentioned in IRC. Seems to be working in testing but needs another pair of eyes. :)

Won't this cause an infinite loop if it returns EOF on a read?

comment:99 in reply to: ↑ 98 Changed 6 years ago by charles

Replying to Longinus00:

Replying to charles:

Longinus00: fixVerify.2.patch addresses the changes I mentioned in IRC. Seems to be working in testing but needs another pair of eyes. :)

Won't this cause an infinite loop if it returns EOF on a read?

sigh yes, that looks like a familiar refrain too.

Changing that particular section to this should fix that case, but is unsatisfying -- should we be more generous with write returning 0, such as retrying? Is it a case likely to ever occur?

const int rc = readOrWriteBytes( tor->session, tor, ioMode, fileIndex, fileOffset, buf, file_bytes );
if( rc <= 0 ) {
    err = rc < 0 ? errno : EINVAL;
    ...
} else {
    buf += rc;
    ...
}

Changed 6 years ago by charles

comment:100 Changed 6 years ago by japher

  • Cc japher@… added

comment:101 Changed 6 years ago by charles

Longinus00, do you have an opinion on fixVerify.3.patch?

comment:102 Changed 6 years ago by Longinus00

While the logic looks fine, why not put the "rc <= 0" check on line 147?

comment:103 Changed 6 years ago by charles

because errno is undefined on line 149 when rc==0 and ioMode==TR_IO_READ or ioMode==TR_IO_WRITE

comment:104 Changed 5 years ago by charles

This sounds an awful lot like the stuff being discussed (and solved) in https://forum.transmissionbt.com/viewtopic.php?f=2&t=10896 ... is anyone still watching this ticket who can evaluate that thread?

comment:105 Changed 5 years ago by mike3e

Hi, after some struggling with configure file (libevent was not recognized and intltool is still being used regardless of --disable-nls option) I was able to compile newest svn version of Transmission on my NSLU2.

That being said, official Ubuntu torrent have just finished downloading without errors. So that must have been the problem.

Big thanks to iz0bbz, AAS and charles for making the greatest torrent client usable again on embedded devices.

comment:106 Changed 5 years ago by charles

  • Resolution set to duplicate
  • Status changed from reopened to closed

Very nice. Thanks for the confirmation!

Closing this ticket as a dupe of #3826

Note: See TracTickets for help on using tickets.