VLSub not automatically loading subs

[gorecki3]

Is this a new report?

Yes

System Info

Void 6.3.12_1 x86_64 GenuineIntel uptodate FF

Package(s) Affected

vlc-3.0.18_3

Does a report exist for this bug with the project's home (upstream) and/or another distro?

No response

Expected behaviour

selected subtitle should automatically be loaded

Actual behaviour

vlsub gets stuck whilst saving subtitles, previous versions of vlc used to have issues with vlsub but i checked the same versions vlc-3.0.18_3 with vlsub 0.11.1 on other distros and this doesn't happen, I wasn't able to figure out how to debug or get a log of vlsub

Steps to reproduce

1. install vlc
2. load a movie
3. click on View -> vlsub
4. search by hash
5. click on any sub
6. download selection

[gorecki3]

i would like to know if I'm the only one facing this problem

[TeusLollo]

I'm not a VLSub user, but:

1) Is this the issue you're facing?: https://reddit.com/r/VLC/comments/phwhau/vlsub_0111_not_working/

2) In the same thread, user Radio-Lisboa suggests the following:

opensubtitles API has changed its request format from XML to JSON only. In adiction it also needs a session token to validate requests. So, in a few words, VLSub needs a re-work to replace the old function, to call the API with a valid token and process JSON data

EDIT: But, there's a workarround for this. As the previous version of opensubtitles is still working, you can edit your system hosts file to route VLSub call as XML. The default path of the hosts file in Windows 10 appears to be C:WindowsSystem32driversetc and you have to open your text editor as admin to edit the file. Add a new line and type 104.25.132.104 api.opensubtitles.org Save hosts file and try VLSub again. NOTE: This is valid while XML service is active in the old API address

Of course, this workaround was meant for windows. Maybe other distros have applied patches on their own, which is why VLSub fails on Void Linux?

3) Where did you get vlsub 0.11.1? https://github.com/exebetche/vlsub is stuck at 0.10.2, and https://addons.videolan.org/p/1154045/ is at 0.10.0. I could find a pull for 0.11.0 at https://github.com/exebetche/vlsub/pull/223/files but it went unmerged.

[gorecki3]

Is this the issue you're facing?: https://reddit.com/r/VLC/comments/phwhau/vlsub_0111_not_working/

Yes

Of course, this workaround was meant for windows. Maybe other distros have applied patches on their own, which is why VLSub fails on Void Linux?

oh good point, i forgot about that.

Where did you get vlsub 0.11.1?

i simply installed Vlc, it comes with vlsub.

i have also tried different versions of vlsub on void linux but none of them worked, but I'll see if i can find a workaround, thank you for replying

[TeusLollo]

This whole situation seems a mess:

VLSub has been historically unstable: https://code.videolan.org/videolan/vlc/-/issues/22747 https://code.videolan.org/videolan/vlc/-/issues/25337

Yet, in the present time: https://code.videolan.org/videolan/vlc/-/issues/17724#note_223578

It seems that upstream VLSub development and maintenance stopped in 2017: the last commit on https://github.com/exebetche/vlsub dates from April 2017, https://addons.videolan.org/p/1154045/ was last updated in September 2017, and since then github issues and pull requests are not processed anymore. So I guess this simplifies our options. To wrap this up, I think we should:

close any trac ticket that was fixed upstream, merging any needed patch from there review the diff and rebase our in-tree changes on top of the final upstream version, or merge anything that should be review any open (or self-closed) upstream pull request or issue since 2017 for valuable fixes and contributions, and pick them up migrate any important open upstream issue to trac, and crosslink tickets find a way (maybe a big open issue in all capitals) on the upstream github and the addons.videolan.org page, to advise users that those versions are discontinued there, and inviting them to report issues and contributions to trac

The git log suggests that Hugo has been a maintainer for the in-tree VLSub, thus I'm reassigning so this has more chances to be in the right hands.

And, in fact: https://code.videolan.org/videolan/vlc/-/issues/27168 https://code.videolan.org/videolan/vlc/-/issues/27168#note_337034

OpenSubtitles.org API important dates:

2022-06-15 registration of new user agents is stopped 2023-12-31 end of life, API endpoint will be turned off

https://code.videolan.org/videolan/vlc/-/issues/27168#note_379616

