"More like this" view throws an error

You forgot to attach your view.
One thing you can try in any case, though, is whether this works with the current dev versions of Entity API, Search API and Search API Solr search.

Yes, for figuring out bugs this is always a good idea.

Your view works fine for me (at least after removing the display, which I haven't installed).

It doesn't even work in the preview, when you give it a valid NID as an argument?
In any case, I can't really help you there. As said, for me your view works fine with the dev versions.
Did you by any chance forget to update the schema.xml and solrconfig.xml files, or to restart Solr?

You could check the Solr log to see whether Solr receives a query, what that query returns, what could be wrong with it, etc.
Then you can debug in the Views query plugin or the argument handler (depending on the above) to see where this goes wrong.

A valid MLT Solr query looks like this:
mlt.fl=SOME_FIELDS&qt=mlt&fq=index_id:INDEX_MACHINE_NAME&wt=json&f.NON_TEXT_FIELD.mlt.minwl=0&rows=ROWS&start=0&q=id:INDEX_MACHINE_NAME-NID
(The f.NON_TEXT_FIELD.mlt.minwl=0 part for all non-fulltext fields.)

I had the same kind of errors on the nodes not yet indexed.

Notice : Trying to get property of non-object dans SearchApiSolrService->extractResults() (ligne 635 dans /var/www/blahblah/sites/all/modules/search_api_solr/service.inc).
Notice : Trying to get property of non-object dans SearchApiSolrService->extractResults() (ligne 639 dans /var/www/blahblah/sites/all/modules/search_api_solr/service.inc).
Warning : Invalid argument supplied for foreach() dans SearchApiSolrService->extractResults() (ligne 639 dans /var/www/blahblah/sites/all/modules/search_api_solr/service.inc).

I ditched my 3.5 install to go back to the 1.4.1 before realizing this :)
Probably a minor bug.

Thanks ethnovode - saved me a lot of trouble. I have 29,000 nodes so had started building MLT and other things before all nodes were indexed. Just in case anyone is googling for this same error:

You must index all your nodes before trying to build views / mlt block based on search_api / solr otherwise you will get the error message above

@gittosj: indeed, but if you're on a running website and the index is updated by cron, when you create a new node you will have this error until the index will be updated. Shouldn't this error be catched ?

Ah, thanks for clearing that up!
Attached is a patch which at least prevents the notices. However, we (of course) can't really do anything about Solr not returning any results. If this is a no-go for you, you'll have to activate "index items immediately" for the index.

Thanks for that and one more issue we should try to clear:

I'm using a couple of aggregated fields as a workaround for the issue of string / full text fields to feed data to both facets (strings) and search index (full-text). I think (!) that the MLT contextual filter works only on 'full text' fields.

However the MLT contextual filter seems to only pick up the first aggregated field created (which for me is a blob of addressfield fields such as city, country etc) which I create from the string fields used to generate facets. If I create a second aggregated field of any kind then it's ignored. Fiddling with these variables to try to find a further workaround left me with a borked index so I'm reluctant to test more to destruction!

Solutions:
Short-term: Can we make sure MLT filter picks up more than one aggregated field / newly created and altered ones?

Medium-Term: Is it possible to allow MLT matching on strings as well as to allow some concept of weighting? For example I'd love to be able to filter for any content in the same place / region / country and then (lower weighting) any content with similar taxonomy?

Thanks for all the great work - it really is powerful and I'm standing by to test a patch if you've time :)

So does the patch work for you?

The other seems like a different issue, and I think I'd need a more detailed description of what doesn't work. After adding the additional related fields, did you change the MLT filter settings to include those fields in the matching?
Regarding the medium-term solution, I don't know if this is possible.
In any case, please create a new issue for that!

Patch works perfectly and many thanks.

The issue with the MLT filter settings remains though - can't select more than the first aggregated field since they don't appear in the filter settings. Tried tweaking, deleting and recreating the view. Even deleted the index and recreated... weird...

I guess you also tried clearing the caches? I could imagine that might otherwise be a problem …
Although I'm pretty sure that Search API Views should take care of that.
Did you also mark the fields as indexed on the „Fields“ tab?

I can't reproduce this. In any case, as said, please create a new issue for that!

Regarding the original issue: committed, thanks for testing!

EDIT: ignore, turned out to be unrelated

I have this issue intermitently on node types whose pages have a "More like this" view.

The non-indexing and warnings are fine, my more serious problem is, when these warnings appear after saving the content (which isn't all the time and appears random), the field data for the content that was just saved is lost - it just has default data. For someone who's just filled in some content, this is naturally a big frustration...

Any ideas what might be causing this? Could this issue with Search API theoretically cause the field data to be lost, or is it more likely to be causality the other way round (some other issue causes the field data to be lost, then that causes this error?)

Thanks for fixing this, I had the same problem.

@drunkenmonkey; can you please add a new version of the module? The last release is already 7 months old.