Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - sledgehammer_999

Pages: 1 2 [3] 4 5 ... 153
Thanks for links. But I'm not sure that we're talking about the same thing. I mean the length of the "pieces" field. I fill it with 0 or 1 (0x00 or 0x01), it's correct. If calculation of the number of pieces is correct, it's all right.

IMO, the length should be taken from the .torrent file. It has a "pieces" field too.
About the "pieces" field in the fastresume: That's a byte array (or byte string). Each element is one byte(character) and represents one piece. Each byte has 8bits. Setting the 1st bit means we have that piece. Setting the 2nd means that we verified that piece aka it passed the hash check. If that piece is unverified, it usually gets hash-checked during seeding when it is requested for upload.
So, if I am not mistaken the correct values are:
1. 0x0 -> piece not downloaded
2. 0x80 -> piece downloaded but not verified
3. 0xc0 -> piece downloaded and verified
4. 0x40 -> I don't think this is valid. It means piece not downloaded but verified.

(those values were obtained from online binary to hex converters)

This does not apply to all torrents, and in the log, I see a io error ... error: permission denied. Apparently this is due not to the torrents themselves, but to something else. I'll try to figure out the other day.

Then that probably means that something's wrong with the conversion.

1.) Will the check runes for utf-8 be correct?

IIRC, normally you don't need to bother with the filenames. You do that if a) the user has renamed the file from inside utorrent b)or has explicitly moved it outside of the folder
In any case, you can't edit the .torrent files because it will change the infohash. The original filenames come from the .torrent. Libtorrent does a sanity check, and replaces invalid utf8 codepoints with and underscore ("_"). And uses this new sanitized string to look for files on disk.

I hope we are talking about the same thing/spot and I am not confusing you.

2.) I do not understand how to correctly calculate "blocks per piece" in fastresume. Now I'm using the logic from the previous scripts (on ruby), it works, but I do not like the concept of using fields from BitTorrent resume.dat for this. How to count this field?

I hope I talking about the same thing.
Unless I am mistaken blocks are always 16KiB. So a piece contains set number of 16KiB blocks. The only exception is the end piece which might contain less data.
I assume that you have to take the piece size from the .torrent file and divide it by 16KiB.

3.) I fill the "pieces" field by the number of torrentfile["info"]["lenght"] or sum lenght of files if it multifile torrent / torrentfile["info"]["piece length"] rounded to a larger number. Is it correct?

I think not. Maybe the calculation of the number of pieces is correct. The data you fill the piece array might not be correct.
Some more info:
Here's an old explanation by me on what I had found on resume.dat when I experimented with it. Link to specific comment. You might want to read the thread from the start to get any other useful info.
And from libtorrent docs here's an explanation on what various fields in the fastresume do:

4.) Now i rehash all my torrents, and some my torrents in which not all files have been selected for downloading, no fully completed. That's ok, bittorrent/utorent create ~BitTorrentPartFile.*.dat, which contain some data, and i not convert it. I am confused that after rehash torrents just stuck. Any idea why this is possible?

Maybe it is in weird state, or you just don't have any peers anymore?

Despite the fact that the code works nominally, for me there are still things that I do not really understand where to get it  and I would like to rewrite it. But I'm not at all familiar with c/c++ code. If you could tell me a couple of things - that would be fine.

Ask here, and if I see it I'll try to answer.

Hi Sledge, could you see if in the next release you can make qBittorrent more robust finding files when rechecking?
If I don't have the directory in my 'default save path' it just won't pick up the files, doing a recheck yields no results. The save path is corrent (folder containing sub folder of torrent name)
This is the issue I commented on in the previous beta thread and appears to be a rather long standing issue.

Do you use the "keep incomplete torrents in" option?
Care to rewrite the steps to reproduce?

Windows / Re: Version 4 PARTS files?
« on: May 06, 2018, 12:33:51 pm »
.parts files contain pieces from partially downloaded files that are unselected. Usually the edge pieces between 2 consecutive files.
IIRC once a file is written to the filesystem(eg by momentarily selecting it in the file view), those pieces don't return to the .parts file if you unselect the file.
Also I think libtorrent doesn't allow us to configure where the parts files is created.

Windows / Re: Is this normal or am I hacked?
« on: May 06, 2018, 12:30:47 pm »
If you have Local Peer Discovery enabled there's a possibility that the client is detecting itself and tries to connect to itself. It realizes this afterwards and drops the connection. Hence no upload/download and the same client version and torrent progress.

  • Processing torrents with non-standard encodings (for example, cp1251)