well, the EOL of the old API is nearing and they started adding warnings into subtitle files downloaded via the API. I am a heavy user of this plug in, both on my AndroidTV streamer as well as the Linux desktop version. It has other bugs as well and needs a rewrite anyway, I suppose.

So, what happened was:

1) VLSub ceased development and went unmaintained in 2017 (Check also my post at https://github.com/void-linux/void-packages/issues/45045#issuecomment-1636778878) 2) Upstream tried their hand at integrating the plugin into their own codebase, yet results were mixed, and the thing was mostly treated as a matter of scarce importance. 3) Now, given what's said at https://code.videolan.org/videolan/vlc/-/issues/27168, opensubtitles.com is changing their own API, which would render this plugin, already half-functional, completely useless. 4) Upstream should thus update/rewrite the plugin, yet they don't know if/when they will do it.

What I'm guessing happened is as follows:

1) The VLSub is already notoriously bugged, I've read of issues going back and fort between multiple VLC versions.

2) @gorecki3 eventually tried his hand at VLSub on Void Linux, yet it was past the date 2022-06-15, when "registration of new user agents is stopped". Thus, he did not have a cached user agent, compared to other linux distros he tried previously, which, I presume, were deployed before 2022-06-15, thus had the time to do "registration of new user agents" before 2022-06-15.

3) I'm speculating here, but, since the plugin did not have an user agent cached, and the website opensubtitles.com had stopped allowing registration of those since 2022-06-15, VLSub simply fails silently since it can't login to opensubtitles.com (This happens in anticipation of opensubtitles.com switching APIs)

4) All of this is null anyway, because "the EOL of the old API is nearing and they started adding warnings into subtitle files downloaded via the API. I am a heavy user of this plug in, both on my AndroidTV streamer as well as the Linux desktop version. It has other bugs as well and needs a rewrite anyway, I suppose"

Since @gorecki3 can't get a hold of the log, we can't confirm my "cached user agent" theory.

What he could do, instead, would be to deploy another linux distro (Clean state, absolutely no files imported from anywhere else) which he knows previously worked, and see if VLSub works. If it fails like on Void Linux, it may indeed be that "registration of new user agents is stopped" and thus, without a cached user agent, it can't work.

But even if it would work (Due to some pre-configuration stuff, or some other distro-specific privilege depending on how authentication of those user agents works), it wouldn't matter, since the API will be switched-off by the end of the current year, pending a plugin rewrite by VLC upstream devs, or anyone else who may volunteer.

This matter really should be brought to VLC upstream developers, who are aware of this at https://code.videolan.org/videolan/vlc/-/issues/27168, besides that, I stated my "cached user agent" theory, which may or may not be correct. But, even if incorrect, it wouldn't matter for long, since the plugin will need a rewrite once opensubtitles.com switches APIs anyway by the end of the year.

This doesn't seem a Void Linux problem per se. Of course, I'm not a developer, those are just my two cents on the matter.

[gorecki3]

Thus, he did not have a cached user agent, compared to other linux distros he tried previously, which, I presume, were deployed before 2022-06-15, thus had the time to do "registration of new user agents" before 2022-06-15.

Apologies if I misunderstood, but when you mention "registration," are you referring to the creation of an account? Because as far as I know, I didn't have one.

What he could do, instead, would be to deploy another linux distro (Clean state, absolutely no files imported from anywhere else) which he knows previously worked, and see if VLSub works. If it fails like on Void Linux, it may indeed be that "registration of new user agents is stopped" and thus, without a cached user agent, it can't work.

I will attempt to do that. Currently, I have an installation of MX Linux 'Wildflower' on a persistent USB drive where vlsub does work. Later, I plan to create a virtual machine and verify if it functions properly on it.

By the way, I must commend you on your excellent and thorough analysis of the entire situation.

[TeusLollo]

Apologies if I misunderstood, but when you mention "registration," are you referring to the creation of an account? Because as far as I know, I didn't have one.

No. In web contexts, an "user agent" is usually a client-embedded UTF-based string, that provides servers with variable information which may be useful. For example, a common web browser has an user agent (Ever wondered how some websites know exactly which browser and which version thereof you're using? That's the user agent providing infos), but many other application-layer programs also have those "user agents".

In this case, it seems to me that VLSub uses an unique "user agent" which is registered upon first usage, and then cached, and which is utilized to have opensubtitles.com provide its services (In this case, downloading subtitles. I guess they set it up like this to prevent abuse).

