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 <[email protected] > <mailto:[email protected]>> 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 > > _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
