Previously, TtmlConverter.process() caught all exceptions during TTML
to SRT conversion and returned opaque error codes (1 for IOException,
8 for other exceptions). These error codes were then wrapped by
Postprocessing.run() into a generic RuntimeException with the message
'post-processing algorithm returned N', losing the original exception
and its stack trace.
This made it impossible for users and developers to diagnose the root
cause of subtitle download failures, as reported in #13206.
Now, IOExceptions are re-thrown directly, and other exceptions are
wrapped in an IOException with the original exception as the cause.
This allows DownloadMission.doPostprocessing() to properly catch and
report the actual error, including the full stack trace in the crash
report.
Fixes#13206
Signed-off-by: pierreeurope <pierre.europe@pm.me>
- Use early return in case of nulls
- Use better variable names
- Remove non-required newlines, imports and add missing ones
Signed-off-by: Aayush Gupta <aayushgupta219@gmail.com>
It no longer really builds any view and used only for stroing click
gesture callbacks. In the same way lik local/LocalItemBuilder does
Last usage of build functions: 93d12e5bf0
This allows disabling these track types when stream info has been not
loaded while the ExoPlayer instance is.
It is now possible to do so with the background player, in order to
disable fetching video and text tracks for manifest sources,
especially used for livestreams.
Also set the recovery first before reloading play queue manager in the
useVideoAndSubtitles method of the Player class.
This partially reverts commit c31ae95f1f, which was needed to fix ghost notifications. There I broke the "cycle" causing the useless notifications to popup in 2 different places (see points 3 and 4 of the commit description).
However, breaking the cycle in point 4 ("`PlayerHolder::tryBindIfNeeded()` is now used to passively try to bind, instead of `PlayerHolder::startService()`" was not correct, for the following reason.
I assumed that `ACTION_PLAYER_STARTED` was used for notifying that the player was instantiated anew, while it actually is used to notify that something is now ready for use: it could be the player, but it could also just be that the bottom sheet view was just added and thus the VideoDetailFragment needs to start the player.
Therefore, when handling `ACTION_PLAYER_STARTED` it is correct to start the player service and not just try to bind to it.
The other point in which I broke the cycle (point 3) should still prevent ghost notifications, although I could not test.