Transmission Style view of torrent list always shows "0 connected peers".

[GoogleCodeExporter]

All torrents are, in the "Transmission Style" view of the torrent list, shown 
with 0 connected peers for me. That is, the torrent status displays for example 
"Downloading from 4 of 0 connected peers" and so on. I'm on Arch Linux, and 
this happens both with the GTK3 and the GTK2 builds, respectively available 
from:

https://aur.archlinux.org/packages/transmission-remote-gtk/

and

https://aur.archlinux.org/packages/transmission-remote-gtk2/

There's nothing special about my system; newly installed arch, with stock 
transmission-cli 2.82-1...

The only possible non-standard thing is that my user "transmission" has its 
home directory moved from /var/lib/transmission to /home/transmission (so as to 
provide a bit of room for it) -- but I don't suppose any hardcoding of that 
directory is going on in transmission-remote-gtk that could explain this? I 
can't easily test moving it back. 

Original issue reported on code.google.com by rene.her...@gmail.com on 21 Apr 2014 at 7:40

[GoogleCodeExporter]

I'm noticing that it by the way also always shows "Remaining time unknown" for 
each torrent, currently downloading or not, which seems likely to be connected, 
in the sense of "things that bomb out" ...

Original comment by rene.her...@gmail.com on 21 Apr 2014 at 7:59

[GoogleCodeExporter]

Additional information: transmission's web-interface (at 
http://localhost:9091/transmission/web/) reports "Downloading from X of Y 
connected peers" correctly.

Original comment by rene.her...@gmail.com on 21 Apr 2014 at 10:04

[GoogleCodeExporter]

Hi,

Strange, I can't think how the download directory would matter. Does this 
happen in the classic view too?

Was struggling to figure out why this might be, but think I might have found 
something.

If it was compiled in debug mode, either intentionally (with ./configure 
--enable-debug) or unintentionally (maybe some library #include sets -DDEBUG?, 
maybe). Can you think why that might be?

In this case, the set operations on the model are done individually, and it 
looks like eta and connected peers were missing from that path. This was used 
quite a long time ago to help with debugging, but probably not needed anymore, 
so I've disabled it.

Can you try with the latest git?

Thanks.

Original comment by a...@eth0.org.uk on 23 Apr 2014 at 9:51

[GoogleCodeExporter]

Thanks for the reply. No, this does not happen in the classic view, in the 
sense that it shows non-zero entries in the "connected" column where 
appropriate.

The arch versions that I'm testing with are not, intentionally, compiled in 
debug mode. The arch build-scripts (the PKGBUILDs) are at:

https://aur.archlinux.org/packages/tr/transmission-remote-gtk/PKGBUILD
https://aur.archlinux.org/packages/tr/transmission-remote-gtk2/PKGBUILD

and are quite generic. As to unintentionally -- no, I can't think of any reason 
why they would be and when browsing the source just now, I believe to have made 
doubly sure that DEBUG is not defined during the build. I do tend to loose my 
way around the GNU autotools fairly easily: if you would want me to make triply 
sure, could you provide me with a specific spot to stick some sort of #pragma 
in so as to make the build bomb out if DEBUG IS in fact defined, or something 
similar?

However -- yes, I could try git. Also through the AUR by the way; there's a 
helpful package at:

https://aur.archlinux.org/packages/transmission-remote-gtk-git/

that checks it out of git and then builds:

https://aur.archlinux.org/packages/tr/transmission-remote-gtk-git/PKGBUILD

Its "Tranmission View" shows the same behavior. Still "Downloading from X of 0 
connected peers" for any value of X. Its compact view seems the same as well -- 
and its classic view actually bombs out: I only get a blank screen in the 
classic view with the git version; a bright-white "bar" at the top, supposedly 
of vertical size equal to the torrent list, and then a grey remainder of the 
window.

But yes therefore, still the same behavior of the Tranmission View in current 
git as in the arch package(s). Yet -- your suspicion above certainly SOUNDS 
like it would be relevant (although I don't understand why supposedly not 
everybody on arch is seeing this...) so I wonder. I have as said tried to make 
doubly sure -- if you would like me to make triply sure, please coach as to 
how... :-/

Original comment by rene.her...@gmail.com on 23 Apr 2014 at 7:45

[GoogleCodeExporter]

And by the way -- just to make sure that I wasn't looking at some very specific 
issue with specific torrents, I just now started a very popular one; Linux Mint 
"16":

http://torrents.linuxmint.com/torrents/linuxmint-16-cinnamon-dvd-32bit.iso.torre
nt

and am currently again looking at the status message "Downloading from 13 of 0 
connected peers". That is -- I'm definitely not dreaming...

Original comment by rene.her...@gmail.com on 23 Apr 2014 at 7:51

[GoogleCodeExporter]

Mmm. Noticing that "32-bit" in the linuxmint URL, let me also make explicit 
that this is on a 32-bit (x86) system, since it might in fact be the case that 
THAT is starting to be rare for desktop systems...

For this to be relevant it seems there should also be some sort of 
big/little-endian confusion somewhere (ie, a big-endian 64-bit long that gets 
its actual value chopped off in some implicit conversion to 32-bit) which seems 
rather unlikely -- but I thought I'd mention it anyway, in case it gives you an 
idea.

Original comment by rene.her...@gmail.com on 24 Apr 2014 at 6:18

[GoogleCodeExporter]

Well, actually, it gave ME an idea. I applied the attached to the stock 1.1.1 
version and now have a proper display of "downloading from X of Y connected 
peers". I did not check if it's actually "right" in the theoretical sense, 
hoping that you will; I shouldn't be spending time on my computer right now. I 
also did not check if this is the only such instance of this.

But, yes, it therefore seems there's a portability issue here regarding "long 
int" (32-bit on x86-32, 64-bit on x86-64) versus "long long int" (64 on both).

Original comment by rene.her...@gmail.com on 24 Apr 2014 at 6:48

Attachments:

• torrent-cell-renderer_longlong.diff

[GoogleCodeExporter]

Excellent work! Thanks for this. This isn't the first time a mismatching type 
has caused an issue on 32bit. I remember a segfault in the very early stages of 
the project. Unfortunately they're really difficult to troubleshoot, as 64bit 
effectively prevents the coding error from manifesting itself, but that's C for 
you. :)

When I hacked the cell renderer from transmission, I changed the types to match 
what's returned by json-glib, but obviously missed these printf specifications.

Was about to suggest looking at the console, I was thinking it may show a 
warning about it not being within the permitted range when copying from the 
model to the renderer, thereby staying at the default value.

Patch has been applied. :)

Original comment by a...@eth0.org.uk on 24 Apr 2014 at 7:20

• Changed state: Fixed

[GoogleCodeExporter]

Actually maybe it wouldn't have showed up as a warning, as it copied from the 
model to the renderer fine, it was a problem inside the gettext function. 
There's quite probably not assertions for the gettext functions.

Anyway, glad this is fixed. :)

Original comment by a...@eth0.org.uk on 24 Apr 2014 at 7:42

[GoogleCodeExporter]

Lovely. And yes, eta is indeed also correct now (as per your changelog) even 
though I had forgotten about that again; something about popping the correct 
number of bytes of the stack during the eventual display, I suppose.

Anyways... can you do bug #260 now? :-)

Original comment by rene.her...@gmail.com on 24 Apr 2014 at 7:48