DOCS/options: mention that sub-clear-on-seek can now break things

This is technically due to the previous commits that made subtitle
rendering more efficient by eliminating redraws, but working around this
particular edge case is useless. The sub-clear-on-seek option was
originally introduced in d5940fabcd6b477c72430c84e460975060807646 and
specifically is a workaround for completely broken mkv files. There is
no reason to use it otherwise. Because that option disables all
duplicate checking and the previous commits rework subtitle rendering in
the still image case to be dependent on keeping track of packets, the
end result is that you will get the same line rendered multiple times.
However the important case of broken mkv files with duplicate ReadOrder
fields still work just fine with --no-video. So instead of bothering
trying to make this option "work", just clarify that stuff can break
since, again, there's no reason to use it other than as a workaround for
broken files.

1 files changed, 3 insertions, 1 deletions

diff --git a/DOCS/man/options.rst b/DOCS/man/options.rst
index 65c90904c7..131319c9aa 100644
--- a/DOCS/man/options.rst
+++ b/DOCS/man/options.rst
@@ -2761,7 +2761,9 @@ Subtitles
     Matroska-style ASS subtitle packets. It should be unique, and libass
     uses it for fast elimination of duplicates. This option disables caching
     of subtitles across seeks, so after a seek libass can't eliminate subtitle
-    packets with the same ReadOrder as earlier packets.
+    packets with the same ReadOrder as earlier packets. Note that enabling this
+    option can result in broken subtitle behavior if you are not actually
+    playing one of the aforementioned broken mkv files.
 
 ``--teletext-page=<-1-999>``
     Select a teletext page number to decode.