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

[Sebastian Trüg]

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