This is tracked at bug 222687. Regards

*** This bug has been marked as a duplicate of bug 222687 ***

i do not agree that this bug should be merged with 222678.
222678 applied to kubuntu and to versions of 4.x, not 4.4.1 snapshots.
The search in dolphin worked fine until the update to 4.4.1+svn1105657-0rc1, which means it was fine in the official debian 4.3.4 packages as in all snapshots of 4.4.1 before svn1105657-0rc1.
I dont see its the same bug or maybe its back again.
btw: shared-desktop-ontologies is installed.
i will be happy to help debugging. let me know what you need.

Looking at the issue further showed that shared-desktop-ontologies 0.3-1 (thanks to MoDax for uploading) fixed it for some users that had the same problem. It did not for me.

What kind of files are you expecting as results? Could you please give a few examples.

i tried all kinds of things.
my settings for indexing are: /home (with a few excludes)
it should contail all mails, chatlogs pdfs and a lot of files.
the index is 412 mb big and holds 10461 entries.
i just did a clean reboot, checked nepomuk and akonadi settings, all was fine, no errors shown.
i leave the option in dolphin search as default.
entering the name of some pdf files like brief, rollup, resume puts a search URL (like posted in the initial bug report) in the field and immediately says: 'No Elements found' there is no searchbar. even very common searchterms like 'linux' or my name, where there should be hundreds of hits shows no searchbar at all.
i also tried names of directories in my home or words like 'pdf' or 'log' or 'txt'
they all return 'No Elements found'  immediately. 
so it seems to me the index is not even queried

probably connected to this:
after a reboot to my understanding nepomuksearch should go over the files marked for indexing fast, and, if it finds no changes, quit itself. thats what it used to do in 4.3.4. now, after reboot and no changes at all to the files to be indexed it starts running, but instead of going thru the files it says: 'Strigi indiziert gerade Dateien im Ordner' (strigi is indexing data in the dir) and of course there is no changes to index size or file count.

The info message is the same during initial check even if no files are actually indexed and the indexer simply checks for new files. So that is OK.

As for the query results: please try the following on the command line:

sopranocmd --dbus org.kde.NepomukStorage --model main query "select ?r where { ?r ?p ?o . ?o bif:contains 'linux' . } LIMIT 5"

and let me know the result.

ok, i just remembered it going through the files really fast and visibly and be done in a minute or 2. now it just sits there for a long time, at least 1 hour and more.
for your searchstring:
$ sopranocmd --dbus org.kde.NepomukStorage --model main query "select ?r where {
?r ?p ?o . ?o bif:contains 'linux' . } LIMIT 5"
Total results: 0
Execution time: 00:00:00.18

The index service is idling and that is ok. It will never terminate.

Could you please also run this command:

sopranocmd --dbus org.kde.NepomukStorage --model main --nrl query "select ?r where { ?r a nfo:FileDataObject . } limit 5"

$ sopranocmd --dbus org.kde.NepomukStorage --model main --nrl query "select ?r
> where { ?r a nfo:FileDataObject . } limit 5"
r -> (empty)
r -> (empty)
r -> (empty)
r -> (empty)
r -> (empty)
Total results: 5
Execution time: 00:00:00.9

That is really bad. Now we need to do more advanced stuff:

First get the port used by Nepomuk as follows:

"ps aux|grep virtuoso"

this will give you the tmp file that is used as config file. Opening that you will see some config entries, one of them being something like:

ServerPort=1125

Use the value instead of PORT in the following command, please:

echo "sparql select ?r where { ?r a <http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#FileDataObject> . } limit 5;"|isql localhost:PORT dba dba

I have the same problem. And this is what I get with the last command (I have used isql-vt instead of isql):


jcromero@hipatia:~$ echo "sparql select ?r where { ?r a <http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#FileDataObject> . } limit 5;" | isql-vt localhost:1111 dba dba
Connected to OpenLink Virtuoso
Driver: 06.01.3126 OpenLink Virtuoso ODBC Driver
OpenLink Interactive SQL (Virtuoso), version 0.9849b.
Type HELP; for help and EXIT; to exit.
SQL> r
VARCHAR
_______________________________________________________________________________

NULL
NULL
NULL
NULL
NULL

5 Rows. -- 112 msec.

This turned out to be a bug in the latest virtuoso packages on Debian (yes, this bug is entirely specific to Debian). I won't get into details but if you get similar reports about "search used to work in 4.4.1 but gives no results in 4.4.1+svn or 4.4.2" from Debian users, just merge them with this bug. It was just a coincidence that new broken virtuoso packages have been uploaded almost at the same time as newer snapshots from the 4.4 branch. The problem can be identified by running the following command and it failing with the error similar to below:

$ echo 'sparql select * where { ?a ?b ?c } limit 5;' | isql-vt
OpenLink Interactive SQL (Virtuoso), version 0.9849b.
Type HELP; for help and EXIT; to exit.
SQL> sparql select * where { ?a ?b ?c } limit 5;
Connected to OpenLink Virtuoso
Driver: 06.01.3126 OpenLink Virtuoso ODBC Driver

*** Error RDFXX: [Virtuoso Driver][Virtuoso Server].....: IRI ID 381 does not match any known IRI in __rdf_sqlval_of_obj()
at line 1 of Top-Level:
sparql select * where { ?a ?b ?c } limit 5