Arch Linux

KMail is also very slow: High cpu usage by virtuoso-t.
After downgrade to virtuoso-base-6.1.7-1 and virtuoso-6.1.7-1 everything works again.

According to the announcement downgrading
virtuoso-base also needs reverting 0e01d5b5
in nepomuk-core.

@Artur
commit 0e01d5b5 really does "nothing" http://quickgit.kde.org/?p=nepomuk-core.git&a=commitdiff&h=0e01d5b5

I'm waiting for upstream here, they told us to "absolutely" downgrade virtuoso...so I did.

Seems that the update to 4.11.1 solved this issue. Could anyone confirm?

I can't really confirm. Both Dolphin and Kmail behave sub-optimal.

There's a very distinct and random lag on certain actions like
selecting an email in Kmail, pressing arrow-down on the file list
with Dolphin.

Yep, after using dolphin/kmail for 2 hours I confirm your last feedback.

I can confirm that after 4.11 lag is a little bit smaller, but it still very uncomfortable to use dolphin with nepomuk service

Try making a backup (if you have tags), deleting your db, and letting everything reindex. I think the database format changed somewhat on upgrade, and the older version flips out when trying to read it. Probably this only hits you with files indexed when 6.1.7 was installed, so you might be able to do something clever to remove them. But hey, reindexing is easy and relatively fast now, plus you get to test that the indexer is working!

For me the issue was actually that dolphin search didn't really work at all - a bunch of files kept showing up as unindexed.

==Why I think this:==

I turned on debug output with kdebugdialog, restarted nepomuk with "nepomukctl restart" in a terminal and then reindexed some things using systemsettings.

I got a bunch of errors like this:
"SQLExecDirect failed on query 'sparql DEFINE input:inference <nepomukinference> select ?r where { ?r <http://www.semanticdesktop.org/ontologies/2007/01/19/nie#url> <file:///test.test> . } limit 1' (iODBC Error: [OpenLink][Virtuoso iODBC Driver][Virtuoso Server]SR496: Property <http://www.openlinksw.com/schemas/virtrdf#qmfMapsOnlyNullToNull> is not a field of struct qm_format_s, RDF class <http://www.openlinksw.com/schemas/virtrdf#QuadMapFormat>)")

If you look at this file:
https://github.com/openlink/virtuoso-opensource/blob/v6.1.6/libsrc/Wi/rdf_mapping.jso
vs this one:
https://github.com/openlink/virtuoso-opensource/blob/v6.1.7/libsrc/Wi/rdf_mapping.jso
you see that the latter has the row:
JSO_SCALAR qmfMapsOnlyNullToNull BOOLEAN OPTIONAL --!< Nonzero if the format gives NULL IFF short value is NULL

So, yes, the new db is not the same as the old.

==How to reindex (the brutal way, if you have no tags)==
Stop nepomuk
Edit $HOME/.kde4/share/config/nepomukstrigirc
so that it has "first run=true" instead of "first run=false"
Move $HOME/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend somewhere else.
Start nepomuk again

==How to reindex (the less brutal way==
Make a backup in system settings. Do the above. Restore the backup.
(arguably there should be a big red button somewhere to do this)

PS Probably a bad idea to upgrade again, because some of the nepomuk tests fail on 6.1.7, or at least did last time I tried.

Yes, upstream told me to NOT upgrade to 6.1.7 again.

I fixed the lag by wiping the nepomuk database.