Since they have recently stopped registering new user agents, that may be why recently-deployed VLSub plugins don't work anymore, but older ones do (Because those could register themselves before such registering services were terminated).

Or at least I guess that's what's happening.

In every case it won't matter in the long run, because VLSub will need to be rewritten to accommodate what those at opensubtitles.com are doing.

Basically thus, unless VLC developers rewrite VLSub by the end of the year, VLSub will completely stop functioning by 2023-12-31 as by:

https://code.videolan.org/videolan/vlc/-/issues/27168#note_337034 OpenSubtitles.org API important dates: 2022-06-15 registration of new user agents is stopped 2023-12-31 end of life, API endpoint will be turned off

EDIT: Spelling

[gorecki3]

Apologies for the confusion, I have just realized that I mistakenly identified the version number of my VLC. It appears that the version of VLC on my other Linux distribution was not up-to-date compared to the one on Void Linux. In my MX Linux installation, I have VLC version 3.0.16 and VLsub 0.11.1, and everything functions correctly there. Hence, it is plausible that the lack of response from VLsub could be attributed to VLC version 3.0.18.

Considering this, it is possible that this observation undermines the validity of the user agent theory.

As you mentioned before, this will not have a significant impact in the long run anyways. However, I want to highlight that I was able to successfully install VLC through the flatpak version, and VLsub works flawlessly on Void Linux. This could be useful for those who still wish to have the ability to obtain subtitles automatically at least for the time being.

[gorecki3]

Hence, it is plausible that the lack of response from VLsub could be attributed to VLC version 3.0.18.

Actually even the flatpak version of VLC, which is also 3.0.18, works fine with VLsub, it becomes unclear what might be causing the issue with the package version on Void Linux.

[TeusLollo]

Actually, vlc 3.0.18 introduced further bugs: https://forum.videolan.org/viewtopic.php?f=13&p=537318, but I digress.

Still, it appears that VLsub does in fact store credentials in plain-text at vlc\lua\extensions\userdata\vlsub\vlsub_conf.xml

It's even been brought up as a security concern: https://code.videolan.org/videolan/vlc/-/issues/27701 https://code.videolan.org/videolan/vlc/-/issues/27702

And, in fact, recently: https://forum.videolan.org/viewtopic.php?p=534299#p534299

Buried deepin the reply above is the clue. Opensubtitles.org now, as of just recently, requires an account to use the VLsub code.

1 - go to opensubtitles.org and create an account. You have to cough up a working email address. 2- find the confirmation email in that account and click the link. 3- open VLC and the VLsub under View. You'll see a "configuration" button. Put your shiny new opensubtitles account in there and vlsub will work again. 4- accept that another nefarious link to you has been forged...

The post above is dated January 2023.

So, there is indeed an "user agent", with full-on login credentials to booth, which seems to have been introduced in the current year.

So, @gorecki3 , could you check a working VLsub install at vlc\lua\extensions\userdata\vlsub\vlsub_conf.xml, and then compare it with a non-working VLsub install always at vlc\lua\extensions\userdata\vlsub\vlsub_conf.xml?

It would be interesting to know what differences vlsub_conf.xml exhibits between a working and non-working version.

You did in fact mention not to have an account to opensubtitles.com, so I wonder if the working install with vlc 3.0.16 ships with pre-config at vlc\lua\extensions\userdata\vlsub\vlsub_conf.xml.

Since they mention that "Opensubtitles.org now, as of just recently, requires an account to use the VLsub code.", maybe they also check vlc version, and do not in fact require login credentials if they see that vlc version if < 3.0.18?

It would make sense, since debian-based distros take quite a while to update, and if they require login credentials only with 3.0.18+, they avoid breaking functionality for most debian users before their repositories update.

[gorecki3]

@TeusLollo , I compared the vlsub_conf.xml file from the flatpak installation of VLC 3.0.18 and the vlsub_conf.xml file from the package installation of VLC 3.0.18 on Void Linux using the "diff" command, and there was no output. Both files are identical and have no differences.

[TeusLollo]

@gorecki3 Well, this is getting insane. I think I'm going to need some help.

@Johnnynator Excuse me for pinging, mister, I think that, since you're the last to have committed to vlc, you may be able to help. Could you please read this thread, and help us with a solution (If any are possible)? I have exhausted my ideas here, and I don't think to have been superficial.
Thanks in advance and sorry for bothering.