AntennaPod is quite slow with huge feeds. The reason is that we have a bunch of workarounds for misbehaving feeds that also make it slower to work with feeds that do not misbehave.
Changes:
- Only start guessing duplicate episodes when no "proper" match is found
- Only parse non-html as HTML for attributes that really need it
- Do not log failed Long parsing when size is not specified
- Try to parse dates with RFC822 first before falling back to workarounds for other formats
I ran a benchmark with "Stuff you should know" (for which the workarounds are not needed) containing 2k episodes. Includes download of 8MB of feed XML (~5 seconds), debug build.
Before: 44 seconds, after: 13 seconds ==> 3.4 times faster feed refresh
This test regularly fails our CI.
The test checked that auto-download kicks in after the currently playing episode
and that it considers the correct item in the queue to enqueue after.
However, because we now use WorkManager, the download can be delayed based
on decisions by the Android system. We cannot assume that downloading already
starts just seconds after playback completes.
I do not know an easy fix for this, and the test is quite complex anyway, testing
multiple different modules at once. So I am removing the test for now.
- Remove video-specific playback speed (no longer needed now that we have per-podcast speed)
- Respect changed speed setting on settings page even if the service is not running
- Do not change global speed when feed setting is updated
Chapter loading can sometimes get interrupted, most importantly if
the corresponding fragment tries to refresh the view again.
Before, this set the chapters to an empty list, indicating that it
should not be tried again. Now, interrupted exceptions do not set
the list to be empty, so it can be retried later.
ByteHamster
ByteHamster
Taco
Tony Tam