I've fixed it, but I've used seconds instead of minutes. It's easier this way.<br><br>We have another problem. Even though the indexing is paused. I get an update that the indexingSpeed is being reduced. (Not Immediately. About 15-20 seconds after it has been paused)<br>
<div style="margin-left: 40px;"> <br>[/home/vishesh/kde/bin/nepomukservicestub] nepomukstrigiservice(3823)/nepomuk (strigi service) Nepomuk::IndexScheduler::setIndexingSpeed: 0 FullSpeed<br>[/home/vishesh/kde/bin/nepomukservicestub] nepomukfilewatch(3825)/nepomuk (filewatch service) Nepomuk::FileWatch::watchFolder: "/home/vishesh/indexing"<br>
[/home/vishesh/kde/bin/nepomukservicestub] nepomukstrigiservice(3823)/nepomuk (strigi service) Nepomuk::IndexScheduler::setIndexingSpeed: 1 ReducedSpeed<br><br></div>Normally indexing a folder, which has about 29 files takes about 1min 43 seconds. (It has a mix of sounds & images). When I deliberately pause the indexing (via dbus), it gets paused. The strigi widget shows that it's paused and so does dbus. Yet, the above output is displayed in the terminal, and on unpausing, the indexer takes lesser time. <br>
<br>I checked out IndexScheduler::waitForContinue, and it seems to be fine. I even added debugging statements and it is waiting. :-/ So, in the end I don't know whats wrong. Could someone else take a shot at this? BTW, this is happening with the earlier versions of the patch as well. I just didn't notice.<br>
<br><b>Other Things I noticed :</b> <br>I was going through the source code of IndexScheduler and I saw a function <br><div style="margin-left: 40px;">void setReducedIndexingSpeed( bool reduced = false );<br></div>Shouldn't the default value be true? <br>
<br><br>- Vishesh Handa<br><br><br><div class="gmail_quote">On Thu, Apr 22, 2010 at 12:41 AM, Sebastian Trüg <span dir="ltr"><<a href="mailto:trueg@kde.org">trueg@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On 04/21/2010 07:10 PM, Vishesh Handa wrote:<br>
><br>
> But I just realized yet another issue (sorry): QTime only measures a<br>
> single day. In theory the initial indexing can take more than an hour.<br>
><br>
><br>
> True. But I think what you meant was that the initial indexing could<br>
> take more than a day. In which case the time will get wrapped once it<br>
> exceeds a day, and hence be incorrect.<br>
><br>
> That means it could make more sense to measure the indexing time in<br>
> minutes only (let's face it, we do not care much about seconds and msecs<br>
> here). So maybe the best would be to remember the start of indexing as a<br>
> QDateTime and then sum up the minutes that have passed since then.<br>
><br>
><br>
> I don't get what you mean. If we just sum up the minutes since then we<br>
> wouldn't be accounting for the duration where the indexer was paused.<br>
> And that is the issue I wanted to address. Or maybe we could store the<br>
> dateTime when the initial indexing began, and store the paused time as<br>
> well (Is this what you meant?). But then the paused time is also<br>
> susceptible to the more than a day problem.<br>
><br>
> Could you please elaborate a little bit more?<br>
<br>
</div></div>I thought about storing the datetime when indexing starts. Then whenever<br>
we pause we do this:<br>
<br>
m_totalIndexingMinutes<br>
+= getPassedMinutes(m_indexingStartTime<br>
QDateTime::currentDateTime());<br>
<br>
then when indexing is resumed we again remember the time:<br>
<br>
m_indexingStartTime = QDateTime::currentDateTime();<br>
<br>
Of course the method getPassedMinutes does not exist yet. ;)<br>
<br>
Cheers,<br>
<font color="#888888">Sebastian<br>
</font></blockquote></div><br>