[Nepomuk] [PATCH] Strigiservice Initial Run timing bug.

[Sebastian Trüg]

The new patch looks very good. I will apply it and also backport it to 4.4.
As for the reduced speed:
* A default value of true is probably more sane but the default is not
used anyway (compare strigiservice.cpp:122
* If you pause you move the mouse which triggers the setting of reduced
speed which results in slower indexing. Does this explain the delay?

Cheers,
Sebastian

On 04/23/2010 09:02 AM, Vishesh Handa wrote:
> I've fixed it, but I've used seconds instead of minutes. It's easier
> this way.
> 
> 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)
>  
> [/home/vishesh/kde/bin/nepomukservicestub]
> nepomukstrigiservice(3823)/nepomuk (strigi service)
> Nepomuk::IndexScheduler::setIndexingSpeed: 0 FullSpeed
> [/home/vishesh/kde/bin/nepomukservicestub]
> nepomukfilewatch(3825)/nepomuk (filewatch service)
> Nepomuk::FileWatch::watchFolder: "/home/vishesh/indexing"
> [/home/vishesh/kde/bin/nepomukservicestub]
> nepomukstrigiservice(3823)/nepomuk (strigi service)
> Nepomuk::IndexScheduler::setIndexingSpeed: 1 ReducedSpeed
> 
> 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.
> 
> 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.
> 
> *Other Things I noticed :*
> I was going through the source code of IndexScheduler and I saw a function
> void setReducedIndexingSpeed( bool reduced = false );
> Shouldn't the default value be true?
> 
> 
> - Vishesh Handa
> 
> 
> On Thu, Apr 22, 2010 at 12:41 AM, Sebastian Trüg <trueg at kde.org
> <mailto:trueg at kde.org>> wrote:
> 
>     On 04/21/2010 07:10 PM, Vishesh Handa wrote:
>     >
>     >     But I just realized yet another issue (sorry): QTime only
>     measures a
>     >     single day. In theory the initial indexing can take more than
>     an hour.
>     >
>     >
>     > True. But I think what you meant was that the initial indexing could
>     > take more than a day. In which case the time will get wrapped once it
>     > exceeds a day, and hence be incorrect.
>     >
>     >     That means it could make more sense to measure the indexing
>     time in
>     >     minutes only (let's face it, we do not care much about seconds
>     and msecs
>     >     here). So maybe the best would be to remember the start of
>     indexing as a
>     >     QDateTime and then sum up the minutes that have passed since then.
>     >
>     >
>     > I don't get what you mean. If we just sum up the minutes since then we
>     > wouldn't be accounting for the duration where the indexer was paused.
>     > And that is the issue I wanted to address. Or maybe we could store the
>     > dateTime when the initial indexing began, and store the paused time as
>     > well (Is this what you meant?). But then the paused time is also
>     > susceptible to the more than a day problem.
>     >
>     > Could you please elaborate a little bit more?
> 
>     I thought about storing the datetime when indexing starts. Then whenever
>     we pause we do this:
> 
>     m_totalIndexingMinutes
>       += getPassedMinutes(m_indexingStartTime
>                           QDateTime::currentDateTime());
> 
>     then when indexing is resumed we again remember the time:
> 
>     m_indexingStartTime = QDateTime::currentDateTime();
> 
>     Of course the method getPassedMinutes does not exist yet. ;)
> 
>     Cheers,
>     Sebastian
> 
>