Upon opening GNOME Activity Journal never gets past "Loading journal"

So I stopped in the zeitgeist daemon (`zeitgeist-daemon --quit`), backed up my zeitgeist database (~/.local/share/zeitgeist/activity.sqlite) and deleted my zeitgeist database. Then I started zeitgeist-daemon again (`zeitgeist-daemon --replace`) and started gnome-activity-journal. Now gnome-activity-journal starts fine, but of course I have no history.

I stopped zeitgeist-daemon, restored my backup of the zeitgeist database and started zeitgeist-daemon in debug mode this time (`zeitgeist-daemon --log-level=DEBUG --replace`) and piped stdout and stderr to a file. I see the former behaviour in gnome-activity-journal (stuck at "Loading Journal") and as I watch a tail of the log file I see after about 10 seconds a bunch of dbus timeout errors.

I will attach the log file. According to zeitgeist-daemon the database is fine:

[DEBUG - zeitgeist.sql] Core schema is good. DB loaded in 1.32012367249ms

...but I'm getting dbus timeouts:

[ERROR - dbus.proxies] Introspect error on :1.316:/org/gnome/zeitgeist/monitor/1
: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not rec
eive a reply. Possible causes include: the remote application did not send a rep
ly, the message bus security policy blocked the reply, the reply timeout expired
, or the network connection was broken.
[DEBUG - dbus.proxies] Executing introspect queue due to error
[ERROR - dbus.proxies] Introspect error on :1.316:/org/gnome/zeitgeist/monitor/2
: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not rec
eive a reply. Possible causes include: the remote application did not send a rep
ly, the message bus security policy blocked the reply, the reply timeout expired
, or the network connection was broken.

That is just a sample. I get that several times in the log. Is this a problem with dbus then? Any thoughts?

Btw, this was milestoned for 0.8.1, but I'm now running 0.8.1:

$ dpkg-query -W zeitgeist*
zeitgeist 0.8.1.1-1
zeitgeist-core 0.8.1.1-1
zeitgeist-datahub 0.7.0-0ubuntu3
zeitgeist-extension-fts 0.0.7-0ubuntu2

Could you paste the output of `dbus-monitor "sender='org.gnome.zeitgeist.Engine'" "destination='org.gnome.zeitgeist.Engine'"`? (run the command, then AJ, when it hangs press Ctrl+C in the terminal running dbus-monitor and save the output).

Log file attached. I didn't restore the old db, but now that the fresh db must have some content I'm getting the same hang. Please let me know if you need a log from both the original database (with lots of content) and this database (with little content).

Hey - I'm also experiencing this issue. Here is the output of the dbus-monitor command specified above (with a seemingly bad database).

Surprisingly, I installed some 300MB of updates and now AJ starts working fine. Does it work for anymore after installing all latest updates?

g-a-j works for me out of the box on an up to date oneiric (10 sep).

It works for me too now.

It does not work for me. The timeline at the bottom of the Loading screen says my activity stopped on Monday 26 September.

It was working. After doing update (past beta 2) it broke again

Same issue for me. No visible indicators for issue.

When run from command line, the following shows:

[code]
$ gnome-activity-journal
/usr/share/gnome-activity-journal/src/main.py:206: Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed
  self.show()
/usr/share/gnome-activity-journal/src/store.py:235: Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed
  while gtk.events_pending():gtk.main_iteration(False)
[/code]

Any suggestions?

Same problem here.
I stopped zeitgeist, removed db
started zeitgeist => ~/.local/share/zeitgeist/activity.sqlite started
then worked 5 minutes

gnome-activity-jounal stalles again

Got 1 events in 0.000139s
[DEBUG - zeitgeist.engine] Where time spent in _get_event_from_row in 0.000000s
[DEBUG - zeitgeist.engine] Where time spent in _get_subject_from_row in 0.000000s
[DEBUG - zeitgeist.engine] Where time spent in apply_get_hooks in 0.000000s
[DEBUG - zeitgeist.notify] Client disconnected :1.400
[DEBUG - zeitgeist.notify] Removing monitor :1.400/org/gnome/zeitgeist/monitor/6
[DEBUG - zeitgeist.notify] Removing monitor :1.400/org/gnome/zeitgeist/monitor/5
[DEBUG - zeitgeist.notify] Removing monitor :1.400/org/gnome/zeitgeist/monitor/4
[DEBUG - zeitgeist.notify] Removing monitor :1.400/org/gnome/zeitgeist/monitor/3
[DEBUG - zeitgeist.notify] Removing monitor :1.400/org/gnome/zeitgeist/monitor/2
[DEBUG - zeitgeist.notify] Removing monitor :1.400/org/gnome/zeitgeist/monitor/1
[ERROR - dbus.proxies] Introspect error on :1.400:/org/gnome/zeitgeist/monitor/6: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
[DEBUG - dbus.proxies] Executing introspect queue due to error
^C[INFO - root] Shutting down Zeitgeist interface...
[DEBUG - zeitgeist.engine] Closing down the Zeitgeist engine...
[DEBUG - zeitgeist.extension] Unloading all extensions
[DEBUG - zeitgeist.extension] Unloading extension 'DataSourceRegistry'
[DEBUG - zeitgeist.extension] Unloading extension 'StorageMonitor'
[DEBUG - zeitgeist.extension] Unloading extension 'Blacklist'
[DEBUG - zeitgeist.extension] Unloading extension 'SearchEngineExtension'
[DEBUG - zeitgeist.extension] Unloading extension 'ActivityJournalExtension'

I finally had a chance to look into this properly, the problem is that the CairoHistogram class calls set_background on itself in the expose-event handler, which most likely pushes another synthetic expose event to the event processing queue and we get to a nice infinite loop without overflowing the stack.

I'm not sure if we just want to remove the set_background call, or move it somewhere where it won't cause havoc.
@Manish / RainCT thoughts?

I got the application to run by just commenting out that line

This bug was fixed in the package gnome-activity-journal - 0.8.0-1ubuntu1

---------------
gnome-activity-journal (0.8.0-1ubuntu1) oneiric; urgency=low

  * Add patch to disable setting the background which was blocking AJ
    (LP: #831436)
 -- Manish Sinha <email address hidden> Tue, 04 Oct 2011 01:24:57 +0530

I just noticed today that there are more instances of setting background color inside expose event handler (in supporting_widgets.py and activity_widgets.py). Unfortunately these instances didn't cause such easily visible issue, what they do cause though is 100% cpu usage and blank pages for days when events are logged. :(

Just tell me which component I should blame for this mess? I guess gdk?

I have for timebeing disabled setting of background. I guess cando can have a look at this

Manish, as requested in my dupe, yes it's python /usr/bin/gnome-activity-journal.

Edit some files, when finished open g-a-j, delete some event addresses, pc almost freezes, htop showed python on 98% cpu and 78 % mem. Not possible to make a screenshot of htop due to system lag, waiting a few minutes makes system responsible and numbers go down again. Zero hints in syslog, kern.log, Xorg.0.log.