Version: (using KDE 4.4.0) Compiler: GCC 4.4.3 OS: Linux Installed from: Gentoo Packages When enabling strigi with a virtuoso backend in 4.4, as strigi indexes its calls to virtuoso fail and/or it crashes the server but continues trying to bombard it with queries and floods .xsession-errors with messages. Last night when I noticed it my .xsession-errors had ballooned to approx. 780MB. Today after clearing ~/.kde4/share/apps/nepomuk/repository/ and re-enabling strigi my .xsession-errors was flooded to ~150MB in a matter of 4-5 minutes. There are a myriad of errors that get output but some highlights are: "/usr/bin/nepomukservicestub(24551)" Error in thread 139990499555088 : "SQLExecDirect failed on query 'sparql select distinct ?r where { { { { ?r ?v1 ?v2 . ?v2 bif:contains "'Top*'" . } UNION { ?r ?v1 ?v3 . ?v3 ?v4 ?v2 . ?v4 <http://www.w3.org/2000/01/rdf-schema#subPropertyOf> <http://www.w3.org/2000/01/rdf-schema#label> . ?v2 bif:contains "'Top*'" . } . { ?r ?v5 ?v6 . ?v6 bif:contains "'Gear*'" . } UNION { ?r ?v5 ?v7 . ?v7 ?v8 ?v6 . ?v8 <http://www.w3.org/2000/01/rdf-schema#subPropertyOf> <http://www.w3.org/2000/01/rdf-schema#label> . ?v6 bif:contains "'Gear*'" . } . } . { ?r a ?v9 . ?v9 <http://www.w3.org/2000/01/rdf-schema#subClassOf> <http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#FileDataObject> . } UNION { ?r a ?v10 . ?v10 <http://www.w3.org/2000/01/rdf-schema#subClassOf> <http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#Folder> . } . } . }' (iODBC Error: [OpenLink][Virtuoso iODBC Driver][Virtuoso Server]FT370: Wildcard word needs at least 4 leading characters)" It wrote thousands of lines of what seemed to be binary data from a bitmap escaped (sample: "BITMAP \n00\n54\n2A\n54\n2A\n54\n2A\n54\n2A\n54\n2A\n54\n2A\n54\n2A\n00\nENDCHAR\nSTARTCHAR U+20C0\nENCODING 8384\nSWIDTH 500 0\nDWIDTH 8 0\nBBX 8 16 0 -2\nBITMAP \n00\n54\n2A\n54\n2A\n54\n2A\n54\n2A\n54\n2A\n54\n2A\n54\n2A\n00\nENDCHAR\nSTARTCHAR U+20C1\nENCODING 8385\nSWIDTH 500 0\nDWIDTH 8 0\nBBX 8 16 0 -2\nBITMAP \n00\n54\n2A\n54\n2A\n54\n2A\n54\n2A\n54\n2A\n54\n2A\n54\n2A\n00\nENDCHAR\nSTARTCHAR U+20C2\nENCODING 8386\nSWIDTH 500 0\nDWIDTH 8 0\nBBX 8 16 0 -2\nBITMAP \n00\n54") It appears one thing that really messes with indexing are Canon RAW files (CR2). I'm not even sure what information to provide to be helpful because there is so much junk in the error log it's impossible to sort through. Any of this familiar? I read Virtuoso ODBC was misreporting its capabilities or something to that effect, perhaps that has something to do with it.
I've got a similar problem. I also use nepomuk + strigi + virtuoso, but in KDE 4.4 and my .xsession-errors also gets flooeded with these 3 lines: [/usr/bin/nepomukservicestub] "/usr/bin/nepomukservicestub(22704)" Error in thread 3011779440 : "Unsupported operation (2)": "Invalid model" [/usr/bin/nepomukservicestub] "/usr/bin/nepomukservicestub(22704)" Error in thread 3011779440 : "Unsupported operation (2)": "Invalid model" [/usr/bin/nepomukservicestub] "/usr/bin/nepomukservicestub(22704)" Error in thread 3011779440 : "org.freedesktop.DBus.Error.UnknownObject - No such object path '/org/soprano/Server'"
@Nate: query words need to be at least 4 chars in length at the moment. I will try to improve on that. @Christian: looks like Nepomuk is not running properly. Maybe something crashed.
Sebastian, Perhaps there is room for improvement re: a dialog warning of ongoing Nepomuk/Strigi errors that allows one to restart/disable scanning? The flooding of .xsession-errors is neither informative nor helpful. I'd imagine there's a better way to fail gracefully, and since this is a relatively silent problem it makes me wonder how many people this is happening to that simply are not noticing.
I have the same problem in kubuntu 10.04. My .xsession-errors gets flooded and I have the same "SQLExecDirect failed on query" messages as Nate in that file. How can I at least work around that problem that my .xsession-errors gets flooded?
i have this bug too: this problem started with kde 4.4.4 and i see that nepomuk flooding xsession-error when akonadi is active.
exact same thing here...
The query API now creates correct queries even for search terms with wildcards and less than 4 leading chars. Thus, there will be no more flooding with failed query messages.