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.