Bug and issue

[NLS]

I run qBT on a Win10 x86 laptop, 5 torrents seeding from one disk, 3 torrents on another, where one is seeding, one is downloading, and the problem is with the third. This torrent is complete more than 90% (it is also big, over 100GB).

Thing is, the torrent stops almost immediately with I/O error. WHAT I/O error? I don't know (here is the bug), because the system pop-up doesn't fit the reason and it times out immediately before I am able to try anything. I tried to find if qBT save saves a log anywhere, no luck.
Also the I/O error can't be real, as I said 2 more torrents are working from same disk.

Any ideas?
Right now I am rechecking that huge torrent, hopping it will clear problems.

BTW  ARE YOU TRYING TO DRIVE US NUTS?
It kept telling me I don't answer security questions correctly because it asked what year we have, EXPECTING 2015!!! (NOT 2016!)

[ciaobaby]

Client version??

And what does the execution log show when this happens?? (View -> Execution Log)

I/O errors at 90% possibly means that there is a damaged disc sector in the space that is allocated to this payload.

You should run the 'check disk'  utility (in a command prompt before Windows starts) to ensure this is not the case.

Other problems could be a '.' or a space at the end of a file name [and extension], other operating systems have no problem with this, but Windows does.

[NLS]

Well after I rechecked the torrent it did go forward. Now I have different problem, but this deserves new post.

View/Execution Log doesn't do much... what should it do? Because it doesn't display anything.

Version is 3.3.3.

[NLS]

Ah found the log! It was a tab on top, I didn't see it.
Well I think I know what is happening then.

There is a tiny readme file that is common in more than one torrents seeding from same folder (yes on purpose). Seems they were fighting all to access it.

While I understand why this could be a problem with downloading (*), I hope it won't be a problem when seeding them all.

If qBT failed with a piece though, it should go on and try ANOTHER piece, not just stop.

(*) Seems although the file was there for all torrents to see, for some it was like "missing" because the rest of the piece was missing yet. Now if qBT handled this a bit smarter, would be nice... but I understand it's a complex thing to do.

[ciaobaby]

Seems they were fighting all to access it.

As they would, given that it is most probably occupying different pieces in each payload and while ever the payloads are mixed together WILL continue to screw things up!

Now if qBT handled this a bit smarter, would be nic

ABSOLUTELY NOTHING  at all  to with qbittorrent  being a bit 'smarter' as this is ENTIRELY a PEBCAK (Google it)  problem created by NOT understanding how the Bittorrent protocol actually works!

[NLS]

Thanks, I am perfectly clear how torrents work.

I think it helps that I am 32 years in computing, more than half of them professionally.

Anyway what smart handling of such cases would be?

Piece is missing but some files are there with proper size, MARK them as present pending verification.
Torrent can only check piece checksum, so when piece comes from seed complete (having in it, complete files and/or parts of files), at OS level don't let the files that are already marked on disk be overwritten, verify piece checksum, if it's ok all fine, if not, then overwrite what was temporarily protected.

I know this would create overhead.
Maybe it could be some advanced switch somewhere.

Another solution, if full path to files between torrents is common (up to file level, so a file is common), then if one torrent has this file complete (i.e. the piece/s that hold that file) and another torrent doesn't have it complete yet, then don't touch that piece (for seeding) until the other torrent also marks it as complete (so then both torrents just try to read the file, not one read it and one write it).

Bad practice? Yes maybe. Actually I say, this IS bad practice. But sometimes there are reasons to do it (usually involving not having extra copies of huge torrents).

Note that cr*ppy utorrent doesn't have this issue. So they solve it somehow.

Anyway I don't expect any change on this. It's just discussion for the shake of discussion at this point.

[ciaobaby]

I am perfectly clear how torrents work

The fact that you purposefully or deliberately allowed two different payloads (that 'share' file names) to be 'merged' (for want of a better word)  does demonstrate that you are, at the very least, misguided in how they'work' at the fundamental level. Because if you were "perfectly clear" you would not have allowed it to, or made it happen, and after it had happened you would know  why this is not a 'bug' or an 'issue' but is a problem that you have "purposefully" created.

[NLS]

As I said, it makes sense that it has a problem, due to how torrent works (pieces instead of files).

Yet, seems that other clients do not have this problem OR (which I think is what happens) just retry and overcome transparently ("something wrong with that piece, let's try another and we'll get back to that").
Not sure if this has anything to do with the use of libtorrent.
I am not asking for anything just propose.

This started as a bug/issue until I found the reason it happens.

[ciaobaby]

Other payloads may not have a problem, never mind other clients.

It is all about how each individual payload has been created initially and how the files are assembled and 'split' across the entire torrent structure, and when you try to shove two payloads into one folder, you take your chances on whether it 'breaks' or not , in this case it has 'broken'.

If, for instance, two identical structures of files and folders are created as a torrent by two clients, which could be the same 'make' or different and one has the piece size set differently, they WILL 'break', if one is sorting in name order and the other is size order (the default) they will 'break', before you can make the decision to locate them both in the same folder, you HAVE to be absolutely sure that they are identical at the binary level  of the data.

[NLS]

I read you.