crawler timerange comparison wrong

Bug #903791 reported by KarlRelton
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Activity Log Manager
Invalid
Undecided
Unassigned

Bug Description

As per https://bugs.launchpad.net/bugs/646724

The crawler.py code in a-l-m has a bug (lines 126-128) comparing a timestamp in the form
of a string with another in the form of a float/interger. Thats why it always
inserts 0 events (timestamp test always fails).

It also has a potential divide by zero bug if there are zero 'valid_uris' at line 86.

Revision history for this message
KarlRelton (karllinuxtest-relton) wrote :

I have spent some time digging and working out why the Retrieve Past
activities function in the activity-log-manager doesn't actually seem to
work.

For background I am referring to
https://bugs.launchpad.net/bugs/646724

I have been playing with both activity-log-manager in trunk, and a
'history.py' script that Sief kindly referred to on his blog a while
back. Both use effectively the same code.

Here is what I believe I have found:

1) the crawler.py code has a bug - i.e. this bug report

on my system that stops it from ever inserting any events. Its a trivial
fix.

2) The code inserts events with manifestation HEURISTIC_ACTIVITY.
Yet the two UIs I am interested in, namely g-a-j and Unity Dash Files
lens only search on events with manifestation USER_ACTIVITY.
This is why even when I corrected #1 I still could not see any results.
Changing over to USER_ACTIVITY and life suddenly looks much better!

3) The code inserts events with actor set to the uri for
activity-log-manager. Not unreasonable, except that g-a-j for some
reason deliberately filters events with this actor from its search! So
having corrected #1 & #2, I was starting to see my past files in the
Unity Dash Files lens, but not in g-a-j.

I'm not sure what the rationale for this deliberate filter-out in g-a-j.
I guess it is debatable whether events inserted by the retrieve history
function should really show up in a front end like g-a-j.

My personal preference is that they should, since I would often like to
use g-a-j (or something like it) as a means of finding files and opening
them, including those inserted into the zeitgeist database by the
retrieve function. Since the event timestamps of such files are sensibly
set to the mtime of the subject file, they would show up in
sensible/expected places in the timeline (i.e. when then were last
modified) - which for me would be just great.

Can you give me a heads up on your own thinking on this issue, which of
course has been around ever since zeitgeist entered into mainstream
usage?

Thankyou for your work and development of zeitgeist - it is great
technology.

Revision history for this message
Siegfried Gevatter (rainct) wrote :

I'm closing this since the crawler currently isn't included in the latest release of Activity Log Manager (Vala version).

However, thank you for your analysis! We'll take it into account if/when crawling functionality gets re-introduced.

Changed in activity-log-manager:
status: New → Invalid
Revision history for this message
Manish Sinha (मनीष सिन्हा) (manishsinha) wrote :

Crawler might be added sometime later. Right now no plan for adding it

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.