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

[Vishesh Handa]

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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100423/11f2b95c/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: text/x-patch
Size: 6151 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/nepomuk/attachments/20100423/11f2b95c/attachment.diff