Re"hashing" krppkr corruption -- Why the "patch" on emule?

[lsvll1]

When I do an emule search now for krppkr (which I know has a long thread about a corrupted file being dispersed due to a ChessBase copy), there's a "KRPPKR-Patch.exe" available to download. Is this a necessary file? What does it "patch"? (I've been burned by downloading an exe file before, so I'm just wary.)

Thanks.

[Kirill Kryukov]

Don't download it, or any other executables from eMule. There is no any valid reason to share an executable via eMule. Also, KRPPKR currently shared on eMule is the correct one as far as I am aware (as long as you use the links from the index page).

[Pachnes]

When you do a search in eMule, the files you have already downloaded will be shown in green colour. The files you are just downloading will be shon in red colour. There is a second (corrupt) krppkr.2.nbw.emd, which is shown in black colour. Black means, this file is completely new for you. Look, both files krppkr.2.nbw.emd have the same name, but they have a different hashvalue and so they are different.

Kiril is right, only start downloading tablebase files by clicking on the ed2k-link at http://kirill-kryukov.com/chess/tablebases-online/. Then you can be sure, you do not download fake files.

[Codeman]

I never understood the motive for people doing damage through corrupting files (like in this case egtb-files)

[Kirill Kryukov]

I never understood the motive for people doing damage through corrupting files (like in this case egtb-files)

As far as I understand it, it is not done on purpose. Simply someone gets corrupted file (which can easily happen moving around a terabyte of data). Then that someone does not know the file is corrupted and keeps sharing it. So the best we can do is inform him that he is sharing a corrupted file. Someone doing it intentionally is unimaginable to me too.

[lsvll1]

Kiril, thanks for the warning about executables. I'm always tempted to download exe's when they're for a file I REALLY want -- but ultimately it's not worth the risk (e.g., like damaging the kernel on my laptop several months ago).

BTW, Thomas, this post wasn't about whether or not any krppkr files (among many others) are corrupt (which I know -- I've already read the long thread on that topic), or about red or black or green eMule search results, which I know after downloading thousands of eMule / eDonkey files over the years, or where the best place is to download EGTB files, which I also know (and thanks for that incredible service, Kiril!). Or perhaps, Thomas, you were just re-informing other members about that older topic???. THIS post is about the specific eMule search result "KRPPKR-Patch.exe."

My reason for interest in a patch? I did an eMule search for krppkr while investigating a problem I'm having with using the krppkr files (which I have a complete set of, among about 30 other TBs). While other EGTBs are working perfectly (and I have not yet tested them all), krppkr has been ineffective, such as during one of Kiril's "longest checkmates." Perhaps this is because I don't have kqrpkr yet (what are your all's thoughts?). Still, having some doubts about that possibility, I had some interest in the patch I ran across because I thought (in my technological naivete) that perhaps this set of krppkr files needs a patch. And that's why I posted this.

Thanks guys,

Patrick (lsvll1)

[lsvll1]

