Page 3 of 4
Re: First release of curses interface
Posted: Fri Nov 28, 2008 12:43 pm
by 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?
Re: First release of curses interface
Posted: Fri Nov 28, 2008 4:21 pm
by 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
Re: First release of curses interface
Posted: Fri Nov 28, 2008 4:51 pm
by fagga
Ok, thank you. I'm gonna remove the (few) lines regarding webseeds until this is working.
Re: First release of curses interface
Posted: Sat Nov 29, 2008 12:47 am
by 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!
Re: First release of curses interface
Posted: Sat Nov 29, 2008 1:07 am
by 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.
Re: First release of curses interface
Posted: Sat Nov 29, 2008 2:00 am
by crispus
380 to be exact. Thanks for your response though! I'll be checkin back to see how it goes!
Re: First release of curses interface
Posted: Wed Dec 03, 2008 2:11 pm
by 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.
Re: First release of curses interface
Posted: Tue Mar 03, 2009 12:24 am
by 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'
Re: First release of curses interface
Posted: Thu Mar 05, 2009 12:38 pm
by 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.
Re: First release of curses interface
Posted: Fri Apr 24, 2009 11:46 pm
by 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.
Re: First release of curses interface
Posted: Sat Apr 25, 2009 12:31 am
by 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.
Re: First release of curses interface
Posted: Sat Apr 25, 2009 9:48 pm
by Jordan
fagga wrote: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.
Re: First release of curses interface
Posted: Sat Apr 25, 2009 11:26 pm
by 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.
Re: First release of curses interface
Posted: Sun Apr 26, 2009 5:21 am
by livings124
Should features not be added?
Re: First release of curses interface
Posted: Sun Apr 26, 2009 7:10 am
by Jordan
fagga wrote: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"...