Closed GoogleCodeExporter closed 9 years ago
Hmm, strange... Especially since I haven't had similar reports (with normal
Transmission versions).
Does the same happen if you use 1.0.4 (which is the same as 1.0.5 but with
search)? If that cashes too, can you send me an error report using the error
report feature in Transdroid's menu? That will include the actual crash
information such as stack trace. Thanks.
Original comment by erickok@gmail.com
on 21 Sep 2011 at 1:56
Thanks for a quick reply!
I tried 1.0.4, same problem, error report was just sent.
Original comment by andreas...@gmail.com
on 21 Sep 2011 at 7:10
It seems my previous error log never got sent... tried it again now although
with 1.0.5. But as I remember they both had the same fatal error of some
runtime acc. to the log...
Original comment by andreas...@gmail.com
on 22 Sep 2011 at 2:30
Thanks for that. For my reference, here is the relevant stack trace:
09-22 16:26:21.764 E/AndroidRuntime( 7718): FATAL EXCEPTION: main
09-22 16:26:21.764 E/AndroidRuntime( 7718): java.lang.NullPointerException
09-22 16:26:21.764 E/AndroidRuntime( 7718): at
org.transdroid.gui.LocalTorrent.getProgressSizeText(LocalTorrent.java:77)
09-22 16:26:21.764 E/AndroidRuntime( 7718): at
org.transdroid.gui.TorrentListView.setData(TorrentListView.java:66)
09-22 16:26:21.764 E/AndroidRuntime( 7718): at
org.transdroid.gui.TorrentListView.<init>(TorrentListView.java:48)
09-22 16:26:21.764 E/AndroidRuntime( 7718): at
org.transdroid.gui.TorrentListAdapter.getView(TorrentListAdapter.java:46)
Should be easily solveable. Hopefully reasonably soon - sorry for the
inconvience.
Original comment by erickok@gmail.com
on 22 Sep 2011 at 2:44
I have the same issue running 1.0.4 and connecting to a Mac with the latest
version of transmission. This issue showed up with the last update to
transmission, and only force closes for me when I have completed torrents.
Everything works fine if I'm only downloading. Seeding causes the f/c's.
Original comment by tcaulfld
on 28 Sep 2011 at 10:57
That's for reporting that. Trasmission must have changed (removed?) something
in their API. I'll try to look into it asap.
Original comment by erickok@gmail.com
on 29 Sep 2011 at 9:21
Issue remains on Transmission 2.40b3 with the same stack (Transdroid
1.0.5-Market).
Original comment by aleksey....@gmail.com
on 5 Oct 2011 at 6:44
Transmission indeed changed their API in 2.40 in a non-backwards compatible
way. :( The values of the "status" field has changed. See
https://trac.transmissionbt.com/browser/trunk/extras/rpc-spec.txt
I hope to fix this at the end of next week. Sorry for the delay.
Original comment by erickok@gmail.com
on 6 Oct 2011 at 7:00
I reverted back to Transmission 2.11 and now Transdroid works just fine. No
errors so far and that's both while downloading and seeding.
Original comment by andreas...@gmail.com
on 7 Oct 2011 at 6:11
Issue 352 has been merged into this issue.
Original comment by erickok@gmail.com
on 11 Oct 2011 at 11:42
I'm sorry, I din't see issue #346 reported same issue. I have many torrents
seeding on Transmission 2.41. On my PC's Transmission Remote GUI, seeding
torrents are displayed as 'unknown' - demonstrating that something has
definitely changed on RPC interface.
Thanks again for your great job!
Original comment by tulio.la...@gmail.com
on 11 Oct 2011 at 11:52
In Transmission 2.40 and newer, domain values of 'status' field have changed,
in a non-backward compatible way, maybe due to a new 'torrent queueing'
feature, returned by a 'tr_stat' object. Saw this at
https://trac.transmissionbt.com/browser/trunk/extras/rpc-spec.txt.
Looking at transmission.h bundled in version 2.41 source code, I found this:
typedef enum
{
TR_STATUS_STOPPED = 0, /* Torrent is stopped */
TR_STATUS_CHECK_WAIT = 1, /* Queued to check files /*
TR_STATUS_CHECK = 2, /* Checking files */
TR_STATUS_DOWNLOAD_WAIT = 3, /* Queued to download */
TR_STATUS_DOWNLOAD = 4, /* Downloading */
TR_STATUS_SEED_WAIT = 5, /* Queued to seed */
TR_STATUS_SEED = 6 /* Seeding */
} tr_torrent_activity;
I think Transdroid should be recompiled using this new domain.
Original comment by tulio.la...@gmail.com
on 11 Oct 2011 at 3:36
Issue 355 has been merged into this issue.
Original comment by erickok@gmail.com
on 18 Oct 2011 at 8:04
Issue 354 has been merged into this issue.
Original comment by erickok@gmail.com
on 18 Oct 2011 at 8:05
The original defect description mentions 2.34 beta 4 (which is why I when I
first read it dismissed it as being a different issue than my 355). Comments
here state being 2.40 the API was changed, does anybody know if the same is
already true for the reported 2.34 beta 4?
Original comment by Alexande...@googlemail.com
on 18 Oct 2011 at 8:14
Since 2.34beta, Trasmission changed a status domain returned by 'tr_stat'
object. Most of us use only stable versions, so it will be generally noticeable
since Transmission 2.40 - 2.41.
Other remote GUIs had issues (Transmission Remote GUI, Transmission Remote
Dotnet), and fixes are being developed and released, with backward
compatibility - assuming that major part of Transmission users are still on <
2.40 version.
Eric, any idea when new Transdroid build will be generally available? Thanks.
Original comment by tulio.la...@gmail.com
on 18 Oct 2011 at 11:34
I've made a fix (see r372) and released a new version that includes support for
all Transmission version (1.30+ I think). Get it direcctly at
http://code.google.com/p/transdroid/downloads/detail?name=transdroid-1.1.0-beta.
apk&can=2&q=
A word of warning: it's more unfinished that my beta's are usually. Some hefty
UI changes are also in here (to support tablets) so you WILL probably find some
UI bugs or quirks. Having said that: give it a try to see if you can connect to
your 2.40+ Transmission servers again!
Original comment by erickok@gmail.com
on 21 Oct 2011 at 1:57
It works (Transmission 2.40)
Original comment by aleksey....@gmail.com
on 21 Oct 2011 at 2:31
It works (Transmission 2.41)
Original comment by thomas.b...@gmail.com
on 21 Oct 2011 at 2:40
I can connect to my 2.41 transmission installation again, but when I try to add
a torrent via the app it force closes.
Plausing and resuming via the app works as does removing an torrent.
In the old version, focusing on a single torrent gave you also the a list with
files the torrent consists of and thus you could change which files to get,
their priorities etc. but in the beta version I don't get any files listed
(guessing those are the UI changes/bugs you referred to).
A way to sort by queue order would be nice as well.
Original comment by Alexande...@googlemail.com
on 21 Oct 2011 at 2:55
I'm having trouble adding torrents as well, transdroid is force closing.
However listing files in existing torrents is working well so far on a Samsung
GT-5500 running FroYo.
Original comment by furex.fu...@gmail.com
on 22 Oct 2011 at 2:36
Ok, I've got a Samsung Galaxy S II running 2.3
Original comment by Alexande...@googlemail.com
on 22 Oct 2011 at 9:47
The listing of files within a torrent should still work as expected. It does
for me (although I have seen quirks with one rTorrent server) but I will
definitely look into this. The smae holds for adding of torrent files by
uploading a .torrent. If you experience a crash again, please send an error
report using Transdroid's menu. Thanks for your input.
Original comment by erickok@gmail.com
on 23 Oct 2011 at 1:49
Checked again, now I get the files list, maybe my data connection didn't work
properly at the time I experienced that problem.
Just tried adding a torrent again, did force close again. I started the app
again and then immediately sent an error report, hope that's what you meant.
Original comment by Alexande...@googlemail.com
on 23 Oct 2011 at 2:00
Thanks. I got your mail with the error report. Strangely enough it shows no
errors at at all. It did looked cut off so maybe not the full log was send.
Please try again or start the Log Collector app manually and send the report to
transdroid.org@gmail.com to see if that helps. Thanks for your time!
Original comment by erickok@gmail.com
on 23 Oct 2011 at 2:27
Ok, I reproduced the issue, and then started the log collector directly and
sent the log again to the previous email address (looks different this time
around than the previous tries).
Original comment by Alexande...@googlemail.com
on 23 Oct 2011 at 2:57
As it nether-the-less looked cut off, I installed a different log reporting app
called CatLog), which runs in the background, and reproduced the issue again
and sent the logs from that app as well.
Original comment by Alexande...@googlemail.com
on 23 Oct 2011 at 3:11
[deleted comment]
I've received the report and - since it is a new, unrelated bug - created a new
issue. See issue 357.
Original comment by erickok@gmail.com
on 23 Oct 2011 at 3:20
Issue 360 has been merged into this issue.
Original comment by erickok@gmail.com
on 7 Dec 2011 at 4:58
Issue 366 has been merged into this issue.
Original comment by erickok@gmail.com
on 31 Dec 2011 at 3:06
Issue 367 has been merged into this issue.
Original comment by erickok@gmail.com
on 2 Jan 2012 at 11:30
Issue 372 has been merged into this issue.
Original comment by erickok@gmail.com
on 18 Jan 2012 at 9:11
Original issue reported on code.google.com by
andreas...@gmail.com
on 21 Sep 2011 at 1:46