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

[Vishesh Handa]

> 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?

Thanks

- Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100421/0151a8fb/attachment-0001.htm