(BTW, regarding the comments made above on different colored search results on eMule, to be specific and accurate: a red search result means either you are NOW downloading it, or you have ALREADY downloaded it in full and are SHARING it (makes sense because either way, you're sharing it). A green search result means you have either cancelled your download, or you have completed your download but moved it to a place eMule doesn't access (makes sense because either way, you're NOT sharing it). So it has to do with sharing. Can't we all get along?! Also, since each color has 2 meanings, eMule shows what is what on the far right of the search result page under the column "Known." Except regarding Black, which of course does mean you haven't ever tried to download it.)

[Kirill Kryukov]

Hi Patrick,

I'm sure Thomas is just trying to help. His advices are more often useful than not to many people new to emule. Our usual experience is people coming here totally clueless about eMule and file sharing. So no need to get so defensive. Also by the way from your question I would have assumed the same like him because a seasoned user knows it's generally a bad idea to download executables from eMule.

While other EGTBs are working perfectly (and I have not yet tested them all), krppkr has been ineffective, such as during one of Kiril's "longest checkmates." Perhaps this is because I don't have kqrpkr yet (what are your all's thoughts?).

Can you please post the position, and describe what engine and GUI you are using, also what EGTB you have installed? Also what the actual engine output is? This could help understanding it. Many reasons are possible, including a bad test position. Also, just to make sure, did you check your EGTB files using MD5 signatures shared on the project page?

Still, having some doubts about that possibility, I had some interest in the patch I ran across because I thought (in my technological naivete) that perhaps this set of krppkr files needs a patch. And that's why I posted this.

Makes sense. Also very sensible to ask here before downloading the patch. Good luck and all the best!

[lsvll1]

Hi again,

Firstly, you’re completely right about the above response to Thomas. I need to read what I write aloud, since I somehow imagined a friendly banter and not a dangerous psychosis. Sorry about that Thomas. I actually see you (i.e., Pachnes) regularly on eMule, and we’ve shared many gigabytes of files. (it’s that sharing thing again)

Anyway (this is embarrassing), it was krppkq, not krppkr, that gives me problems. So that makes the issue of the patch kind of irrelevant to my problem – but then, we’ve already dismissed the patch question anyway. [Basically, I saw the patch under the krppkr search and thought, hey, there’s a patch on this file… maybe it addresses the EGTB that’s not working for me. I just didn’t confirm it.]

Which still leaves the problem of krppkq. I’ve only tested it with the following positon (which is listed on your website of longest checkmates):

8/k1P5/8/8/1R5P/8/K7/7q w (and mate in 216)

The GUI and engine are both Fritz 11. I’ve also tried Rybka 2.3.2a with the same position on the Fritz GUI, and I think Naum 3. The engine gives +/= and is clearly searching SOME tablebase, as the Fritz GUI reports that kind of activity with “tb = N” in the engine’s analysis (N ever-increasing). (As an aside, along with “tb = N,” you also know Fritz is using EGTBs when you start the program up and a small window appears that says “Initializing Engine.” And the larger the tablebase files, the longer that window is up. That info is from Steve Lopez at ChessBase.)

While Fritz can’t solve the above mate, very interestingly, there’s a mate in 211 listed on the same site (right beneath the above position) for krppkp on an almost identical (!) position to the above (which makes sense since the black pawn immediately queens):

8/k1P5/8/8/1R5P/8/7p/3K4 w

In this position (again, a krppkp position that immediately becomes a krppkq position), Fritz solves the problem immediately!

[Also, I have triple-checked my hash sums, and the following 6-piece EGTBs are installed on Fritz so far: kbpkbp, kbpknp, kbpkpp, kbppkq, kbppkr, knpknp, knpkpp, knppkr, kppkpp, kpppkn, kpppkq, kpppkr, kqbkqn, kqpkqp, kqppkp, kqppkq, kqqkqq, kqrrkq, kqrrkr, krbkrp, krnkrp, krpkbp, krpknp, krpkpp, krpkrp, krppkp, krppkq, krppkr, kbbkbb, kbbkbn, kbbknn, kbnkbn, kbnknn, kbnnkr, knnknn, krrkrn. And of course 3, 4, and 5 pieces.]

And if you got this far, thanks for taking the time! Perhaps it IS a problem with the position?

Patrick

[Kirill Kryukov]

Interesting. Some engines and interfaces are known to have EGTB bugs, may be the case here? I don't have Fritz 11, so can't check it here, but may be someone will check it? Asking Chessbase support may be an option too. Those positions were found using Wilhelm, to which I usually trust. Online EGTB query (this one) confirms that "8/k1P5/8/8/1R5P/8/K7/7q w" is mate in 216. Good luck!

EDIT: One idea: Try to disable EGTB support in GUI, and check with the engine itself. Then a UCI engine like Naum or Rybka should check the tablebase by itself. By using EGTB support in the GUI, an engine is never asked to query the tablebase, it is all done in GUI (if the current position is within the table).

[lsvll1]

Hi Kiril,

I have new information on the krppkq position (8/k1P5/8/8/1R5P/8/K7/7q) that stumped my Fritz 11, andI think it strongly suggests the solution to the problem. It turns out that krppkq does work, just not on the "longest checkmate" position. I found 2 other 6-piece positions that work in general, but not on their own "longest checkmate" positions, those combinations being: krpknp (4n3/6P1/5k2/8/8/8/1p1K4/R7 w, and 198 to mate) and krpkbp (8/3R2P1/7k/8/8/8/5p2/K5b1 w, and 166 to mate). The common feature of the 3 positions is that they each have at least one pawn on the 7th rank. And not yet having the promotion tablebases for each of these, I would guess that it's most likely the "incomplete tablebase problem." Which I probably should have thought of before.

FYI, before figuring out the above, at your suggestion I also ran the krppkq position on Rybka with tablebases enabled for Rybka but not for the GUI, and Rybka also could not figure the position out.

Thanks,
Patrick

[ath]

When I do an emule search now for krppkr (which I know has a long thread about a corrupted file being dispersed due to a ChessBase copy), there's a "KRPPKR-Patch.exe" available to download. Is this a necessary file? What does it "patch"?

As noone seems to have addressed the last question: this *may* be the patch required to get the KRPPKR off ChessBase Turbo Endgame 2 (I think) going. A simple consistency test of those particular endgame files show that there is an error in one of them, and ChessBase customer support sends out that file as a fix.

If I remember, it must be placed in your appropriate EGTB directory to be applied, and it's not always removed -- and as that directory also tends to be shared, it usually shows up.