Automattic / Automattic/pocket-casts-android

Android: stale Cast session auto-resume (error 2152) tears down the media notification and stops local playback

Open
#5,248 0 comments 0 reactions 0 assignees View on GitHub
Bug
Dominant language
Kotlin
Stars
2.8k
Forks
308
Avg merge
1d 13h
Merged PRs (30d)
143

Description

> **Updated 2026-07-27** with root cause confirmed from a full debug log on 8.16. The original report is preserved under "Original report" below. Retitled from "Intermittent broken playback with 8.10-rc-2": this is neither intermittent nor rc-specific, it reproduces on demand and is still present in 8.16.

## Summary

Pocket Casts persists a Chromecast session and the Cast SDK auto-resumes it on app foreground. When the receiver is unreachable the resume fails with error `2152`, and **that failure is routed into the local playback error path**. The result is that the media notification and foreground service are torn down and local playback stops, even though the user is not casting and never asked to.

The user sees a "Could not connect to the Chromecast device" toast, loses lock screen / headphone / Android Auto transport controls, and playback halts.

## Log signature

```
E Cast session resume failed with error code 2152
E Cast session failed with error code 2152
I stopForeground state: 7 removing notification: true
E Playback state error: 1 Could not connect to the Chromecast device. Please check the device and try again.
```

Repeats roughly 10 seconds after **every** app foreground event (10+ occurrences in a single log), each preceded by the standard foreground sequence (`Loading subscription plans` / `Billing client connected` / `Set up periodic refresh`).

Sequence:

1. Cast SDK attempts to resume a previously saved session.
2. Resume fails with `2152`.
3. The failure surfaces as a generic playback error instead of being scoped to the cast path. **This is the defect.**
4. `stopForeground(... removeNotification = true)` tears down the media notification and foreground service.
5. Local playback stops; transport controls go dead.

## Reproduction

1. Cast to a Chromecast or Nest receiver from Pocket Casts.
2. Leave without explicitly tapping **Stop Casting** (walk out of range, or power the receiver off).
3. Later, with the receiver unreachable, foreground Pocket Casts and play an episode locally.
4. Within ~10 seconds the toast appears, the media notification disappears, and playback stops.

Step 2 is the trigger. The saved session persists indefinitely until a session is explicitly ended.

## What this is not

* **Not a network or proximity problem.** Confirmed firing with `Current connection: Type: mobile, Metered? yes` and a Bluetooth headset as the active audio route. Cellular data, no receiver reachable anywhere, and the resume is still attempted and still kills playback. Toggling Wi-Fi does nothing.
* **Not cleared by a process restart.** Four separate `App started. 8.16 (9441)` events within a ~5 minute window, error recurring after each. The saved session outlives the process, so force stop and device reboot do not help.
* **Not user-initiated.** Affected users are not casting. One had never knowingly cast from the app.
* **Not PCDROID-555.** The same log contains `reason=3 (LOW_MEMORY)` process exits, but those are a separate issue. This failure is directly attributable to the cast error tearing down the foreground service and is reproducible on demand.

The user-visible toast is gated behind the `display_errors_on_player: true` flag, enabled in current builds.

## Workarounds

**Works:** rejoin the network with the receiver powered on, connect from Pocket Casts, then explicitly tap **Stop Casting**. This ends the session cleanly and clears the persisted state. Independently discovered by the reporter on PCDROID-549.

**Does not work,** all confirmed by affected users: force stop, device restart, Wi-Fi toggle, and "disconnect via the Cast icon" (there is no visible session to disconnect from, which is precisely the problem). Support should not be recommending these.

## Suggested direction

Two separable fixes:

1. Do not propagate a Cast **session resume** failure into `PlaybackState` or the local player error path when no cast session is actively in use. Failing silently back to local playback resolves the user-facing breakage on its own, and is the smaller change.
2. Reconsider `CastOptions.setResumeSavedSession`, or bound the resume attempt: stop retrying once the route is undiscoverable, and clear the persisted session when the app is not on a network where that receiver exists.

## Impact

* App versions **8.9 through 8.16**.
* Android 16 (SDK 36) and Android 17 (SDK 37).
* Multiple OEMs: Nothing A024, Pixel 10 Pro XL.
* **10 support tickets** carrying this error string since April 2026. Two are attached to this issue; at least one affected customer has stated they are switching apps over it.

Likely the same underlying defect as PCDROID-549, which can probably be closed as a duplicate of this once confirmed.

---

## Original report

### Description

This issue occurs intermittently. During podcast playback (over headphones so no casting), I'll get a toast notification that says

> Could not connect to the Chromecast device. Please check that the device and try again.

Sometimes playback will continue and sometimes it'll pause (and only resume when I re-enter the app). What will consistently happen is that the playback controls will disappear from the notification area and I can no longer play/pause with the controls on my headphones. If playback continues, it will usually be able to finish the podcast but then it won't go to the next one in the queue (it'll just pause at the end of the current podcast). When I open the app it displays a banner underneath the bottom bar which says

> This episode can't be played. Learn more

where the "Learn more" link takes me to an unhelpful webpage. Note that this banner appears consistently even though the podcast is playing.

Going into the playback screen, hitting play/pause twice will usually reset the app to working normally temporarily.

I do wonder if this is related to casting that I don't exit properly. I do sometimes cast to speakers, pause playback and then leave home without explicitly cancelling casting. This has never previously been a problem.

*(Confirmed 2026-07-27: this hunch was correct.)*

### Step-by-step reproduction instructions

Unfortunately this issue occurs intermittently so I don't have good reproduction instructions. When it does occur, it's often something like the following:

1. Open Pocket Casts and start playing a podcast.
2. Leave the app (not always required)
3. Wait a short period of time
4. Observe the toast notification which says

> Could not connect to the Chromecast device. Please check that the device and try again.
as well as the playback controls disappearing from the notification area.
5. Try play/pausing using my headphone controls. They don't work.
6. Open Pocket Casts and observe the bottom banner which says

> This episode can't be played. Learn more
7. The app can be reset to normal by going to the "Playing" screen and tapping Play/pause twice.

### Screenshots or screen recording

Toast notification:

![Image](https://github.com/user-attachments/assets/0809dc1e-12df-4882-a20f-2f6ace775244)

Bottom banner:

![Image](https://github.com/user-attachments/assets/53ba846a-eb63-49f0-9b42-92108c88a218)

### Did you search for existing bug reports?

- [X] I have searched for existing bug reports.

### Device, Operating system, and Pocket Casts app version

* Google Pixel 10 Pro XL
* Android 16
* Pocket Casts 8.10-rc-2 (9423)

Contributor guide

Open the contributing guide

Research direction

Trace the Cast SDK saved-session resume handling into the PlaybackState and local playback error path, using the 2152 log sequence and reproduction steps as the starting point. Reproduce with an unreachable receiver, then verify that a resume failure when no cast session is active does not remove the media notification, stop the foreground service, or halt local playback.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, kotlin
Domain
mobile
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.