Invalid argument error when adding specific magnet link.

transmission-remote-gui / transgui

🧲 A feature rich cross platform Transmission BitTorrent client. Faster and has more functionality than the built-in web GUI.

GNU General Public License v2.0

3.22k stars 280 forks source link

Invalid argument error when adding specific magnet link. #996

Open mrplumber opened 7 years ago

mrplumber commented 7 years ago

Hello,

Transmission Remote GUI refuses to add specific magnet link (see below) with an error message "Invalid argument". The same link works fine when passed with transmission-remote program on another Linux machine.

Magnet link (this is an URL to pastebin with actual link): https://p.dousse.eu/?53a8547c4d488577#9bGiF++WmyOmWmREhM+bUPhT5QCDeKjJvVL/m8vCvKE= Transmission Remote GUI version 5.8.3 on Windows 10 Transmission daemon version 2.92 on Debian stable.

cfpp2p commented 7 years ago

This I can not reproduce. With the above link and final magnet provided everything works.

leonsoft-kras commented 7 years ago

Similarly

uniss2209 commented 7 years ago

I reproduced. The "Invalid argument" window. Transmission Remote GUI 5.8.3 on win7x64. uTorrent 2.2.1 started downloading without problems.

pelepelin commented 6 years ago

I have some where "Illegal argument" is caused by dn in magnet URI, probably, having invalid characters for the target filesystem, for example, dn=%D0%A2%D1%80%D0%B0%D0%BD%D1%81%D1%84%D0%BE%D1%80%D0%BC%D0%B5%D1%80%D1%8B%3A throws an error, but dn=%D0%A2%D1%80%D0%B0%D0%BD%D1%81%D1%84%D0%BE%D1%80%D0%BC%D0%B5%D1%80%D1%8B does not. I use ntfs-3g on the transmission host if that matters.

angar4ik commented 6 years ago

Reproducible.

Client: v5.13 Linux x64 Server: DD-WRT Link: dn=%D0%9A%D0%BE%D0%BD%D1%8C%20%D0%91%D0%BE%D0%94%D0%B6%D0%B5%D0%BA%20%2F%20BoJack%20Horseman%20%2F%20%D0%A1%D0%B5%D0%B7%D0%BE%D0%BD%3A%203%20%2F%20%D0%A1%D0%B5%D1%80%D0%B8%D0%B8%3A%201-12%20%D0%B8%D0%B7%2012%20(%D0%A0%D0%B0%D1%84%D0%B0%D1%8D%D0%BB%D1%8C%20%D0%91%D0%BE%D0%B1-%D0%A3%D0%BE%D0%BA%D1%81%D0%B1%D0%B5%D1%80%D0%B3%20%2F%20Raphael%20Bob-Waksberg)%20%5B2016%2C%20%D0%B4%D1%80%D0%B0%D0%BC%D0%B0%2C%20%D0%BA%D0%BE%D0%BC%D0%B5%D0%B4%D0%B8%D1%8F%2C%20%D1%81%D0%B0%D1%82%D0%B8%D1%80%D0%B0%2C%20WEB-DL%201080p

UPDATE:

It works fine after I removed almost everything in "dn=" argument, as @checat mentioned.

ghost commented 5 years ago

I can reproduce a version of this too, OP pastebin link is no longer valid though so I don't know if it's exactly the same issue. Client: transgui 5.15.4 on Win10 x64 Server: FreeNAS 11.1-U6, transmission-2.93-amd64

When I encounter this problem it's always with dn= filenames containing Cyrillic characters, which I note the other magnet links posted in this thread also do. (Maybe this is just a coincidence due to the prominence of rutracker.) I believe at least some manifestations are not due to filesystem naming limitations, since I can create .txt files with the offending filenames just fine on both the client and server.

Minimal repro of a case I just encountered, using Debian 9.5.0 LiveCD ISO : Fails: magnet:?xt=urn:btih:L7ZHEZ4DV7HK453D5NRHACPZGJOXF7SU&dn=%20%E2%80%94%20 Works: magnet:?xt=urn:btih:L7ZHEZ4DV7HK453D5NRHACPZGJOXF7SU&dn=%E2%80%94

The working name %E2%80%94 decodes to a wide dash "—", the failing name %20%E2%80%94%20 is " — ".

skobkin commented 5 years ago

This is probably related to #1044.

pelepelin commented 5 years ago

yep, looks a duplicate for me

ghost commented 5 years ago

This bug may be fixed now? The failing reproduction case in my previous comment works as of version 5.17.0.