Do you mean filename encodings inside the torrent file? If so, what do you do with that?
.torrent files should have utf8 encoding for the filenames. Otherwise, libtorrent replaces invalid utf8 codepoints with an underscore "_". Do you handle this?

Link to 4.1.7 post->,5916.msg31784.html#msg31784


Here is qBittorrent 4.1.0 built with MSVC 2017.

4.1.0 link->

Libraries's version used:
Libtorrent: 1.1.7+git8808eb7cdd
Qt: 5.6.3 (32-bit) / 5.10.1 (64-bit)
Boost: 1.67.0


some of the problems you describe might be related to libtorrent and not qbittorrent. Libtorrent has some fixes related to stuff you mention in the next release. Those will be included in my next release too.
Wait to try my new release.
In case problems persist, I would like step-by-step instructions on how to reproduce each of your problem.

To be sure that you are pointing qbt to the correct directory level, after adding a torrent, check "Save Path:" label under the "General" tab.

The "Do not Download" priority isn't for what you wanted it to be. It just sets a file/piece priority. Those pieces might still be downloaded if they are shared pieces with other files.
After a file has been fully downloaded it doesn't make sense to have its pieces' priorities changed.
Libtorrent has an "upload only" mode, but that isn't exposed as an option in the GUI.

Move success/failure might be reported in the log. I am not sure about that. You need to check.

"run external program" feature has seen some fixes after 4.0.4. They will be included in the next release too.

so i just noticed that there is a new version available, looking trough the log changes i see no fix for that qbit is not properly reporting ratio/upload, i will take that then as not fixed  :thumbsup:

Subscribe to this bug:
(libtorrent bug tracker)

Can you (or someone) compile a new build with this fix so we can test it?

Please test this:

so i just noticed that there is a new version available, looking trough the log changes i see no fix for that qbit is not properly reporting ratio/upload, i will take that then as not fixed  :thumbsup:

Subscribe to this bug:
(libtorrent bug tracker)

Here is qBittorrent 4.0.4 built with MSVC 2017.

4.0.4 link->

Libraries's version used:
Libtorrent: 1.1.6+git01c41fadcf
Qt: 5.7.1 (32-bit) / 5.10 (64-bit)
Boost: 1.66.0

I've downloaded the "Windows x64" version 3 times so far and everytime I try to run the installer, I  receive an "Installer integrity check has failed".

No idea if the error is on my side, your side or Fosshub.
I just figured I'd point it out, just in case.

The version 4.0.4 installer on fosshub seems to be busted.

The fosshub windows x64 exe is 41.4 MB and fails integrity check. Checksum doesn't match - eecefe1182b323e65dd79bb98d76391178c75238440363944646727503035d57
The SourceForge windows x64 exe is 21.4 MB and runs. Checksum matches - 27420dec31a55b6e4745be7db1e12feb82a5a18b8186a7f0fc339fc97a7b612f

Seems like there's a difference between the two. Those looking to install 4.0.4 should use the SourceForge mirror.

Thanks for the reports. Apparently it is fixed already from the FossHub team. They have emailed be about it.
It was a botched upload. I didn't catch the file size error (nearly double) because it was late at night for me. Sorry.

Here is qBittorrent 4.0.4 built with MSVC 2017.

4.0.4 link->

Libraries's version used:
Libtorrent: 1.1.6+git01c41fadcf
Qt: 5.7.1 (32-bit) / 5.10 (64-bit)
Boost: 1.66.0

Here is qBittorrent 4.0.3 built with MSVC 2017.

4.0.3 link->

Libraries's version used:
Libtorrent: 1.1.5+gitd52763805c
Qt: 5.7.1 (32-bit) / 5.9.3 (64-bit)
Boost: 1.65.1

Can i ask whats the benefits of this build compare to official? Or is this the official just posted here?

Cause its using exactly the same versions as the official.

This is the official one, since it links back to the main download page.

Here is qBittorrent 4.0.2 built with MSVC 2017.

4.0.2 link->

Libraries's version used:
Libtorrent: 1.1.5+gitf42b63c7ea
Qt: 5.7.1 (32-bit) / 5.9.3 (64-bit)
Boost: 1.65.1

Pages: 1 2 [3] 4 5 ... 153