Created attachment 318378 [details]
Starting in version 0.16, rasterbar libtorrent makes use of #if defined UNICODE for checking for the need of std::wstring vs std::string (line 362 in http://libtorrent.svn.sourceforge.net/viewvc/libtorrent/tags/libtorrent_0_16_2/include/libtorrent/config.hpp?revision=7204&view=markup). This shows itself in my case when using the python bindings (http://libtorrent.svn.sourceforge.net/viewvc/libtorrent/tags/libtorrent_0_16_2/bindings/python/src/torrent_handle.cpp?revision=7204&view=markup) and move_storage gets called by for example deluge. I have unicode as a global use flag. I don't know if it's an issue with my system, but UNICODE is not defined, so when move_storage gets called from python libtorrent throws an error, expecting type std::string while getting type unicode. What I did to fix this was to add unicode to IUSE for the ebuild. I then use cppflags_append to add -DUNICODE if use unicode. I don't know if this is the proper approach but it works.
I'm attaching my emerge --info. I will make another post with a patch for the ebuild I am currently using following this.
Created attachment 318380 [details]
Add more info about your usecase - UNICODE in this package is meant only for Windows. On Linux, it simply uses utf8.
Use case is simple. Install one of the rb_libtorrent 0.16.x releases. Install deluge (1.3.5 and 9999 were tested). After a download completes, right click the listing and select "Move Storage." Nothing happens. (Automatic move upon finishing does the same thing if set.)
If debug logging is enabled for deluged, a simple Error is displayed. I chatted with andar on the #libtorrent channel at irc.freenode.net and he walked me through programming deluge to log more information on the exception. I did so and the traceback showed that libtorrent was expecting std::string to be passed to move_storage, but was getting unicode instead.
I tracked down what could have changed in move_storage to cause this, and it was the lack of UNICODE causing TORRENT_USE_WSTRING to be false thus only allowing std::string usage with move_storage. Passing -DUNICODE to the cppflags allows TORRENT_USE_WSTRING to be true and libtorrent allows for unicode to be passed to move_storage.
Like I said, I wasn't sure this was the proper method for resolving the issue, but it is now working for me. If this package was only intending UNICODE for windows, then there's a bug upstream somewhere, but someone with more knowlege should report that.
Actually, just took another look at deluge. They intentionally cast the destination path as unicode for move_storage.
# Attempt to convert utf8 path to unicode
# Note: Inconsistent encoding for 'dest', needs future investigation
dest_u = unicode(dest, "utf-8")
# String is already unicode
dest_u = dest
So it would appear this is in fact a deluge bug. Not sure exactly what deluge needs to do instead and maintain cross platform consistency.
http://git.deluge-torrent.org/deluge/commit/deluge/core/torrent.py?id=417a9f6e63e75e5c8b5c2cd9e922aea1723c50de is where that code got added. Apparently a windows issue. Until deluge upstream is working, should just unapply this patch. Will be attaching patch files for 1.3.5 and 9999 respectively.
Created attachment 318396 [details, diff]
deluge 1.3.5 patch
Created attachment 318398 [details, diff]
deluge 9999 patch
Created attachment 318400 [details, diff]
deluge 1.3.5 ebuild patch
Created attachment 318402 [details, diff]
deluge 9999 ebuild patch
Turns out my inital attempt only resolves the issue for manually moving data in deluge. When set to automatically move when a download finishes, the issue crops up again. Need to investigate further.
I have a bug related with rb_libtorrent-0.16 on deluge-1.3.5 too
Deluge just do not work. Very slowly download and almost do not upload.
*** Bug 431782 has been marked as a duplicate of this bug. ***
I suspect part of the answer is here (http://code.google.com/p/libtorrent/issues/detail?id=173):
> unfortunately, in 0.15 and earlier, the torrent creation is an exception from
> the rest of the API in that it doesn't re-encode strings for filenames.
> You may want to try to use the wide string version of add files,
> especially on windows.
However, the problem deluge has is that it needs to handle Windows and Unix-like differently. Actually, it's (arguably) a little design flaw of libtorrent...
Well, not quite. It's more that libtorrent_rasterbar was written in a way that it could be built/work on Windows versions that don't support Unicode. That was a feature back when Win9x was common, now is a misfeature.
On the other hand, even these days there are Windows programs released not built with wide API :roll:.
Upstream bug report: http://dev.deluge-torrent.org/ticket/2140
Created attachment 329054 [details, diff]
deluge 1.3.5 patch
Fixes "move completed to" when download finishes.
Deluge git patch for that bug is here:
It looks a bit more extensive than the patch attached to this bug.
This was fixed years ago. Please close.