[fixed] API SubDownloadLink doesn't work used as srt since a few minute/hours?

[vankasteelj]

Hi,

when talking to the API, I take the 'subdownloadlink' from XML-RPC and turn the .gz into a .srt

"http://dl.opensubtitles.org/en/download ... 5202406.gz" for example, I turn it into "http://dl.opensubtitles.org/en/download ... 202406.srt" and that allowed me to download the subtitle (mostly have a list of urls I could choose from, and download in a click without having to deal with the API)

That doesn't work anymore. The .gz link works, but if I try to download as .srt, it doesn't let me. It sends back a html page saying "incorrect download parameters" instead of the .srt

I can't really use DownloadSubtitle method as it, I need a list of direct links. Is this temporary? I could otherwise download the .gz and unzip it manually then with a little bit of code, but the .srt way was so convenient (and it had the ads within).

Let me know, thanks.

PS: here's what I use: https://github.com/vankasteelj/opensubt ... ch.js#L132 to turn .gz to .srt (or other, but mostly .srt)

[oss]

we change that part a bit. Normally it is either .gz or none. I can add failback to uncompressed file if not .gz (as it was before...)

[oss]

but it is better to fix it in your program, that it is using download link which is returned in API and not adding custom extensions...

is there any reason for to do it ?

[vankasteelj]

It is not custom extension, it's the extension sent by the api too

Basically, with the api, I recieve:

Code: Select all

response.data[0] -> { SubDownloadLink: "http://url.com/example_id.gz" SubFormat: "srt" }

I used to combine them to get 'http://url.com/example_id.srt' which can be used as direct link (used in the app to grab the subtitle with curl, XmlHttpRequest or such and use that stream directly in my player)

It's a convenience method. I know at least 10k people use it (and it stopped working yesterday: outch), so if you could re-enable the direct links (fallback, as you call it), that would be great.

What I can do myself, if you want, is to deprecate that method and issue a new version of my node wrapper, with .gz only links, so devs have to switch, then you can disable it again, idk, in a month maybe? So people can transition without breaking the flow :p or leave it activated like it used to be, you tell me what you prefer.

But as of now, many apps might just have stopped working (requiring an update for subs to get through).

Let me know how you want to procede : (A) if you want me to deprecate module and update forcing .gz, and you re-enable the fallback just the time of transition, (B) if you prefer re-enabling the fallback like it was before yesterday and I don't touch anything, (C) or if you prefer things just to be like they are today and those devs have to upgrade asap for opensubs to work again.

[oss]

I didnt know wrappers are using it like that, the thing is, on website is it without extension...

anyway I enabled it like it was before...so actually any extension which you will pass will return the file, gz will return for you gzipped file...

in API it returns something like

[SubDownloadLink] => http://dl.opensubtitles.org/en/download ... 3116803.gz

it is enough to remove ".gz" parameter to get the link (same as it is on website)

But this is cosmetic, and I fix it, it is not a big deal. I can even (and I will introduce that soon) send custom headers together with file.

[vankasteelj]

Great, i'll roll next update without any extension then, thanks for the tip! It all works good (as before, even faster it seems, idk if it's your modifications or the recent maintenance)

[oss]

Good. Btw soon we are going to release public API where one can do quite a lot of things with existing subtitles, retime by time, retime by fps, convert formats, convertt encoding...will write about public release here...