Unrelated subtitle tracks picked in autodetection

VLC 1.1.10 git - 2011-05-13 0203 on Win XP SP3

Open an .avi file with VLC, go on Tools => Codec Information and note what there is.

Now rename the file to "_.avi", open it again with VLC and go on Tools => Codec Information.

Now you will see one (or more) additional subtitle tracks.

If in the same folder there are subtitles and you name the file "_________.avi" it pick all of them.

changed title from Ghost subtitle tracks based on filename to Unrelated subtitle tracks picked

VLC only matches ASCII letters and digits, I believe...

I'm not sure what would be the best behaviour but I think that probably would be better to not load anything rather than load everything in case of missing ASCII letters and digits.

assigned to @jbk

added Component::Subtitles label

See also https://bugs.launchpad.net/vlc/+bug/711925

changed title from Unrelated subtitle tracks picked to Unrelated subtitle tracks picked in autodetection

Should be fixed in 3.

added Status::fixed label

changed milestone to %3.0 FF

closed

Milestone renamed

mentioned in issue #6406 (closed)

I know it's been a while since there was any activity on this, but I don't think it is fixed in version 3, at least not on the Windows platform.

Issue #6406 (closed) is probably a better match for what I just ran into. (is marked as duplicate of this one) If filenames contain only non-ASCII characters, there will be mismatches when trying to autodetect subtitles.

The reason for this is that the function subtitles_Detect() tries to trim filenames for fuzzy dectection. The trim function filename_trim_inplace() will remove any non-alphanumeric chars (!isalnum()), so in the case of non-ASCII chars, it will probably end up with an empty string. That means, comparing two filenames which only contain non-ASCII chars will always match.

I'm not sure how to properly fix this, without breaking existing behaviour that some people may rely on. Maybe it would be better to blacklist certain chars that should be ignored for comparison instead of whitelisting alphanum chars. Or somehow detect that there are non-ASCII characters in the filename and only do non-fuzzy detection in this case.

mentioned in issue #25893