Re: Firefox 3.6 support and possible compatibility issue
Glenn
I am currently downloading the Firefox 3.6 Beta. I will test out
compatibility as soon as it is installed. Although, I doubt the move
to 3.6 is causing your problems. It might be the 2.3 version of
Autotrans. However, the fact that it is only happening to selected
torrents (and not all of them) leads me to believe it isn't the
plugin's problem. Autotrans treats all torrent links the same, which
is to just send the URL directly to the Transmission RPC. It doesn't
download the data itself, so it shouldn't be corrupting the
information. That being said, I will look into the bug. Can you tell
me a few links (or just the website where they're from) which aren't
working.
On Jan 11, 12:02 pm, Mel Torme <mcmanus.ja...@gmail.com> wrote:
> Hi there Glenn. Thanks very much for the AutoTrans add-on, it's
> really handy, and I look forward to the Magnet support you spoke of in
> another message.
>
> I'm wondering if you were planning to test compatibility with FF 3.6.x
> soon? I have haxed the installer for 2.3, by opening it and changing
> versions in the install.rdf file myself, in order to get it working
> due to a long set of circumstances that forced me to wipe and
> reinstall FF from scratch. I was going to report on its compatibility
> with the FireFox 3.6 compatibility add-on, but when I went to mark
> something, it said that the developer had already marked it
> compatible.
>
> I have in fact noticed a few torrents for which it seems to be
> reporting "invalid or corrupt file", but seems to work when I download
> the exact same link, then upload it to transmission manually from the
> transmission web interface. They tend to come mainly from one
> particular popular but restricted site that's had a bit of downtime
> twice last year, but is now back up if a bit ailing, so I'm not always
> sure if a link is going to work or not; however, since the same file
> works through the Transmission (1.76) web interface, it seems possible
> it might be the add-on. The same site seemed to work decently when I
> was on FF 3.5.5/Autotrans 2.2, but since I changed both of those at
> the same time, I unfortunately can't isolate a possible issue.
>
> Regardless if this is a bug with the torrent site or Autotrans, do you
> have a timeline for 3.6 compatibility in the works?
>
> Thanks again!
Glenn
how it would work. So for this particular site, you have to input
login credentials every time you click on a torrent link? Or just
once to login to the site? If you are logged into the site, I don't
see why the link would be corrupted when you try to download it with
Autotrans. Or is it that once you are logged in, Autotrans works for
these links?
If it is the case that you must enter login info for each link, then
this isn't very feasible for Autotrans, because it would have to
maintain a table of all your login credentials for various sites that
you might use, and then send those credentials if you are attempting
to use a torrent link from that site. I may add the ability to
download a torrent file to your machine, be able to inspect it
(perhaps in a popup window), and then send the contents of that file
to Transmission. But again, I'm not so sure this would solve the
login problem you describe.
On Jan 12, 5:27 am, Mel Torme <mcmanus.ja...@gmail.com> wrote:
> Hi, thanks for looking into this. While 3.6.x is still beta, it has
> so far seemed to solve that ongoing periodic lag problem that has been
> plaguing 3.5.x for at least the last year, so I genuinely appreciate
> your consideration. In case you haven't seen them, I've picked out a
> couple of relevant links about 3.6 add-ons:
>
> https://developer.mozilla.org/En/Firefox_3.6_for_developershttps://developer.mozilla.org/en/Updating_extensions_for_Firefox_3.6http://blog.mozilla.com/addons/2009/10/22/announcing-the-add-on-compa...
>
> With the new knowledge of AutoTrans only sending the URL across, and
> in searching for other examples of what works and does not work (most
> of what I found did report "Successfully Added"), I think I have found
> what the issue is: for sites on which you must first login, sending
> the URL across for the transmission daemon to download will of course
> not succeed. I migrated around the same time from a program called
> PCHUploader, which did a similar thing, but actually did download
> torrents to the local machine and manually send them up as a multipart/
> form-data submission. Obviously for sites which require a login, just
> sending the URL across won't be successful. :\
>
> I would swear high and low that I used AutoTrans multiple times with
> the site in question, but if that hasn't changed between 2.2 and 2.3,
> clearly I was mistaken. All things considered, so far it appears then
> that the current iteration is compatible with 3.6.
>
> Would downloading to the local machine before sending back up be a
> feature enhancement you would consider for a future version?
>
> Thanks again.
Glenn
into the next version of Autotrans when I get a free moment.
Thanks for the explanation.
On Jan 12, 10:01 am, Mel Torme <mcmanus.ja...@gmail.com> wrote:
> No, what I think is happening is that, you log in to the site just
> once, and go to download the link, right-click and choose "Torrent
> It", and it currently sends that URL over to the Transmission RPC
> server (which in my case resides on another box, but that's
> irrelevant), and transmission attempts to download it, failing because
> its webclient/useragent is not logged in. In other words, the user-
> agent (Firefox) from which I send the URL /is/ logged in, but
> transmission, which receives the same URL, is not.
>
> With login sites, the torrent client is never (afaik) required to know
> credentials for the tracker once the torrent file itself has been
> downloaded; it works either by embedding an md5 passcode as part of
> the tracker URL in the torrent file itself, or alternatively by
> logging the IP of the user's last login to the website and cross-
> referencing that with the IP of the torrent client when it connects to
> the tracker.
>
> If, as PCHUploader does, it were to download the torrent into memory
> on the local machine, then upload it back across to the Transmission
> server, it would already have the torrent contents itself out from
> behind the login wall, and thus the transmission daemon would only be
> required to start it and connect to the tracker like normal.
>
> Does that make sense, or was I clear as mud? :-)
>
> On Jan 12, 4:50 pm, Glenn <glenn...@gmail.com> wrote:
>
> > This may be something for a future version, but I'm not entirely sure
> > how it would work. So for this particular site, you have to input
> > login credentials every time you click on a torrent link? Or just
> > once to login to the site? If you are logged into the site, I don't
> > see why the link would be corrupted when you try to download it with
> > Autotrans. Or is it that once you are logged in, Autotrans works for
> > these links?
> > If it is the case that you must enter login info for each link, then
> > this isn't very feasible for Autotrans, because it would have to
> > maintain a table of all your login credentials for various sites that
> > you might use, and then send those credentials if you are attempting
> > to use a torrent link from that site. I may add the ability to
> > download a torrent file to your machine, be able to inspect it
> > (perhaps in a popup window), and then send the contents of that file
> > to Transmission. But again, I'm not so sure this would solve the
> > login problem you describe.
>
> > On Jan 12, 5:27 am, Mel Torme <mcmanus.ja...@gmail.com> wrote:
>
> > > Hi, thanks for looking into this. While 3.6.x is still beta, it has
> > > so far seemed to solve that ongoing periodic lag problem that has been
> > > plaguing 3.5.x for at least the last year, so I genuinely appreciate
> > > your consideration. In case you haven't seen them, I've picked out a
> > > couple of relevant links about 3.6 add-ons:
>
> > >https://developer.mozilla.org/En/Firefox_3.6_for_developershttps://de......
Oliver
I just want to mention that I have the same problem. And I finally
know why :)
I log in to my torrent site from my MacBook, select a torrent and
select "Torrent It" to send it to my MacMini (which works as my Media
Center, but is not logged in to the torrent site). Torrent does not
appear in the MacMinis Transmission program.
If I download the torrent file to my MacBook first and upload it via
the web interface to the MacMini it works like a charm. I guess I'll
have to stick to this method for now.
So I just want to say a solution for this is much appreciated :)
Thanks for your time and effort in this.
Regards
On 12 Jan., 16:17, Mel Torme <mcmanus.ja...@gmail.com> wrote:
> Spectacular, thank you very much! I think that will really increase
> compatibility.
>
> And as this is different from what started this thread, I appreciate
> your time and work in testing compatibility with 3.6.x, as well.
>
> Cheers.
Glenn
I have in fact worked on this problem a bit, but unfortunately I'm a
bit stumped at the moment.
Maybe you could help me. I made a preference in the plugin which
allows you to send the contents of the torrent file (the meta-info) to
the transmission daemon, instead of sending only the torrent URL. My
problem is that I can't seem to find the correct base64-encoding
scheme that I need in order to send the meta-info to the daemon.
I know that it has to be base 64 encoded, but every method I've tried
to do this encoding has failed so far.
I have inspected what the transmission-remote application ultimately
sends to the daemon, so I can see what properly encoded data looks
like, but unfortunately, that isn't quite enough for me to calculate
where the error is in my own encoding math.
If you're interested in taking a look at the various code methods that
I've used, they are all right there in the plugin's overlay.js file.
You can see some variables which set different methods to use.
What the plugin ultimately needs is a javascript function that can
accurately base64-encode the meta-info. Then this bug will be fixed.
Let me know if you can offer any assistance. I can also send you some
documentation that I've written up whilst attempting to solve this
little riddle.
I look forward to hearing any input.
Glenn
The assistance is much appreciated. I came to similar conclusions as
yours in the course of my research. And similarly, I haven't found a
valid solution yet.
I will look a little deeper when I get a chance. But until then, if
you find any more leads (especially relating to which parts should be
UTF-8 encoded before being 64-bite encoded) please let me know!
Thanks again.
On Feb 18, 1:37 am, Mel Torme <mcmanus.ja...@gmail.com> wrote:
> Hi Glenn,
>
> Thanks, I saw that the new plugin had the option in there, and noticed
> the encoding error. Sorry it took me a couple of days to reply.
>
> I dug into the code and the torrent specification, and noticed your
> other posting on the transmission forums, ran the same transmission-
> remote --debug the guy suggested, and I think I have narrowed down the
> problem, but not a solution (as I'm not spectacular with javascript).
>
> In reading the spec (http://wiki.theory.org/
> BitTorrentSpecification#Metainfo_File_Structure) closely, it appears
> to me that *only* the character strings themselves are UTF-8 encoded,
> and not the field names (although, they are ASCII, which for the first
> 0x7f characters is an overlay onto UTF-8). After that, the "pieces"
> segment can be any encoding, although in the cases of the torrents
> I've tried, they are also UTF-8 encoded, (which, how that works with
> binary SHA-1 digests, I don't know. I don't have UTF-8 on my
> terminal, and it appears binary to me).
>
> The output from the autotrans plugin looks the same for the first 670
> base64 characters, then starts differing from what transmission-remote
> sends; there are lots of '+977' strings in there, and utf-8 uses a lot
> of repetitive characters (e9 nn nn), so it looks like that is where
> the fault lies.
>
> In any case, I think there are 2 issues:
> 1. I don't think the torrent metainfo file actually needs to be utf8-
> decoded first, as I used a simple, dumb unix command-line tool called
> 'mimencode' to simply run on the torrent metainfo file, and it's
> totally encoding-agnostic, and its output looks identical to that in
> the transmission-remote --debug output. The binary piece data in the
> 'pieces' segment may be being corrupted
> 2. The transmission-remote --debug command appears to have embedded
> newlines in it, wrapped at 64 characters, represented by a "\n" (I
> didn't look at its source code, but I assume that's for printability,
> or maybe both ends know about it). I don't know if this really
> matters, as I think other tools I've seen wrap at different lengths or
> not at all, but it might be worth considering.
>
> More info: I tried your encoding athttp://www.stringify.com/2007/jun/18/base64/,
> a javascript site which also uses window.btoa() and window.atob(), and
> it decodes your code fine, but not the transmission-remote-encoded
> version.
>
> I don't have a definitive answer for you I'm sorry to say, but I'll
> keep trying a few different things to see if I can come up with more.
> I just wanted to pass on what I had so far since this is a couple of
> days late, and I do appreciate the work you put into the plugin.