First release of curses interface

[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

[pea]

Here you go: http://github.com/lucky%20charms/transm ... ree/master

http://tinyurl.com/6r2krh does the trick irrespective from this forums software..

[fagga]

Whoops! I didn't see that the thread got wrapped into two pages, so I missed your last posts.

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.

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!

[fagga]

Additionally to the Git repository, transmission-remote-cli now has a bug tracker.

[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.

[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!

[aleph]

OK, great. Seems to be working now. I'll give it more of a test and report back any bugs.

[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?

[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;

[fagga]

Thanks for your fast reply. libtransmission.h answers this question and some I'm gonna have in the future.

[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!

[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...

[fagga]

Sorry for not answering, for some reason I didn't get a notification email. (?)

I just had to pop in and say "thanks". This is exactly what I need to run transmission off my headless home server.

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.

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*

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?

[Jordan]

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.

[fagga]

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.

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.