Version: KMLDonkey 0.10pre3 (using KDE KDE 3.3.0) Installed from: Debian testing/unstable Packages OS: Linux When I search for any file in the Search Tab there don't not appear the Network and the Hash number. In fact, Network is always 0 and Hash 00000000000000000000 for all the files searched, instead the real value that I can see only after starting downloading the file. Because of it, I can't know if the searches are already downloading, those searches don't appear in a different color. This bug doesn't not appear if a use MLGui or Web. And one more thing, now the option "Download as" doesn't work in Search Tab, if I choose a name for the file the name will not be changed in the Downloads Tab and I will need to change it again.
Hi ibc, KMLDonkey got all those informations displayed at the searchresult from the core. This includes the hash as well as the information if the file was already downloaded. It would be great if you could update your KMLDonkey and look if this bug is still reproducable (for me it is not, what surly doesn't mean much). Also it would be great to know what MLDonkey-version you use. Thanks.
With 2.5.22 this is reproducable. Don't know why the core changed there behaviour again, but this is something we couldn't do much on cause we just got and display what the core spends. Therefore I mark this bug as WONTFIX (CANTFIX would be better). Maybe it would be an idear to report this to mldonkey.org?
OK, now I am using Kmldonkey 0.10pre4, with KDE 3.3.0 and mldonkey-server 2.5.28-2, and the same problem occurs, so I think it would be a good idea to report the bug to mldonkey.org. Thanks.
Seems http://savannah.nongnu.org/bugs/?func=detailitem&item_id=9945 already handles the wrong network-number. I just added that hashes are displayed wrong as well and a link to this bugreport :-)
The bug still occurs in kmldonkey 0.10pre4 and 0.10. A curiosity: If I put the cursor over the status bar (in the bottom of the window) there appear: "Protocol of actual graphic interface: 26 Protocol of core graphic interface: 29" I don't know the meaning of this, maybe the cause of the bug?
Hi ibc, no. This are the used protocol-numbers. As sayed I don't would look at kmldonkey for that bug. According to the bugreport listed above the bug is somewhere at the mldonkey-core :)
|| As sayed I don't would look at || kmldonkey for that bug. According to the bugreport listed above the bug is || somewhere at the mldonkey-core :) OK, thanks for your fast response. Just a question: If I use mlgui instead of kmldonkey, when I do a search there appear correctly the hash and the network of the files, so mlgui "knows" how to read the information of the core. Could the kmldonkey developers use that information to fix the problem? Of course. I believe you when you say that the problem is in the core. Anyway thanks a lot for your fantastic application.
Using the new version 0.10.1 something has changed about this bug: Now the "Hash" is shown correctly but the "Network" still is always "0". I only use the edonkey net, so it's possible that "0" is the "number" of edonkey net, I don't know.