You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Possible bug: In versions of AntennaPod including today's release 2.4.0f, a change to a feed's URL may be lost after first subsequent feed refresh.
Example: Tap 'Subscriptions' > choose podcast > tap circled i (info) > tap three dots > tap 'Edit feed URL' > change 'http' to 'https' and save (tap 'OK' then 'OK'). After subsequent successful feed/queue/subscription refresh, 'https' changes back to 'http'.
Specific reproducible example: For the podcast 'Congressional Dish', the URL is 'http://congressionaldish.libsyn.com/rss', but if outbound port 80 is blocked in favor of 443 then https is preferred and in fact necessary; the podcast does not refresh successfully if http. But refresh, download, etc., succeeds (once) after changing to https. Unfortunately, after this success, the feed URL is found to have reverted to 'http' not 'https'. So apparently something in the refresh/update can cause the user's change to be lost or overwritten.
The text was updated successfully, but these errors were encountered:
Possible bug: In versions of AntennaPod including today's release 2.4.0f, a change to a feed's URL may be lost after first subsequent feed refresh.
Example: Tap 'Subscriptions' > choose podcast > tap circled i (info) > tap three dots > tap 'Edit feed URL' > change 'http' to 'https' and save (tap 'OK' then 'OK'). After subsequent successful feed/queue/subscription refresh, 'https' changes back to 'http'.
Specific reproducible example: For the podcast 'Congressional Dish', the URL is 'http://congressionaldish.libsyn.com/rss', but if outbound port 80 is blocked in favor of 443 then https is preferred and in fact necessary; the podcast does not refresh successfully if http. But refresh, download, etc., succeeds (once) after changing to https. Unfortunately, after this success, the feed URL is found to have reverted to 'http' not 'https'. So apparently something in the refresh/update can cause the user's change to be lost or overwritten.
The text was updated successfully, but these errors were encountered: