VLSub 9.13 HTTP time-outs

When i try to search for subtitles moments later ,appears a message asking to kill the extension and colse vlc,When i try open vlc apears saying that vlc just crash do you want to report.

Log files informations

Added attachment:

• log

The related forum discussion: https://forum.videolan.org/viewtopic.php?f=14&t=136182#p449683

The Extension needs more time. Please consider disabling the buggy Watch timer in /modules/lua/extension.c. It could be a simple solution.

Can you explain step by step how to disable watch timer?

Sorry, it is just a suggestion for some VLC developer reading this ticket and willing to look at the case.

Ok thanks i apreciate it,i will wait for future solutions.

Mederi bro i just try the tip from the link you give to me,and works if i wait a while like a minute +- it works fine,this has to be a bug,but i need a better solution to this problem.

Replying to [comment:1 mederi]:

The related forum discussion: https://forum.videolan.org/viewtopic.php?f=14&t=136182#p449683

The Extension needs more time. Please consider disabling the buggy Watch timer in /modules/lua/extension.c. It could be a simple solution.

What makes you think that the watchdog is buggy? It rather looks like it is working and the extension is taking an inordinate amount of time. Don't shoot the messenger; don't remove the canary: Fix the extension.

assigned to @linkfanel

Yeah and indeed it is a bug in VLSub. The HTTP code there was written with two left hands, and it broke after some server-side updates of OpenSubtitles.org.

changed title from Vlc sub 9.13 extension kill to VLSub 9.13 HTTP time-outs

added Component::LUA scripts label

I don't do lua extensions.

Replying to [comment:8 linkfanel]:

I don't do lua extensions.

Trac automatically assigns unassigned bugs to you when the component is changed to "Lua scrits". Nothing personal. You are free to deassign bugs.

unassigned @linkfanel

I know.

Replying to [comment:6 courmisch]:

What makes you think that the watchdog is buggy? It rather looks like it is working and the extension is taking an inordinate amount of time. Don't shoot the messenger; don't remove the canary: Fix the extension. Users report their new experience with "Extension not responding!" dialog box: click "Yes" > VLC crash / wait over a minute > VLSub results.

When the watchdog dialog box appears (Extension not responding!), usually users think that the extension crashed and needs to be closed. Perhaps the message could contain information that this does not necessarily mean a crash and probably the extension just needs more time to finish its task.

Sometimes, if users click the "Yes" button in the watchdog dialog box, the whole VLC disappears. Then users need to open VLC again and sometimes the "VLC crash reporting" dialog box appers.

It seems that there is a problem in communication between VLSub and opensubtitles.org server at the moment, but the watchdog crashing problem is still there for all Extensions with calculations/operations taking long time. If users do not touch anything and just wait more than a minute, the watchdog dialog box disappears and results appear in VLSub.

Added attachment:

• Watchdog dialog - VLC crash.png

Also #17566 (closed)

0001-lua-fix-VLSub-HTTP-timeouts-bug-17561.patch

Added attachment:

• 0001-lua-fix-VLSub-HTTP-timeouts-bug-17561.patch

I've got a quick fix for this bug (and one which does not imply to downgrade the HTTP header like in ticket 17566).

VLSub OpenSubtitles client rely upon the "Content-Length" header as a way to stop from receiving data. Problem here, OpenSubtitles use CloudFlare as CDN and always return gzipp'ed response with a "X-Uncompressed-Content-Length" header filled out. Since "contentLength" var is set to nil, there is here a infinite loop on polling which ends up freezing the extension.

The dirty way to fix the timeout problem is to look for both headers, while the correct way is to implement a reliable http client as well as a reliable xmlrpc library.

The root cause of the bug is that VLSub does not handle chunked Transfer-Encoding, even though it is required in HTTP version 1.1. It also fails to handle 1xx intermediate responses, which OpenSubtitles.org luckily has not been sending so far.

Of course, the real problems are:

1. The VLSub author ostensibly does not care to implement the protocol properly.

2. The merge of VLSub in VLC bypassed the normal code review process 3.5 years ago. Otherwise, those issues could have been flagged before they caused problems.

Combine the two, and you get this user support disaster. To make matters worse, VLSub also does not send a version number. So OpenSubtitles.org could not detect and work around the bug even if it wanted to. (Oh, and upstream VLSub sends the version in syntactically invalid form! It never ceases to amaze me how badly coded this extension is.)

Regardless, as far as I can tell, the patch above comment:13 does not make any sense. Parsing the proprietary CloudFare header line will not magically undo the encoding, and maybe not find the correct end of the response body either.

The only part of that comment that I would agree with, is the last subordinate:

The correct [solution] is to implement a reliable HTTP client as well as a reliable XML-RPC library. But then again, there should really be a proper common HTTP POST implementation in VLC.

My bad : CloudFlare does send the response data as plaintext, but set headers to indicate there was a gzip operation involved somewhere ("X-Content-Encoding", "X-Uncompressed-Content-Length", "X-Compressed-Content-Length").

Example of a response :

HTTP/1.1 200 OK
Date: Sun, 13 Nov 2016 17:49:36 GMT
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=deb78d59c5bd7ab938859c7ff9bfad9321479059376; expires=Mon, 13-Nov-17 17:49:36 GMT; path=/; domain=.opensubtitles.org; HttpOnly
Set-Cookie: PHPSESSID=9nT1Ur6SXjX3x8hms9FWtPzbqRf; path=/; domain=.opensubtitles.org; HttpOnly
Download-Quota: 200
X-Content-Encoding: gzip
X-Uncompressed-Content-Length: 377
X-Compressed-Content-Length: 209
X-HTTP-Version: 1.0
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Origin,X-Requested-With,Content-Type,Accept,DNT,Keep-Alive,User-Agent,If-Modified-Since,Cache-Control
X-Cache-Backend: web3
Vary: Accept-Encoding
Age: 0
X-Cache: MISS
Server: cloudflare-nginx
CF-RAY: 30140facb1b33be1-CDG

179
<?xml version="1.0" encoding="utf-8"?><methodResponse><params><param><value><struct><member><name>token</name><value><string>9nT1Ur6SXjX3x8hms9FWtPzbqRf</string></value></member><member><name>status</name><value><string>200 OK</string></value></member><member><name>seconds</name><value><double>0.007</double></value></member></struct></value></param></params></methodResponse>

You can see the 0x179 starting the chunk match the 377 in X-Uncompressed-Content-Length. My workaround has a little arithmetic problem (the raw length of a chunked response is always greater than the content length) but it works since the client recv data by blocks of 1024 (or less).

added Severity::major label

added Status::fixed label

changed milestone to %3.0 FF

closed

Milestone renamed

mentioned in issue #17566 (closed)

mentioned in issue #17724