I recently downloaded a single file torrent with a name like "Blah Blah Blah's.avi". When ktorrent attempted to save the file, it gave an error. I guessed that the single quote / apostrophe was the problem, so created a directory whose name was just a single apostrophe, and then tried to open the torrent again and this time saved the file in that directory, and it worked.

Seems like filenames containing single quotes, and possibly other characters, are not being properly escaped.

If any more info is needed I can provide it.

Also I thought I'd tack on to the end of this (possibly helpful) post that the one feature that I feel is lacking from ktorrent now that protocol encryption is in SVN is file priorities. I frequently used that feature in other clients. I think it is a natural complement to selective downloading, which is already part of ktorrent.

phantom042 wrote:Also I thought I'd tack on to the end of this (possibly helpful) post that the one feature that I feel is lacking from ktorrent now that protocol encryption is in SVN is file priorities. I frequently used that feature in other clients. I think it is a natural complement to selective downloading, which is already part of ktorrent.

Though I can't help you with your file name problem, I'll still post about the latter comment. KTorrent has a QueueManager (click the QM button along the top) which allows you to priorites and queue file downloads. Is this what you are after?

Yeah, I wasn't very clear. It was just a little note so I didn't bother improving my description.

What I mean is: say a torrent contains several files. Normally, all of the files finish at essentially the same time since the order in which chunks are downloaded is random. Because of this, you basically can't use any of the files until all of them have completed.

Several clients (BitTornado and uTorrent for sure, I think Azureus and others) have a feature where you can prefer to download chunks from a given file before chunks from other files. That way, assuming all the chunks for a given file are available, you will complete it first and be able to use it even though the entire download is not complete. In BitTornado you can choose "Download First / Normally / Later / Never" so it serves both the purposes of file prioritization and selection (which you can already do with KTorrent).

The reason I mentioned it is that I think KTorrent is by far the best bittorrent program for Linux (I switched to primarily using KDE instead of Gnome because it's the best and I use it so much) and that is the only feature I miss from uTorrent or BitTornado. It's still better than BitTornado in my opinion because it handles multiple downloads, which is very important, but it would be better in every way if I could also prioritize files within a download.

phantom042 wrote:I recently downloaded a single file torrent with a name like "Blah Blah Blah's.avi". When ktorrent attempted to save the file, it gave an error. I guessed that the single quote / apostrophe was the problem, so created a directory whose name was just a single apostrophe, and then tried to open the torrent again and this time saved the file in that directory, and it worked.

Seems like filenames containing single quotes, and possibly other characters, are not being properly escaped.

If any more info is needed I can provide it.

Also I thought I'd tack on to the end of this (possibly helpful) post that the one feature that I feel is lacking from ktorrent now that protocol encryption is in SVN is file priorities. I frequently used that feature in other clients. I think it is a natural complement to selective downloading, which is already part of ktorrent.

Did you experience this bug with SVN ?

I'm waiting to install svn (I compiled it yesterday) until something I'm downloading now completes. That will probably happen in the next 12-24 hours.

I added a bug to the KDE bugtracker and will update it if I also have the problem with svn.

EDIT: Just checked the bugtracker, and it seems this problem is already fixed in trunk. I did do a search before I posted that bug but apparently I missed one or it wasn't listed. I will confirm later / tomorrow and post again.

phantom042 wrote:I'm waiting to install svn (I compiled it yesterday) until something I'm downloading now completes. That will probably happen in the next 12-24 hours.

I added a bug to the KDE bugtracker and will update it if I also have the problem with svn.

EDIT: Just checked the bugtracker, and it seems this problem is already fixed in trunk. I did do a search before I posted that bug but apparently I missed one or it wasn't listed. I will confirm later / tomorrow and post again.

I closed it because I'm pretty certain we have dealt with these kind of problems. But if it still shows with the svn version I will have to reopen it.

Just installed latest svn and had no problems, using the same file that I used with 1.2. So you were right to close the ticket. I like the other changes too, like the upload slots setting and separate downloading / seeding tabs. Protocol encryption seems to be working fine. Thanks for all the hard work.

Regarding setting file priorities, should I create a whishlist bug in the bugtracker for it? The logic is fairly simple: if a file is flagged to be downloaded first, strictly prefer any piece that has data from that file to any piece from another file, regardless of rarity. It's just like the current priority system except applied to files within a torrent instead of between different torrents, assuming I understoon the code in chunkselector.cpp.

I could try writing a patch that adds the basic functionality if it would be accepted, and someone else is willing to write the UI code.

phantom042 wrote:Just installed latest svn and had no problems, using the same file that I used with 1.2. So you were right to close the ticket. I like the other changes too, like the upload slots setting and separate downloading / seeding tabs. Protocol encryption seems to be working fine. Thanks for all the hard work.

Regarding setting file priorities, should I create a whishlist bug in the bugtracker for it? The logic is fairly simple: if a file is flagged to be downloaded first, strictly prefer any piece that has data from that file to any piece from another file, regardless of rarity. It's just like the current priority system except applied to files within a torrent instead of between different torrents, assuming I understoon the code in chunkselector.cpp.

I could try writing a patch that adds the basic functionality if it would be accepted, and someone else is willing to write the UI code.

You can make a wish, that way we don't forget it.

Code would also be fine, the GUI code is probably the biggest issue, because we can allready prioritize chunks (we prioritize the first chunks of multimedia files for the preview feature).

another error with filenames (in 30-07-06 svn):
can't preview files with space before # char in filename
example:
file /tmp/tor61/cache/something #6.mp3
can't open file
/torrent/tmp/tor61/cache/something%20#6.mp3

lukas wrote:another error with filenames (in 30-07-06 svn):
can't preview files with space before # char in filename
example:
file /tmp/tor61/cache/something #6.mp3
can't open file
/torrent/tmp/tor61/cache/something%20#6.mp3

I will check it out.

OK, it should be fixed now

one more thing... column of bytes "downloaded", I have noticed that it is coming up to total size of torrent or still downloading and showing equal both downloaded and total size, but if I calculate size of chunks not downloaded yet (or see bottom graphical status with downloaded chunks - you see white holes), it is not correct. If I stop them and start again, it shows "downloaded" size ok
It does not matter how long they are running but you should see more difference if torrents are running for a longer time and if they are big, the same svn snapshot

lukas wrote:one more thing... column of bytes "downloaded", I have noticed that it is coming up to total size of torrent or still downloading and showing equal both downloaded and total size, but if I calculate size of chunks not downloaded yet (or see bottom graphical status with downloaded chunks - you see white holes), it is not correct. If I stop them and start again, it shows "downloaded" size ok
It does not matter how long they are running but you should see more difference if torrents are running for a longer time and if they are big, the same svn snapshot

Actually we just cap the number to the size of the torrent, for several reasons some parts of a torrent can be downloaded twice or more.