I have found a bit of a problem with the "SearchSubtitles" xmlrpc method when searching by name. I'll try to explain:
As we all know searching by hash works. Has worked for years now.
Not long ago additional search mechanisms were implemented. They allow greater flexibility when a hash is not present (and make it easier to download unhashed subs and reupload the hash matches.
One of the new search criteria implemented was "by IMDB", which usually implies searching (via CheckMovieHash, for example) for a proper IMDBID to use. It works well too.
Then there is the "search by fulltext" which searches using the filename (usually) or a user-input text.
And that's when I have problems.
See, there's no way to link results to the originating files.
Imagine I have a file:
leolo.avi
It searches by fulltext and comes back with a subtitle result entry. SubtitleID 3299027 which lists movie as Léolo.
Now, this causes a problem, since there's no way to match the result to the original query automatically. In a normal search you'd have the hash and in an IMDB search you'd have, well, the IMDB ID.
In a fulltext search you can't map the results since there's no field that matches the original query.
So, the search only works in one-by-one searches until it's fixed.
How to fix it?
Including the original $query in the results for fulltext search.
Alternative solution:
Provide a CheckMovieName that searches for IMDB IDs based on fulltext using the subtitle names and movie names uploaded as well as a query name. Provide one or multiple results (in a similar way CheckMovie and CheckMovie2 currently work with SeenCount) and obtain IMDB IDs for them. Then use THAT for searching.
I wanted to avoid doing per-file SearchSubtitles since it's slower and it's a bigger hit to the database.
Of course, this doesn't cover TV Series support, which really should have its own method to stop SearchSubtitles growing even more.
Lastly: I was going to ask you to consider adding search arrays to searchsubtitles, so I didn't have to do three searches as I do right now. Then I realized this would probably be some effort and wouldn't be used by most.