Deluge and KTorrent - same torrent different data

[magick]

I had downloaded an ISO image with KTorrent 4.3.1 using a private tracker. After a while I decided to try out Deluge, so I installed the latest version (1.3.11).

I added the same torrent file, from the private tracker, to the Deluge and showed it a location where the already downloaded data were. Deluge automatically started checking file but made it only to 99.84% and then started downloading! It downloaded additional 56MB and then started seeding. Then I stopped it and returned to KTorrent which reported an error with that torrent data, after checking it KTorrent downloaded again some data and then file was OK by its definition, but not by Deluge!?!

I was not trying to cross-seed - it was the same data (ISO image to which I have legal rights by the way), the same torrent file from the same tracker! Can somebody please explain me what is going on? How different torrent clients can reproduce binary different data files?!?

P.S. I'm using GNU/Linux system - openSUSE 13.2 x86-64 with KDE 4.14.3.

[magick]

It's Deluge's fault - it corrupts data! I've double checked with Transmission 2.84 (14307) and 'torrent checker' program.

I had imported same torrent file in to four different torrent clients and gave them the same path to the same (already downloaded) data - all of them except Deluge verifies data successfully and starts seeding. Deluge fails to verify 8 out of 4,406 chunks (8 x 8MiB = 64MiB) and reacquires them in its own special way (basically corrupts them) which makes those chunks invalid for all other (that I've tested) torrent clients. If I let, some other torrent client to reacquire them again after Deluge they become valid for all other torrent clients which proves my assumption that Deluge miscalculates hash for some data chunks.

As I said, I'm using openSUSE 13.2 x86-64 and I installed Deluge 1.3.11 from distribution's Network repo.

[MarkusKramer]

Interesting.

Have you compared file content of the 'KTorrent version" with the "Deluge version"?
If they differ, then these 8 chunks are downloaded from somewhere and others too have corrupted versions of the file.

Can you disclose (make public) file and metadata (.torrent file)?
Which torrent checker do you use?
What outputs the torrent checker, in both cases?

[magick]

I didn't compared two "different" file versions because I didn't had enough disk space to save both versions (~40GB each) but I suspect that they did differ as at least two other torrent clients were not able to verify them. I've repeated the whole process several times. KTorrent/Transmission downloads it and verifies - Deluge fails to verify some chunks and downloads them again - then KTorrent/Transmission can't verify those chunks and want to re-download them. It could go forever.

It was a BD copy of a movie which I legally own and it was on a private torrent tracker. My BD-ROM broke down and I didn't have other option for testing DLNA streaming of BD media but to dl an ISO image of one.

I can tell you that all 8 chunks were scattered allover main .m2ts stream of the BD50.

'Torrent checker' is a program that my friend wrote for me at this occasion. He is a .NET developer and he says that it was a rather simple task as torrent file contains all needed data (number of chunks and their hash values), all he had to do is to parse and serialize all data in order to do check hash on each chunk. I didn't get to check Deluge's download with Torrent checker as it was painfully slow but i did passed check on KTorrent/Transmission 'version' so to speak.

[MarkusKramer]

Please run your checker on the "deluge version", calculating SHA should run only very little longer than simply reading the file (40GB < 5 min)
The checker should output, if they differ, the expected hash, the found hash, and the chunk.
This is the only way to analyse the problem I can think of.

I tried to find a standalone (Python) torrent checker but have not found one: can you ask your friend to disclose his?