Forum rules
Under no circumstances is spamming or advertising of any kind allowed. Do not post any abusive, obscene, vulgar, slanderous, hateful, threatening, sexually-orientated or any other material that may violate others security. Profanity or any kind of insolent behavior to other members (regardless of rank) will not be tolerated. Remember, what you don’t find offensive can be offensive to other members. Please treat each other with the kind of reverence you’d expect from other members.
Failure to comply with any of the above will result in users being banned without notice. If any further details are needed, contact: “The team” using the link at the bottom of the forum page. Thank you.
Posts: 3
Joined: Thu Aug 06, 2020 8:32 pm

XMLRPC API documentation issues

Thu Aug 06, 2020 8:43 pm

I am a developer on mpc-hc (clsid2 fork, the current active fork installed with klite codec pack). I have been trying to make an improvement to the subtitle search capability, and have run into some issues.

1. Documentation is inconsistent on trac: ... iki/XMLRPC

On this page, the api is defined for SearchSubtitles with parameters (including "tag"):

Code: Select all

array SearchSubtitles( $token, array(array('sublanguageid' => $sublanguageid, 'moviehash' => $moviehash, 'moviebytesize' => $moviesize, imdbid => $imdbid, query => 'movie name', "season" => 'season number', "episode" => 'episode number', 'tag' => tag ),array(...)), array('limit' => 500))

But at the top of the page, it suggests this link for better examples: ... mlRpcIntro

Code: Select all

struct SearchSubtitles(string $token, array(struct('sublanguageid' => string $sublanguageid, 'moviehash' => string $moviehash, 'moviebytesize' => int $moviesize, 'imdbid' => string $imdbid ), struct(...)))

Note the two signatures are different, leading to possible confusion. This leads me to #2.

2. It seems tag search support is silently disabled, and just doesn't work.

I found a post from 2018 or 2019 saying it was disabled for performance reasons. It took me a while to find that post. Yet, the documentation states nothing about that. With two distinct signatures on the trac pages, it's enough to make you wonder if the "tag" doesn't belong in the api any longer--or are you just using it wrong? Yet, the page that mentions "tag" search is actually updated more recently.

As for performance reasons, the result of disabling tag support is, I can no longer do video filename search. This forces me to use "query" instead, and then filter the results. That must be a bigger performance hit than just searching by tag, right? Even with an exact filename, the first result is usually the right one, but is followed by 499 "close" results that I just throw away.

Is there any hope for a strict filename search, or return of tag search? It makes me sad to do such an inefficient query just because of nebulous "performance" concerns.

User avatar
Site Admin
Posts: 5008
Joined: Sat Feb 25, 2006 11:26 pm
Contact: Website

Re: XMLRPC API documentation issues

Fri Aug 07, 2020 5:33 am

well we disabled tag for performance reasons and it stays like that, maybe I can enable it again and see how it goes. The problem with tag is we have to index more than 72.000.000 tags (1 subtitle file can have many movie file and they can have multiple movie names)

I understand this is quite frustrating, lets hope in new REST API this will works better.

Posts: 3
Joined: Thu Aug 06, 2020 8:32 pm

Re: XMLRPC API documentation issues

Fri Aug 07, 2020 11:07 pm

What if you just add "filename" search and only index filenames vs. all the other kinds of tags?

Or queryexact so it doesn't match a bunch of close things?

Posts: 3
Joined: Thu Aug 06, 2020 8:32 pm

Re: XMLRPC API documentation issues

Sat Aug 08, 2020 2:50 am

I am not sure if my last reply was lost, or what. Seems like it disappeared?

What if we could do filename only search (and not any other tags)?

Or, for queryexact, require exact string match. The results seem to know when it's exact, so maybe a way to restrict to that.

One other idea is to index a hash of the filenames. I don't know how you are storing it, but if all records were a SHA-128 hash or something, a key lookup in a sql db should be very fast.

Return to “Programs using OS”

Who is online

Users browsing this forum: No registered users and 0 guests