Build Transmission on Windows

[rb07]

Fixed stand-alone operation. You can run local sessions now.

Changed to libevent 1.4.14 .

Updated the downloads link viewtopic.php?f=1&t=7612&p=37848#p37848 with the build of version 2.00 release.

I'll update the Wiki next, for those who like to build it themselves. Did not build the GTK+ application... but since most of the changes I made where to libtransmission it may also work (it should).

I'll probably follow Longinus00 advice and start a new thread later, it would be nice to have more people testing, I'm sure there are more little bugs but nothing as big as Diablofan reported above (for those technically inclined: it was select() being used to wait, the Windows select() was just returning an error so the program looped as fast as it could; I changed to gnulib but it turned out it also had a bug on select() when used for waiting).

[Jordan]

That's pretty awesome. I may have to dig out my old Windows drive to give it a spin

rb07: So is the new build using gnulib, or did you drop it after its select() was wrong too? gnulib is a nice library but if possible it would be better to run light and without middleware. Also if you have any portability patches for libtransmission, feel free to open a ticket for them and I'll merge them in the repository.

[rb07]

That's pretty awesome. I may have to dig out my old Windows drive to give it a spin

It should look and work just like the Linux version, thanks for all your hard work.

rb07: So is the new build using gnulib, or did you drop it after its select() was wrong too? gnulib is a nice library but if possible it would be better to run light and without middleware. Also if you have any portability patches for libtransmission, feel free to open a ticket for them and I'll merge them in the repository.

I have 2 builds, one with gnulib, one without. The one for download is without (except the last 2.00b2 version).

The idea is that gnulib is more convenient and probably also more stable. By convenient I mean we could get rid of most Windows specific code (and I see that someone has been busy adding a lot of workarounds for Windows).

I don't see gnulib as "middleware", its just a library. The select() bug was very easy to find and fix, in fact its already fixed on their repository (they included my change). Using it was cleaning a lot of Windows specific code and then just linking that one library.

[Lacrocivious]

rb07--

It looks like you have a winner!

XP Pro SP3 - QTransmission-2.00-Setup.exe

Installer is glitch-free, if a bit redundant (not a problem). Avast! antivirus did not block or affect installation.

If 'launch Transmisison' is selected (as in default) at end of installation, then turtle schedule time settings are greyed out. If Transmission is closed and restarted, schedule is not greyed out and is adjustable.

Blocklist update does not work. After a long time, blocklist update claims it was successful but says the list contains 0 items. File level1.bin appears in \Documents and Settings\Username\Application Data\transmission\blocklists but is a zero-byte file.

In torrent properties dialog, during active torrent phase, Information tab does not update upload amounts, although peers tab does update.

Webui works fine.

I am not certain whether the XP firewall requires a manual entry for the chosen port to be enabled, in addition to the qtr, Transmission Remote, and Transmission-Remote-port entries you already create. I suspect it may be necessary to manually add the chosen port as an exception to enable upload to work. In my case I open a specific port in my gateway/firewall for each LAN station that runs Transmission, and I forward that port to the IP of each respective LAN station.

I am most favorably impressed, sir. Thank you for this excellent work.

[rb07]

The blocklist getting a zero size file is something I've seen a long time ago, before there was QTr... if I remember correctly the application has a hardcoded URL to somewhere in the Transmission Web server, and it always returned a zero size file.

In my servers (running the daemon) I download the blocklist using other means (moBlock or curl or wget)... but it seems that the people using the Mac app do have that part working, I'm not sure about the GTK+ app. Anyway, perhaps the URL could be customized.

I hadn't noticed the part about upload in the info tab being static, I guess I haven't been looking long enough to see that.

The first time you run the application it has to create the "config" directory where it puts several things like settings.json, until it has that file many option will be grayed out because from the app point of view they don't exist. I think the file(s) are created when you close the application, some files like dht.dat are created after long enough time passed and only if you have torrents that use that feature. In Windows XP that "config" directory is (depending on the language) /Documents and Settings/<user name>/Application Data/transmission .

About Windows Firewall, yes, you are correct, the port has to be opened and the firewall usually pops up a panel asking if you want to block the application. I haven't used any firewall at Windows level for a long time, like you, I prefer my firewall on the gateway and map specific ports to servers. That is something you always have to do if you want the tracker to see you as "connectable".

BTW, the Qt application was made by Jordan, he is the one that deserves the credit. I only did some porting to make it work in Windows, not a first class job since I only use the app as a front-end for the server, so many things I haven't really tested (and I did miss the couple of show stoppers that now are fixed).

Thanks for your comments.

[Jordan]

If I had to guess... maybe the fgets() call in blocklist is causing the level1.txt file to be parsed wrong?

[rb07]

If I had to guess... maybe the fgets() call in blocklist is causing this?

You may be right. I did change a lot of file use to binary mode trying to avoid all the silly errors caused by MingW's default of opening files in "text" mode (line endings as the dinosaurs used, CR-LF) which used to cause incorrect .torrents (the binary part had lots of garbage CR).

[Jordan]

If I had to guess... maybe the fgets() call in blocklist is causing this?

You may be right. I did change a lot of file use to binary mode trying to avoid all the silly errors caused by MingW's default of opening files in "text" mode (line endings as the dinosaurs used, CR-LF) which used to cause incorrect .torrents (the binary part had lots of garbage CR).

If that's the case, the first suspect would be the first fopen() in _tr_blocklistSetContent() in libtransmission/blocklist.c.

[rb07]

If that's the case, the first suspect would be the first fopen() in _tr_blocklistSetContent() in libtransmission/blocklist.c.

Nope, I got that one changed ...

Code: Select all

    in = fopen( filename, "rb" );
    if( !in )
    {
        tr_err( err_fmt, filename, tr_strerror( errno ) );
        return 0;
    }

    blocklistClose( b );

    out = fopen( b->filename, "wb+" );

[rb07]

OK, got the blocklist problem figured out, it turns out to be my mistake: in net.c I added those functions at the end (a long time ago and its now included in the original code), inet_pton() is not right, just read this on the Microsof site:

The getaddrinfo function can be used to convert a text string representation of an IP address to an addrinfo structure that contains a sockaddr structure for the IP address and other information. To be used in this way, the string pointed to by the pNodeName parameter must contain a text representation of an IP address and the addrinfo structure pointed to by the pHints parameter must have the AI_NUMERICHOST flag set in the ai_flags member. The string pointed to by the pNodeName parameter may contain a text representation of either an IPv4 or an IPv6 address. The text IP address is converted to an addrinfo structure pointed to by the ppResult parameter. ...

I didn't use the flags! This is another Windows only piece of ... you don't see on Unix.

[rb07]

New upload on the list viewtopic.php?f=1&t=7612&p=37848#p37848

This one fixes the blocklist download problem described by Lacrocivious, thanks again for the report.

[Lacrocivious]

I have just installed QTransmission-2.00-2-Setup.exe over the earlier one on an XP SP3 box.

The blocklist now works as it should on that system.

There were no problems running the new installer on top of the existing installation. All preferences and loaded torrents were kept.

[Jordan]

What, no 2.01 build yet?

[rb07]

What, no 2.01 build yet?

OK, I'm slow... actually didn't know there was a 2.01 until now.

2.00+ is not working. I'm still testing, I'll fix it soon.

One change in 2.00+ for those like me using a remote session, is that it now starts showing the list of torrents very fast, no more 2 - 3 minute delays... that makes it well worth the change to the latest.

[Longinus00]

You know if you guys actually filed bugs these things would probably get fixed faster.