Version: 0.8.1 (using KDE 4.5.2) OS: Linux kget had to be killed because after becoming un-responsive. then when started again it erased an already finished download and started it again. and another almost finished download also. Reproducible: Didn't try Expected Results: checking or asking before deleting anything. OS: Linux (i686) release 2.6.34.7-56.fc13.i686.PAE Compiler: gcc
The problem is that KGet hang in the first place. Can you please describe what lead to it being unresponsive? Did it happen once the downloads finished, how long did you wait before killing it etc. ... On the redownloading, it sounds like it did not manage to save the change of the download state -- it does that once a download finishes -- most likely because of it hanging.
yes, once a download got to 99% it hanged for several minutes. then I killed it.
This sounds Nepomuk related. Does it hang for you if you disable Nepomuk? PS.: No I do not mean that Nepomuk is slow per se, often it is DBus etc. for me the same thing was slow with KDE versions many months ago and now it is blazingly fast.
it didn't hang again even without disabling anything.
Ok, so then I'll close this bug. The not saving was because it did not reach 100% while it hang. And the hanging is most likely (99,9%) Nepomuk related and in KDE 4.5.4 setting of Nepomuk stuff has changed, it will happen in its own thread and should not block then anyway. So in general you should not have this issue anymore with 4.5.4.
what do mean by "not saving"? the file was fully downloaded (100%), it was a movie and I played it to the end before restarting kget. then kget erased it and started downloading it all over again. the second file was 99% and was not supposed to be erased also. that sounds to me like a problem. shouldn't kget check before erasing anything?
KGet asks you if you want to overwrite a file etc. but not if you have already a transfer that is not finished -- that is what I think happened here. I think that because of the crash/killing saving the kget transfers.kgt file did not work and thus neither the current downloaded segments, nor the current state were saved. Instead the thing that had been saved was that the transfers existed -- that gets done once a transfer is added. That a lot of time passed between the one transfer finishing and then killing KGet sounds suspicous though. Did you add both transfers at the same time? And if not how far was the transfer that finished later on? Did the transfer that was finished start at 0% then?
the two transfers were added in about a minute or two one after the other (can't remember exactly). the transfer that finished was started the second.
And was the one transfer already hanging when the other finished?
to make it clear: download A started at t=0 download B started at t=60 download B finished at t=100 download A reached 99% at t=150 at t=151 kget hanged for long time. then I killed it. and started it again. then kget erased the already fully downloaded B and the 99% already downloaded A and started them both from 0%. sorry for the misunderstanding.
This is really tricky as it should have been saved. What kind of protocol was download B?
all http
I guess I found the bug. Could you please tell me which of those download plugins is activated in the settings: "KIO" and/or "Multi Segment KIO" I think that only KIO is activated, and there as I have noticed now no signal gets emitted if the download is finished, i.e. no changes are written to transfers.kgt.
Oh, maybe I was wrong in the above, in any case please still tell me which plugins are activated.
both KIO and Multi segment KIO plugins are activated.
Ok I might have found the error this time -- hmmm that is getting repetitive ;). Do you remember if KGet reported a size for download B, or did it only reported a size once it was finished? I.e. there are two possible cases: 1. You start the download, after a short while KGet shows a size of XY Bytes for B, the size of the file 2. You start the download, only when it finished KGet shows its size
SVN commit 1200339 by mfuchs: If a download did not report a totalsize do not use the finished chunks to calculated its processed size, as none has been set to finished. BUG:256774 M +7 -5 datasourcefactory.cpp M +5 -0 datasourcefactory.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1200339
SVN commit 1200346 by mfuchs: Backport r1200339 If a download did not report a totalsize do not use the finished chunks to calculated its processed size, as none has been set to finished. CCBUG:256774 M +7 -5 datasourcefactory.cpp M +5 -0 datasourcefactory.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1200346
Hi, I only did those two commits, to make sure this ends up in 4.5.4, so if what you experienced is "case 2" this bug is fixed, otherwise not. If it is not please reopen. Sorry for all the hassle.
thanks, I think it was option 1 but really can't remember for sure now. I don't know how to reopen a bug.
I just noticed that I reopened it by accident anyway. If you still have the link to the file you could try it.
I really think that this should be fixed, so if you experience this kind of problem in 4.6 then please reopen (changing the status to unconfirmed, or reopened if the later exists) the bug.