This bug has been around literally for years. It's a resolved upstream-upstream bug insofar as the VLSub.lua bundled with vlc-2.2.4 tarball is old and has problems but the upstream-upstream bleeding-edge vlsub.lua works much better and despite the wierd capitalization change is suitable as a drop-in replacement: https://github.com/exebetche/vlsub/blob/dcb7eaae4837a7d53b903a3b09acc2b01a09e099/vlsub.lua Attached patch "backports" this revision into the 2.2.4-r1 vlc source tree unpacked by portage. I chose this revision, the un-relased head of the vlsub master branch, because, as I investigated, I came across (but did not verify) several reports that the HTTP 1.1 change in the tip commit above happens to be important for some users (something to do with Cloudflare, they said, iirc). Anyhow, since we seem to be staying here on 2.2.4 for a while -- and since, for that matter, it's not known to me whether vlc has even updated the vendored VLSub.lua in their own git (assuming that's how it gets there). So, i.e., =media-video/vlc-9999 might well, or, equally, might well not, still suffer from this same problem, and, for all I know, still respond positively to the same medicine. Anyhow it fixes this longstanding bug for me and a couple other people out there on github
Created attachment 468618 [details, diff] vlsub-fix.patch oops, forgot the patch. One other note -- this is not /exactly/ upstreams version -- I change the value of the shortdesc variable to "Download Subtitles" on line 73 because vlc puts this value into its menus. Since vlc developers have presumably chosen to put the option to download subtitles in the most counter-intuitive place they could think of, having the menu item text change from "Download Subtitles" to "VLSub" would represent a an unacceptable regression as only a dev would ever know what that means.
I have no issues with vlcsub plugin and current vlc versions
