According to the Android documentation, if onPlayFromSearch is called with an empty query, the app should make a decision what to play. Before, a database search with this empty query was performed, which returned arbitrary results. Now we play the last played episode instead.
Merging #6074 has caused a new edge case for VBR audio files, in which
using the seek bar to seek to the end of an episode sometimes hits the
new code path, and the `skip()` function is called.
Because `skip()` invokes `endPlayback()` with `hasEnded` set to `false`,
post-processing tasks are not executed unless the pre-seek position
falls within the "Smart mark as played" range. If "Smart mark as played"
is set to `Disabled`, or the pre-seek position is outside that range,
then the episode is not marked as played, and not removed from queue.
This commit fixes that edge case by replacing `skip()` with a direct
call to `endPlayback()`, with `hasEnded` set to `true`.
The bug is on this line [#145](f7a13065a9/core/src/main/java/de/danoeh/antennapod/core/storage/DBWriter.java (L145)) - the call to `PlaybackPreferences.getCurrentlyPlayingFeedMediaId()` returns the episode that was playing and deleted, hence it stops playing the next episode like it is supposed to. Because it's called in a Thread, the next episode already started playing for 1 second or so and then stops
The fix will now save into the preference the correct episode that is playing on the PREPARE stage.
- Support showing most error messages as a snackbar
- Ask for notification permission when enabling episode notifications
- Clarify what we use notifications for
When using variable speed, skipping back and forth introduces some
uncertainty to the current position, causing skip-forward to try to skip
to an invalid position when very near the end of the episode. This
change fixes this by skipping the current episode if the desired
skip-forward position exceeds the duration.
WorkManager does not tell us whether it was cancelled by
the user (not retried) or by the system (retried later).
So we need to delete the file and remove from queue when
we know that it was actually the user. Also make sure
to always delete the file when the download fails.
Also, don't show "will retry" message on last retry attempt.
