Hey guys, I’ve been using AntennaPod since Jan/26 and I can honestly say it is the best podcast player/manager out there, no doubt. I’m coming from PocketCast and CastBox and, aside from the web sync, I feel there ain’t nothing we had over those other players that we don’t have on this one, plus the added bonus of not having ads from the platform itself.
I’m a media hoarder, I consume a lot of YouTube and multiple news/tech/documentaries podcasts, and one thing that I had on YT that I missed here, a lot, was the option to manage multiple themed playlists/queues.
I’m no Java developer, I mostly work with JS and PHP (web based projects), but I decided to dig through the multi-queue status on the project, and found that we had multiple PRs not merged due to inconsistency, AI and lots of other issues.
As a new user I can’t post more than 2 links, sorry, but here are some of the things I’ve found:
- Multiple / User Definable Queues. Issue #2648
- (Very) WIP: Enable Multi-Queue support. PR #8070
- WIP: Multiple Named Queues - DO NOT USE - branch was dumped and reimplemented PR #8066
- WIP start dialog on multiple queues PR #3221
- Enqueue location by podcast PR #8215
- Improve database indexes for large libraries PR #8718
- Multiple queues. Conclusions: we like the UX approach of the agentic PR but should probably be implemented by a (skilled) human (to minimise the review overhead). Forum: needs-decision call #4169/34 @keunes
I know this has been a most asked feature and I’m sure it’s not up yet because there are a lot of problems to follow through before being able to deliver it, but out of curiosity I gave the task to Claude (I know, I’m sorry, hear me out though) with the following requirements:
- Keep all development work within code style and structure according to AntennaPod contribution docs: Code structure & Code style
- Respect what moderators have pointed out before, on other Issues and PRs, so that we have the best shot and least overhead on reviewing anything, including:
- Scope: @ByteHamster asked for a “dumb”, manual queues first (v1), then an MVP: no automation, no icon or color pickers, no experimental on/off switch. The objective is to build the groundwork to merge it without impacting current users, database, legacy apps and all else.
- Architecture: instead of building out database tables, extend the existing queue table, for ease of maintenance and compatibility. On PR #8066 he specifically asked for the existing DBReader/DBWriter to be used instead of a new repository layer (this was actually the reason PR #8070 was declined, from what I understood).
- UX: On PR #8070 switching queues is done on the same Queue screen users are already used to, and is stored in memory. “Add to queue” goes straight to the active queue, with no picker dialog. This works great because if the user never creates a new queue, nothing changes, and if users manage multiple queues, there is no extra step on adding an episode to the current “in use/active” queue.
- AI code: PR #8066 form seefood (great avatar, btw, love the show) was rejected largely because it looked AI-written without regard for the existing code, hard to read and thus lacking maintainability (I’m with you guys on this one, that’s why I asked Claude very nicely to keep within code style/structure and reviewed each phase manually).
- Documentation is key, every part of the implementation should be planned out on a ./Docs folder, documented and revisited once the phase was done, so any findings, issues or changes were to be documented, reasoned, reviewed and revisited as well.
- Do as minimal diff as possible to be able to keep up with the main AntennaPod repo’s future updates (in case this endeavor has the same fate as the others before it):
- New branch for each phase of the implementation, so that if it is partially accepted, we won’t loose all the work done, and easier to review as well.
- In each phase look for security issues, performance improvements and opportunities (reuse, simplify, etc), and design deviation (check for any previous implementations of classes, functions and styling from the Code Structure e Style guide).
From this, I forked the AntennaPod repo to my personal GitHub profile, Claude came up with a plan with 6 phases of implementation (I did actually create links for each phase docs and branch, but with the limitation I had to remove them…):
- Phase 1 - Storage layer: No user visible changes. App still behaves the same as previous versions and upstream, only the default queue still exists, but we do the groundwork to use multiple queues on the database, adding a small new table only to hold the new queues’ names.
- Each episode can live in only one queue, and the chosen queue is recorded in memory (as there are no UI changes, “default” queue is the chosen one, always).
- All compatible with main app and exported databases.
- Phase 2 - UI: added interface options to enable users to interact with database changes made on Phase 1:
- When clicking 3 dots and clicking to add a new queue on the Queue screen, a new chips row is added, showing available queues, and allowing users to select the active queue they want. Menu options are: “New”, “Rename” and “Delete” queue.
- Queue names should be, at most, 30 chars, and can’t be stored empty to avoid errors.
- Android Auto queue count and swipe actions for episodes in different queues.
- Phase 3 - Release builds: In order not to interfere with the main “develop” branch, created a “multiple-queues” branch to live as default on fork only.
- Every merge int to the branch builds an APK signed with my key and creates a release on the GitHub repo.
- This is supposed to help me use the app while not merged upstream to AntennaPod (which I know might never happen)
- Phase 4 - Upstream Sync: to keep up with AntennaPod upstream repo, a workflow fetches and merges (if no issues present) changes. If any conflicts, a PR is created labeled “upstream-sync” to list them and never merges automatically.
- Phase 5 - A queue per podcast: Here we branch out from the main PRs and issues known so far, and add an extra menu entry on podcast’s config menu, to allow user to select a default desired queue:
- New episodes add to that queue by default.
- Episodes queued, when finish their downloads, go to that queue.
- “Add to queue” manual action still lead the episode to the active queue, not the podcast’s config.
- Phase 6 - Queue picker: When selecting multiple episodes the user is presented with new option entries on the menu: “Add to queue” and “Move to queue”. These are only shown when more than one queue exists. It also enables the user to send episodes to any queue they want before switching to it and going to each podcasts feed first, which is specially helpful when coming from AntennaPod’s single queue and a large episode list (which is my case as well, I’m guilty).
Granted that phases #3 and #4 are only intended for this fork’s maintenance, and the Docs folder only exists to help anyone reviewing the code understand the reasoning behind any of the decisions implemented, but phases #1 and #2 are straight out of the research done, as asked by moderators and nothing else.
The fork has it’s own needs met to be able to co-exist with upstream, but they are minor and detached from functionality, going beyond the MVP (./Docs folder and changes on the interface on #5 and #6), or creating changes that may impact merging, such as database versioning. These changes could be introduced later as their own PRs, no need to keep them all together.
I’m currently running this on my phone, testing it out and anyone is welcome to join me on this test, but so far everything seems to be working great, no bugs, no issues, none I could see, at least. All in all seems like this could be a candidate for this feature, but I’ll leave it to you guys, specially those who came before me, to test it out and see if it makes sense to us to create a new PR with it.
Hope to hear from you soon, I’m actually quite happy with the result.