Page 2 of 4
Re: First release of curses interface
Posted: Wed Nov 05, 2008 5:18 pm
by fagga
Two things:
1: I successfully set up a repository at github.com. And it feels better than I expected it to.
2: I know why everyone is calling me lucky charms: My name seems to be offensive to the forum software, so it's getting censored. Sadly, I realized this after setting up my github account, which has the same login name. And, sadly again, the link to my project contains my login name. Which prevents me from properly linking to my project. Another case where censorship is nothing but annoying. (If it where only funny like here:
http://glumbert.com/media/censor)
Well, I'm going to just ignore this.
Here you go:
http://github.com/fagga/transmission-re ... ree/master
Re: First release of curses interface
Posted: Wed Nov 05, 2008 10:00 pm
by pea
http://tinyurl.com/6r2krh does the trick irrespective from this forums software..
Re: First release of curses interface
Posted: Wed Nov 05, 2008 10:14 pm
by fagga
Whoops! I didn't see that the thread got wrapped into two pages, so I missed your last posts.
theCrank wrote:I've got some unused webspace lying around. You can upload your interface if you like to.
Thank you, very nice. But I'm ok now with github.
I once had a look at Subversion on Savannah and I didn't like it at all. But github.com seems to be cool. Only a bug tracker is missing, but they say they're working on it.
Jordan wrote:I think that's a good idea. It's to early to put this in the Transmission tarball, but it's looking good, and the bugfixes are coming fast & furious, so I'd like to be able to link to it from the Transmission homepage...

That would be awesome. I'm a developer!

Re: First release of curses interface
Posted: Sat Nov 08, 2008 12:35 am
by fagga
Additionally to the Git repository, transmission-remote-cli now has a
bug tracker.
Re: First release of curses interface
Posted: Mon Nov 10, 2008 8:01 am
by aleph
Hi. I tried this on my mybokworld busybox system. Having a little trouble getting it to work. I'm getting the following:
Code: Select all
[root@MyBookWorld ~]# ./transmission-remote-cli
Traceback (most recent call last):
File "./transmission-remote-cli", line 972, in <module>
ui = Interface(Transmission(HOST, PORT, USERNAME, PASSWORD))
File "./transmission-remote-cli", line 301, in __init__
curses.wrapper(self.run)
File "/opt/lib/python2.5/curses/wrapper.py", line 44, in wrapper
return func(stdscr, *args, **kwds)
File "./transmission-remote-cli", line 377, in run
self.init_screen()
File "./transmission-remote-cli", line 306, in init_screen
curses.curs_set(0) # hide cursor
_curses.error: curs_set() returned ERR
Not really sure what it means.
Re: First release of curses interface
Posted: Mon Nov 10, 2008 12:04 pm
by fagga
You terminal must be unable to hide the cursor. Shouldn't be a problem now.
BTW: Could've been the first bug on the bug tracker!

Re: First release of curses interface
Posted: Tue Nov 11, 2008 11:01 am
by aleph
OK, great. Seems to be working now. I'll give it more of a test and report back any bugs.
Re: First release of curses interface
Posted: Thu Nov 13, 2008 12:22 pm
by fagga
I have a question to the staff:
I'm trying to show the amount of available data for each torrent when there are no seeds. I'm doing this by adding desiredAvailable and haveValid. The value seems plausible to me, but is this the right way?
And what does desiredAvailable show anyway?
Re: First release of curses interface
Posted: Thu Nov 13, 2008 1:52 pm
by Jordan
Hi fagga,
The RPC spec's table that lists these fields refers you to tr_stat, which is defined in libtransmission/transmission.h. That's where you can find more information about them:
Code: Select all
/** Byte count of how much data is left to be downloaded until
we're done -- that is, until we've got all the pieces we wanted.
[0...tr_info.sizeWhenDone] */
uint64_t leftUntilDone;
/** Byte count of all the piece data we want and don't have yet,
but that a connected peer does have. [0...leftUntilDone] */
uint64_t desiredAvailable;
/** Byte count of all the checksum-verified data we have for this torrent. */
uint64_t haveValid;
Re: First release of curses interface
Posted: Thu Nov 13, 2008 2:56 pm
by fagga
Thanks for your fast reply. libtransmission.h answers this question and some I'm gonna have in the future.
Re: First release of curses interface
Posted: Wed Nov 19, 2008 2:31 pm
by slomojoe
Fagga:
I just had to pop in and say "thanks". This is exactly what I need to run transmission off my headless home server.
You may want to put version numbers or dates in your code. That way we can make sure we're talking about the same version when a bug crops up. Also, I can check to see that I have the latest (right now I'm downloading and running diff). I see my other complaint, the size of the download is wrong, has been marked fixed in the bug tracker. Thanks again!
Re: First release of curses interface
Posted: Wed Nov 19, 2008 8:13 pm
by Jordan
The latest version is running very well for me. In fact it's quickly becoming my remote viewing client of choice.
I have one question/request though... is there a way to have it filter out all the stopped/idle torrents and show only the interesting ones? Right now I use a clumsy hack if I have more than a page's worth of torrents -- I put bash in a loop to call transmission-remote every five seconds and grep out the
"Idle" and "Stopped" torrents...
Re: First release of curses interface
Posted: Sat Nov 22, 2008 6:44 pm
by fagga
Sorry for not answering, for some reason I didn't get a notification email. (?)
slomojoe wrote:I just had to pop in and say "thanks". This is exactly what I need to run transmission off my headless home server.
Jordan wrote:The latest version is running very well for me. In fact it's quickly becoming my remote viewing client of choice.

