First release of curses interface

[fagga]

Hello again.

I have yet another question: How am I supposed to handle webseeds? I created a test torrent, but the webseed list from the daemon is always empty. Here is a sample request:

Code: Select all

{
    'tag': 77,
    'method': 'torrent-get',
    'arguments': {
        'fields': [..., 'webseeds', ...],
        'ids': 23
        }
}

The test torrent:

Code: Select all

btshowmetainfo 20030621 - decode BitTorrent metainfo files

metainfo file.: blabla.test.torrent
info hash.....: 29a64572c168e498e7be4ff32a3a1be6e03cdf7c
file name.....: blabla.test
file size.....: 8 (0 * 32768 + 8)
announce url..: http://localhost:12345/announce
http seeds....: http://localhost:1234/blabla.test

transmission-remote -b doesn't get any webseeds either, so I'm not doing anything wrong, right?
Are webseeds only listed when Transmission actually downloads from them?
While searching the trunk, I found something that looks like a typo to me in transmission.h, line 1089:

Code: Select all

float* tr_torrentWebSpeeds( const tr_torrent * torrent );

Shouldn't it be "Seeds", not "Speeds"? Could that be the problem?
Is anyone using webseeds anyhow?

[Jordan]

webseeds are currently a very low priority because there's been very very low user interest in them.

I'm not eager to spend a lot of time tweaking and debugging features that will rarely be used, so I haven't looked at the webseed code in awhile. Often, features like that only get added when a user's "itch" gets strong enough that they submit a patch for it.

tr_torrentWebSpeeds() is the correct name, since it returns the download speeds of our different webseed connections

[fagga]

Ok, thank you. I'm gonna remove the (few) lines regarding webseeds until this is working.

[crispus]

Hello. I'm getting some kind of error here when I run transmission-remote-cli.py. The output is super long so I'll post a link to it here.

http://omploader.org/veXpz/error

Thanks in advance!

[fagga]

That's a strange error. And you have over 237 torrents! For some reason, the response from the daemon breaks in the middle and a new response is started.
Anyway, I don't have any idea what could cause this. At the moment, I think the bug must be either in transmission-daemon or in some Python module. Maybe Jordan could have a look at this, but I'm gonna think about it too.
And thanks for your report.

[crispus]

380 to be exact. Thanks for your response though! I'll be checkin back to see how it goes!

[fagga]

I still don't know how you got this error message. I just created 300 torrents and added them all, but everything was fine. Except a really high cpu load, but transmission-remote-cli was still usable.
I'm sorry, but if I cannot reproduce your error, I cannot fix it.

[mihairu]

Hi, could you please add what version of libraries I need on this script? I have this error:

Code: Select all

Traceback (most recent call last):
  File "Programs/transmission-remote-cli/transmission-remote-cli.py", line 1821, in <module>
    ui = Interface(Transmission(HOST, PORT, USERNAME, PASSWORD))
  File "Programs/transmission-remote-cli/transmission-remote-cli.py", line 180, in __init__
    self.wait_for_torrentlist_update()
  File "Programs/transmission-remote-cli/transmission-remote-cli.py", line 373, in wait_for_torrentlist_update
    self.wait_for_update(7)
  File "Programs/transmission-remote-cli/transmission-remote-cli.py", line 382, in wait_for_update
    if self.update(0, update_id): break
  File "Programs/transmission-remote-cli/transmission-remote-cli.py", line 199, in update
    tag = self.parse_response(response)
  File "Programs/transmission-remote-cli/transmission-remote-cli.py", line 235, in parse_response
    self.status_cache.update(response['arguments']['session-stats'])
KeyError: 'session-stats'

[fagga]

Sorry for the delay, the e-mail notification doesn't work or I'm too stupid to use it.

You error message doesn't have to do anything with libraries, it is caused by a protocol change from transmission 1.40 to 1.50.
Concidentally, I just fixed this bug, so it should work now.

[quietas]

I've got this bug currently:

Code: Select all

Traceback (most recent call last):
  File "./transmission-remote-cli.py", line 1908, in <module>
    ui = Interface(Transmission(HOST, PORT, USERNAME, PASSWORD))
  File "./transmission-remote-cli.py", line 458, in __init__
    self.run()
  File "./transmission-remote-cli.py", line 554, in run
    self.draw_torrent_list()
  File "./transmission-remote-cli.py", line 934, in draw_torrent_list
    self.draw_torrentlist_item(self.torrents[i], (i == self.focus), ypos)
  File "./transmission-remote-cli.py", line 949, in draw_torrentlist_item
    self.draw_uploadrate(torrent, y)
  File "./transmission-remote-cli.py", line 968, in draw_uploadrate
    self.pad.addch(curses.ACS_UARROW, (0,curses.A_BOLD)[torrent['uploadLimitMode                                             ']])
KeyError: 'uploadLimitMode'

Last week it was working great, I could check my torrents without via SSH and all was good. No after updates it borked.

It's on Ubuntu 9.04 server, transmission 1.51-0ubuntu3 from the repos.

[fagga]

According to the rpc specs "uploadLimitMode" is removed from the protocol in version 1.60. Maybe the Ubuntu 1.51-package features patches from this version, at least I don't have a better explanation.

The main problem are the ongoing changes in the rpc protocol which transmission-remote-cli wasn't designed for, so patches for those changes are quite dirty and mess up the code. I could put in another of those dirty workarounds, but it's likely that there are more protocol changes who raise more errors. And if not, the next Transmission version is going to.
To make protocol changes easier to implement, a major part of transmission-remote-cli should be redesigned, and I'm not quite sure if this would really help.

I'm sorry, but there is no easy way other than to downgrade to a previous daemon version.

[Jordan]

The main problem are the ongoing changes in the rpc protocol which transmission-remote-cli wasn't designed for, so patches for those changes are quite dirty and mess up the code. I could put in another of those dirty workarounds, but it's likely that there are more protocol changes who raise more errors. And if not, the next Transmission version is going to.
To make protocol changes easier to implement, a major part of transmission-remote-cli should be redesigned, and I'm not quite sure if this would really help.

I'm sorry, but there is no easy way other than to downgrade to a previous daemon version.

I think you're overreacting. There's only been one set of incompatible changes to the RPC spec, and that's from 1.52 to 1.60. As you're probably aware, the reason "uploadLimitMode" was changed was to keep in sync with 1.60's new features.

[fagga]

I think you're overreacting. There's only been one set of incompatible changes to the RPC spec, and that's from 1.52 to 1.60. As you're probably aware, the reason "uploadLimitMode" was changed was to keep in sync with 1.60's new features.

Yes, maybe I am overreacting a little. Currently there are two version checks: <1.4 doesn't have peer lists and the return value of 'session-stats' changed with ~1.4. Another check wouldn't really turn the code into complete chaos. But I imagine how the code would look like in one or two years with 20 or 30 version checks. I don't want to maintain such a thing.
On the other hand, protocol changes cannot be avoided completely, I know.

I'll see if I can look into it tomorrow.

[livings124]

Should features not be added?

[Jordan]

Another check wouldn't really turn the code into complete chaos. But I imagine how the code would look like in one or two years with 20 or 30 version checks. I don't want to maintain such a thing.

Don't worry about supporting older versions, then. Users will accept being told "you need to upgrade" a lot easier than they will being told "you need to downgrade"...