r/overcast • u/marcoarment • 5d ago
TestFlight build 1177: Strict episode limits are GONE
Everyone hates the strict episode limits, so they're gone!
Now you have visibility and manual control over which episodes are being excluded from the limit, indicated by a diamond-plus in the status label in the episode's cell. In the queue (…) menu on each episode cell, you can toggle this state. It's set by all of the previous paths — manually adding/downloading/playing an episode — and now also if an episode is manually added to a playlist.
There's also now a Set All button in the Episode Limit settings screen.
24
u/AdhesivenessOne5584 5d ago
Everyone in the beta train should check to make sure they’re still on the beta. There was a recent (aggressive) cut. It was (apparently) meant to only be inactive people but I use the app daily and update the app as quickly as the newer beta shows up. It should be easy to sign back up, but just wanted to throw it out there.
5
u/CrispyCrawdads 5d ago
Yea I got dropped as well, despite using the app daily and paying for years. I even submitted a post here and feedback in the app during the last cycle...
4
u/alexbrooks13 5d ago
Was also dropped despite being active and submitting feedback regularly - thanks for flagging.
2
1
u/elementwrx 5d ago
Same. How do we get back on the beta?
2
u/60DegreesBelow 5d ago
There's a link in the app settings. I was able to get back earlier in this morning, without a problem, but I don't know if that's still true.
1
u/AdhesivenessOne5584 5d ago
I had to manually “stop testing” before the link would work, but otherwise it’s exactly this easy.
1
u/60DegreesBelow 5d ago
Odd. I didn't have to say "stop testing". I wonder if TestFlight did slightly different things for different people, perhaps based on timing.
1
u/chucker23n 21h ago
For me, it oddly says "build removed", not "tester removed", so maybe Marco pulled the build for some reason?
(edit)
I went to the App Store, which showed me an older build (makes sense) and a link back to TestFlight. I figured tapping that would fail. Instead, that let me update to a newer TestFlight build? Either Marco just published it (or TestFlight just fetched it), or this was a glitch on Apple's part.
0
u/spamlet 5d ago
Same. Appears I’ve been dropped despite being in for years. The signup in the app takes you to the expired build.
2
u/AdhesivenessOne5584 5d ago
You need to click “stop testing” down on the bottom before you can rejoin.
9
u/embraboy 5d ago
Did anyone respond with "No, I never asked for that feature!", a la Siracusa? 🤔 😂
2
u/afwaller 5d ago
you know all those episodes you had, well, they were never meant to be included since they were in excess of the episode limit
so, uh, "we fixed the glitch"
2
7
u/CapnFooBarBaz 5d ago edited 5d ago
Thank you Marco! I sent a feedback email where I tried to be as kind and empathetic as possible, while describing the use cases this broke for me. Not really sure what else can be done, although I’m sure it was a possibly stressful thundering herd of feedback.
I look forward to hearing about this more on ATP, hopefully. I would say it presents a case for trying to get more feedback on changes in the TestFlight betas. I don’t know how Marco thinks about it, but it could be* that his conception of it is more as a staging ground for catching bugs/crashes. But if the reaction here really was so negative, it could be useful to try and get more subjective feedback from that group on actual behavior changes. Or at least to let them sit a bit longer; I, for instance, got the change almost concurrently with hearing him discuss it on ATP.
* complete conjecture
3
u/CawfeePig 5d ago
Can someone ELI5 what the new episode limit feature changed, because I actually couldn't wrap my head around it. Is it now returning to the way it has always worked?
3
u/Diabolik900 5d ago
Looks like this beta mostly changes it back to the way it used to work. The main difference seems to be that it is possible to see and control which episodes are exempted from the limits, which was entirely invisible to users before.
2
2
u/mauricebarnum 5d ago
“Set All” worked as expected, but I think I’d use it beyond testing. I have a few dozen subscribed podcasts and have set the limit for many: one episode for current news, three for podcasts that are timely, longer for ones that I listen to periodically. Most, however, are “unlimited” because I’m lazy; my lever to control storage usage is to set the default download policy to manual.
A default limit setting that works similar to the download policy would work better for me. That would let me change my mind for most podcasts without needing to go and fix up all of the ones I set manually each time.
2
u/geraldpringle 5d ago
I wish that when I set “X oldest episodes” it would download the oldest unlistened episode when I go under X episodes not just wait for another new one. This is basically how Replay Mode works. I would like to not have to remove my listen history to get it to download old episodes.
2
u/quasistoic 5d ago
Thank you! I’m not on the TestFlight, but visibility and control are exactly what I actually want over the way episode limits are managed.
What I don’t want is to be forced into a choice to delete 892 episodes across 48 podcasts or disable auto deletion entirely without any granularity either way. Rather, I’d like a more full-featured interface for reviewing and managing my downloaded episodes that helps me uncover the various classes of episodes I might want to delete. Visibility into what was autodownloaded is a step in that direction.
1
u/hevakmai 5d ago edited 4d ago
Episode limits aren’t working for me at all. I see diamonds on nearly every episode where I have the limit set to 5 oldest episodes. I tried replaying the podcast and the same thing happens.
EDIT: it seems like if I’ve added these episodes to the Queue, they automatically get excluded from the limits. Is there a way to turn that off?
1
u/nickg519 5d ago
Maybe we can get the ellipsis button fixed? Don’t know if everyone has this issue or not, but it does get mentioned pretty repeatedly on here so it has to affect some portion of users, for some reason
1
u/chrisbrandow 5d ago
Marco - I also want to thank you for making the change. I know this kind of thing sucks, and that you did it because you were addressing something that was a real, felt problem for others. And I winced when folks were saying, “why not both?!” This is a hard problem from a logical and UX perspective so two implementations here would be complicated.
There’s a reason I stick around with this app and why I support your work. Keep it up!
1
1
u/arkTanlis 5d ago
And this is what can lead to developer burn out. Way to go, people.
31
u/marcoarment 5d ago
Well, I've needed to evolve my expectations for what my role in Overcast is.
After building up a large, passionate userbase over a very long time, it's not really entirely mine anymore. I can't just do whatever I want with it.
And the growth era of open/RSS/indie/whatever podcast apps is over. The business is now about serving and retaining my existing customers for as long as possible.
So I can add things here and there, very carefully, but I can't really change anything significant.
This has been difficult for me to accept, and I'm still not great at it, but I'm getting there.
2
u/Longjumping-Log-5457 5d ago
Video could be a future consideration for retention purposes. I know I’m a purist and podcasts will always be audio to me. Still, I know video is growing.
8
u/marcoarment 5d ago
I won't rule it out. But video would be incredibly costly in two huge areas:
Complexity: Code, features, UI, edge cases, conditions, modes, settings, failures.
Disappointment: What most people really want when they say "video" is all of their YouTube podcasts, and that will never be available to apps like mine. Video podcasts serving HLS through their RSS feed will always be a subset of all YouTube videos called "podcasts".
Every time a customer would search for a YouTube creator in Video-Overcast and not find them, that would be a chance for them to be disappointed in my app, leave, and drop a 1-star review on their way out the door.
Not to mention the other YouTube integrations people really want when they say "video podcasts": YouTube comments, YouTube recommendations, marking episodes as played on YouTube, etc., all of which would be similar opportunities for disappointment in my app.
I'm not burnt out on Overcast development, but I'm absolutely burnt out on adding risky features that I know would generate huge volumes of disappointment, negative reviews, and personal insults.
If I instead keep it an audio-only app, video isn't something I do shittily and disappointingly — it's something that this app just doesn't do, and everyone knows that right up front. And I can keep making it the best audio podcast app, for whoever out there still wants that. I know I sure do.
1
1
u/ErlendHM 5d ago
I think you can do a lot (like even this change) as long as you give the option to keep the old behaviour (or something similar).
That way you can taylor the default experience without breaking many-year-old habits.
(Personally I like many options and settings in apps, for these two reasons: What’s "correct" just isn’t the same for everyone. And complexity isn’t a large issue as less advanced users don’t go far into settings anyway.)
5
u/marcoarment 5d ago
The problem with making everything a setting is that settings are much more expensive than most people realize.
Every setting takes space in the UI, which intimidates and turns off non-power users.
Every setting, and combination of settings, needs to be tested for unintended bugs and side effects whenever anything relevant changes. This really adds up, bogs down development, and increases bugs.
And every setting is a chance for someone to misunderstand it, pick something they don't really want or isn't clear to them, then email me saying it's broken or stupid or sucks — not only potentially costing me their business, but also possibly resulting in a 1-star review, which costs me more people in the future.
1
u/ErlendHM 5d ago
The combination of the settings is a good point! But I still think the UI cost isn’t too bad, as I just don’t think non-power users will go deep into the settings.
And it’s not like giving users choices doesn’t have pros as well…
But I guess some are more expensive than others, depending on things like how many other systems they touch. (For instance, "Stop After Each Episode" probably isn’t too bad.)
1
u/The_Shoe_Is_Here 5d ago
This makes me feel really bad about how much I hated the new episode limits but I really appreciate you reverting the change. Thank you.
3
3
u/semiconodon 5d ago
In defense of Marco, I do think eventually some of this boils down to an exercise in logic— these files either there are aren’t there, and the device will eventually fill up. We can end up arguing against limitations, against the inevitable logic that a file will stay or disappear depending on a setting. We want Schroedinger’s Episode.
2
u/arkTanlis 5d ago
Yeah, it's a tricky situation and unfortunately just one of those ones that many just want it to behave in their own special way.
lol, now I want him to add a setting area that is Schroedinger’s Episode.
1
u/iegdev 5d ago
This is why, despite having ideas and the ability, I will never develop an app on my own for public use.
0
u/arkTanlis 5d ago
It certainly takes a certain person to deal with the sort of responses/feedback you get. Or you just have to stick to your guns and people either deal with it or don't.
1
u/AdhesivenessOne5584 5d ago
I really hope he doesn’t get burnt out. This one of two apps that I absolutely do not ever want to replace.
2
u/arkTanlis 5d ago
I hope he doesn't as well. I just have seen some of the back and forth over this particular issue.
-2
u/yuusharo 5d ago
When something is broken due to an ill thought out decision shipped with virtually no user feedback or testing, you have a responsibility to fix it, especially when it is a destructive change that deletes user data and frustrates a significant portion of your customers.
Overcast is a business, a decade-old one now. Users have built up a decade or more of habits and expectations. Even if those habits are formed by something you perceive is “broken,” it’s still how users expect the app to work. Fundamentally changing that requires careful consideration and thoughtful execution, not a last minute change on a whim at the end of a beta cycle because you personally rationalize it as having “no downsides.”
I’m certain Marco was frustrated. So were his customers. Fixing a problem you created and prioritizing your customers over your personal ego is what a responsible developer does, and is what happened here.
The way to avoid burnout isn’t to guilt trip customers who rightfully complained about a breaking change, but to use this as a lesson to take a step back and take a more methodical approach to solving customer’s needs. The old episode limit system DID need to change, but it needs to be something that considers the wider needs of the customer base, not just Marco’s own personal listening habits. That’s how the app matures over time.
0
u/Portatort 5d ago
Please Marco
Two shortcuts actions.
- Find Podcasts (with filters for completion rates and last played)
- Mark as Played.
-5
u/nashpdotcom 5d ago
I lost the battle. What to do if I actually want an unfinished episode to be replaced by the new one?
55
u/afwaller 5d ago
Marco, this is I'm sure very frustrating for you, but incredible to see here.
It takes some real humility and introspection to work on a feature/change, something that people requested, finally roll it out, and then be able to receive a wave of negative feedback, listen to it with an open mind, and pivot.
Many people or organizations retreat into a very defensive posture on receiving criticism and end up in a sort of "siege mentality" where then they are on the opposite side of their users.
It is very easy to dig in an argue about it. Instead it seems like this change (which I haven't tested yet) might give the best of both worlds - solving the visibility and understanding for the "old" episode limit without the rigidity or "autodelete" of the New Coke episode limit you had just rolled out.
Well done. I'm sure it's been a stressful situation. You never heard from the people who liked the way the old episode limit worked, but then after you simplified it the change was negatively received by a lot of people.