You're very welcome and I, in return, have to thank you guys for your kind words. This is the first time I'm actually programming for someone else than me, so I'm pretty excited about your approval.
slomojoe wrote:You may want to put version numbers or dates in your code. That way we can make sure we're talking about the same version when a bug crops up.
Yes, you're right. But as the script is under heavy development, I could do a major version jump every two days or so. But I think I'm doing this anyhow now, although I just found out about this guy who has already done Python bindings for Transmission, which I could use and what would made me probably force to do some major re-writes. *sigh*
Jordan wrote:I have one question/request though... is there a way to have it filter out all the stopped/idle torrents and show only the interesting ones? Right now I use a clumsy hack if I have more than a page's worth of torrents -- I put bash in a loop to call transmission-remote every five seconds and grep out the
"Idle" and "Stopped" torrents...
Well, you could sort by state. That would pack all your downloading torrents together.
Of course, I could implement a filter but just filtering states would be lame. And I think other things do have higher priority right now.
I also do have a question:
Yesterday I tried the new version 1.4 on my Debian system using the Ubuntu Hardy packages. It worked well, but one downloading torrent always stopped after a seemingly random delay, filling 'errorString' with "Resource temporarily unavailable".
I don't want to file this as a bug because I was using the wrong packages, but I think this error message isn't very helpful. I read in the forum about hard disk or file system failures that could cause this behaviour, but version 1.34 (which I'm running now) works just fine. Neither /var/log/syslog nor `transmission-daemon -f` revealed anything about the cause of this. Couldn't 'errorString' be more specific about
what resource is unavailable?
Re: First release of curses interface
Posted: Sun Nov 23, 2008 5:01 pm
by Jordan
fagga wrote:
Jordan wrote:I have one question/request though... is there a way to have it filter out all the stopped/idle torrents and show only the interesting ones? Right now I use a clumsy hack if I have more than a page's worth of torrents -- I put bash in a loop to call transmission-remote every five seconds and grep out the
"Idle" and "Stopped" torrents...
Well, you could sort by state. That would pack all your downloading torrents together.
Of course, I could implement a filter but just filtering states would be lame. And I think other things do have higher priority right now.
I also do have a question:
Yesterday I tried the new version 1.4 on my Debian system using the Ubuntu Hardy packages. It worked well, but one downloading torrent always stopped after a seemingly random delay, filling 'errorString' with "Resource temporarily unavailable".
I don't want to file this as a bug because I was using the wrong packages, but I think this error message isn't very helpful. I read in the forum about hard disk or file system failures that could cause this behaviour, but version 1.34 (which I'm running now) works just fine. Neither /var/log/syslog nor `transmission-daemon -f` revealed anything about the cause of this. Couldn't 'errorString' be more specific about
what resource is unavailable?
I would answer that, but I'm currently too busy wishing that the curses interface had activity filtering...
IIRC, the "Resource temporarily unavailable" message comes directly from the tracker, so who knows what they're referring to. I'm not 100% positive about that but I think it's correct.
Re: First release of curses interface
Posted: Sun Nov 23, 2008 6:21 pm
by fagga
Jordan wrote:I would answer that, but I'm currently too busy wishing that the curses interface had activity filtering...

As I'm totally open for being blackmailed, I just implemented your filter list.

No, I actually had second thoughts about it and found that it's a quite trivial thing to do. At first I had visions about highly flexible regular expressions or something.
Jordan wrote:IIRC, the "Resource temporarily unavailable" message comes directly from the tracker, so who knows what they're referring to. I'm not 100% positive about that but I think it's correct.
That would explain the message, but not why the torrent gets paused. In my opinion, torrents shouldn't get paused automatically unless there's some kind of writing error.