![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://beehaw.org/pictrs/image/1be75b15-2f18-429d-acf7-dcea8e512a4b.png)
That is a little of how I use it too - I have all podcasts set to download automatically globally (set it up to 25 episodes at the same time) and put them in my queue so I always have exactly 25 episodes to listen to in any order there each day.
Then there are 2 daily podcasts that I do not let automatically download (but automatically refresh, and I love that the app delineates between the two), however one regularly produces longer episodes including a lot of the shorter ones that I do let it automatically download. Huh, I never realized how advanced the setup actually is. Though I do remember the actual ‘setting up’ being relatively painless after getting to grips with the global/per-podcast difference.
Also, fwiw I have the synchronization set up using one of the self-hosted options instead of the default gpodder service - which is often down intermittently - and it works well enough, even if a bit slow every now and again.
Not all notifications go through FCM but all push notifications do as far as I’m aware - which is what the previous comment and the post title are talking about.
It is, in fact, worrying for privacy implications on the one hand and a real monopolizing factor on the other since if you wish to deliver an app which needs to implement such notifications you’re using Google’s service or constantly drain the user’s battery.
There’s UnifiedPush which tries to provide an open alternative but so far unfortunately still sees very little adoption.