| Age | Commit message (Collapse) | Author |
|---|
|
Two of Peter's, both on surfaces that already had the pieces.
Holding a show in the library plays what it is offering, the same gesture the
episode list has carried since the row buttons changed. Playing a show's newest
episode meant opening the show first, which is two taps for the thing you want
most often. A show offering nothing does nothing when held, rather than
something arbitrary -- tapping still opens it either way.
The transport's second row reads sleep, speed, ad. It was the reverse, which
was my ordering and not a considered one. Sleep is set deliberately before
settling down so it takes the near edge; the ad button is hit mid-listen when
something slips through, so it sits furthest out where a stray press costs the
least.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The last thing standing between the token and the query string it should not
be in. The downloader moved to an Authorization header a while back; the player
never did, and the player is how the car plays anything not already on disk.
Withdrawing the query parameter without this would have broken streaming in the
car silently -- a 401 arriving as "playback failed".
ExoPlayer resolves a URL on its own loading thread with no coroutine to read
DataStore in, so ServerAudioAuth caches the configuration and the session
callback refreshes it before handing over any stream URL. Nothing is cached per
URL: the same player fetches publisher audio, and the whole point of
ServerBearer is that those get nothing. Attached through a ResolvingDataSource
rather than as a default request property for the same reason -- a default
would send Peter's server credentials to every podcast CDN he subscribes to.
Before the first refresh it sends nothing, which is the safe direction: a
stream that should have carried the token fails visibly, where one that should
not have carried it would have leaked it.
Verified against the live server, not a fake: the player reaches READY on
listen.terst.org audio with a header and no token in the URL, and the same URL
without credentials is still refused. The token is supplied as an
instrumentation argument and is not in the repository -- a test file carrying
it would be the same mistake in a different file -- so the test skips unless
one is passed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Two things, both about finding something rather than playing it.
Android Auto lists category folders under Podcasts instead of forty-five shows
in a row -- a car screen holds six to eight, so anything not near the top was
several flicks away. The categories already existed and already had an order,
so this costs no new data. With only one category present the folders would
separate nothing, so the shows are listed directly and the level disappears.
A show that has not published in a year says so above its drip control:
"No new episodes in 3 years". That is the whole of the special treatment a
finished show gets -- no flag, no automatic behaviour, no guessing that a show
is over. A run of silence is a fact and "finished" is not. A year, because
shorter fires on everything merely between seasons, and a line that appears on
everything says nothing. It costs no extra query: the sheet already reads every
episode for the detection readout.
The browse id format moved out of LibraryTree into BrowseIds, because that
object went past its function limit and the split is along a real line. The
format is the seam that has actually broken -- an id that does not survive the
round trip to the browser is what made Up Next show something other than the
queue -- and it could not be tested off a device before, because LibraryTree
builds Media3 items. It has six tests now, including that an episode id and a
show id carrying the same raw string are never confused for one another.
Verified over the real session protocol on the emulator: the folders appear,
the News folder holds the news show and not the fiction one. 8 browse tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Four things Peter asked for, all on the episode screen, which is the now
playing screen -- there is no separate player.
The artwork is 72% of the width rather than a 96dp thumbnail, so it reads as
the artwork of what is playing instead of a list icon. Short of full width on
purpose: the title and the transport still have to be on the first screen.
The three controls you press without looking -- back, the primary, forward --
have a row to themselves at a size worth aiming at. Five controls on one line
made all five small. The ad button, the speed and the sleep timer share a
quieter row below.
The sleep timer is on the screen now instead of three taps into the overflow
menu, which is the wrong depth for something reached for in the dark. The chip
carries what the timer is waiting for -- it reads 14:55 while a countdown runs
and "End of episode" in the other mode -- so nothing has to be opened to find
out. It opens the same dialog the menu does; one set of durations, one
explanation of the fade, two ways in.
The notes are shown in full and never behind a tap. The fold existed so long
notes could not push the transport off the screen, and the transport moved
above them when the two screens merged -- so all it still did was hide the half
of the screen it was there to protect. DescriptionPreview and
ExpandableDescription go with it.
The wording moved to SleepLabel, which is tested: it was inline in the menu and
again in the dialog, and the chip would have been a third copy.
Verified on the emulator rather than from the diff: the screenshot shows all
four, the chip opened the dialog, and arming 15m turned the chip into a running
countdown.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Both describe behaviour that was deliberately changed and neither was updated
with it, because the instrumented suite is not in the commit gate: it needs a
device, so it only runs when someone asks for it. 108 tests, two of them
asserting the opposite of what the app now does.
The library row asserted a Download button. The row's three became play next,
queue and mark played a commit ago -- play is a long press on the line and a
queued episode downloads itself -- so the test named a control that no longer
exists. Mark played now has a test of its own; it was the one the change was
for and the only one of the three with none.
The car's resume test seeded an episode with no file, from when playback would
fall back to the publisher's copy. That fallback was removed on purpose, so the
car now starts a fetch and plays nothing this time round -- the test was
asserting a resume against an empty playlist and failing on the position being
zero, which is the right answer to the wrong question. Confirmed from the
device's own log, "nothing to play for resume-ep from outside the app", rather
than inferred. It seeds a downloaded episode now, so the defect it exists for
-- the position being dropped at the session boundary -- is what it measures.
Whole instrumented suite: 109 tests, no failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Browsing by show is the wrong shape for driving: it asks you to remember what
you were doing and then find it, which was behind "discovery sucks" and
"scrolling the lists in the car is bad experience". Three lists sit above the
shows now and answer the question actually being asked at a traffic light --
what was I in the middle of, what fits this drive, what is new.
All three come from data the app already keeps. No new column, no migration.
Short cuts off at 20 minutes, which is Peter's call rather than a guess: it
catches the daily news and the shorter curiosity episodes and leaves out
conversation and deep dives. It reads COALESCE(actualDurationMs, durationMs)
-- playbackDurationMs in SQL -- because a feed declaring 22:05 for a file that
runs 28:18 would otherwise put a half-hour episode in a twenty-minute list.
An episode of unknown length is left out; unknown is not short.
Continue is the one list that does not exclude queued episodes, because the
episode you are in the middle of is normally the head of the queue and
excluding it would empty the list in the ordinary case. Short and New exclude
anything started, so finishing something is never buried under a new arrival.
A list holding nothing is left off the root entirely rather than opened and
found empty -- the same dead end the phone's library dims a show for.
The queries are their own narrow CarListDao rather than three more methods on
EpisodeDao, which detekt was right to call already the widest in the app: they
are read-only, they all cross every show rather than belonging to one, and
they exist for a single surface. Not on UiGraph, since no view model wants them.
Verified on the emulator: 9 CarListsDbTest cases against the real tables, and
MediaBrowseTest walks the real session protocol to the Continue node and finds
the part-heard episode in it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Tier said "how important" and the shows needed "what kind". Seven ordered
categories replace it: news, analysis, curiosity, sailing, true stories,
fiction, deep dives. The order is still the server's processing priority, so
one field carries both axes -- which is the idiosyncrasy docs/show-kinds.md
is written to watch, with four signs that a better abstraction has arrived.
All 42 known feeds are refiled by migration 20 -> 21, which rebuilds the
subscriptions table rather than renaming the column: RENAME COLUMN keeps the
old 'ordinary' DEFAULT and fails schema validation, and DROP COLUMN needs
SQLite 3.35 against minSdk 29's 3.28. The wire value for true stories is
"truestory", not "true", because SQLite reads an unquoted true in a DEFAULT
as the boolean and stores 1.
Schema 21 is a new exported JSON; migrate20To21RenamesTierAndRefilesTheKnownShows
covers it, and all 22 device migration tests pass.
The coverage exclusion for the settings composable follows the file's rename;
left pointing at TierSettingKt it read as a 0.6% drop. The remaining 0.08% is
the deletion of the covered tier-seeding code, taken as an exception.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
**Android Auto was broken by my own fix, and this is the third attempt at the same decision.**
It started by falling back to the publisher's enclosure, which plays a differently-ad-inserted
copy so the measured breaks cut into the programme. Fixing that made the browse callback
*download* first -- tens of megabytes inside the future Auto is waiting on -- so the car reported
"failed to load" and the episode played later only because the download had finished by itself.
That is exactly what Peter saw.
The distinction missed twice: streaming is not the problem, streaming *the publisher's copy* is.
The server's copy is the audio the offsets were measured against, so playing it is as correct as
playing the file and it starts at once. The car asks the server (one small request), plays the
download if there is one, the server's copy otherwise, and nothing at all if neither -- never the
publisher. The fetch still happens, on its own coroutine, so the next attempt has the file.
OutboundRequestsTest said "no remote media item", which was the wrong rule and is why it had to
be relaxed to let this through. It now says what was always meant: nothing in the playback
package may touch `mediaUrl`, the address the *publisher* nominated. Watched failing.
**The car's Up Next was not the queue, and one episode looped.** Both are the same bug, and not
in the browse tree -- that listed the real queue all along. Tapping an episode set the *player's*
playlist to that one item, so the car's own Up Next showed one entry and a single-item playlist
repeats instead of moving on. The playlist is now the queue, starting at the episode tapped. An
episode browsed from a show is not in the queue and still plays alone, because dragging the queue
in behind it would quietly change what plays next.
ReachabilityTest then found `startFetchingIfNeeded` had no callers left -- it existed only for the
car path this replaces -- so it is gone, with the two tests that were really about `fetchAndStart`
rewritten against it rather than deleted with it.
**The lists, as asked:**
- The library row offered play, queue, download. It now offers play next, queue, mark played.
Play is a long press and download happens by itself for anything queued; what was missing was a
way to say "not now" without opening the show.
- Episode rows had five icons across a phone, where the useful ones were the hardest to hit.
Three now, the same three.
- Long press on an episode plays it immediately. Tap still opens it.
- The show's name in the episode screen's top bar opens the show. It was sitting there doing
nothing.
Extracting `rememberShownEpisode` kept EpisodeScreen inside its length budget -- the follow-the-
player logic is a named concern and reads better out of the way than the top bar did.
All four checked on a device, not just in tests: the three icons, a long press starting playback
at 0:06, and the title tap landing on the show.
The coverage gate pushed back and found one more gap on the way: a fetch failing with no message
fell through to the exception's class name, and nothing exercised it. Tested now. The exception
covers only the deleted method's own tests.
1065 tests, detekt 0, lint clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Peter's mobile data is not metered, so the UNMETERED constraint on the refresh worker was doing
nothing for him -- and the question was whether to mark the connection metered or drop the guard.
Neither, quite.
The guard was never about the cost of refreshing. Its own comment said so: "refreshing every feed
is cheap, but downloads that follow are not". It was a proxy for a guard on downloads, and the
refresh is genuinely cheap -- every request carries If-None-Match and If-Modified-Since, so an
unchanged feed is a 304 with no body and a whole sweep is a few hundred bytes a show. Waiting for
Wi-Fi to spend that is what let a failed refresh from hours earlier stay on screen as the current
state of the library.
So refresh runs on any connection now, and the download worker keeps its unmetered and
battery-not-low constraints, which is where the expensive unattended work actually is.
Marking the connection metered would have worked too, and is worse: it is a system-wide setting
changed to compensate for one app, affecting every other app on the phone.
**What the guard was really hiding, and still is:** anything reaching the queue calls
Scheduling.downloadNow, which has no network constraint at all -- deliberately, because Peter
asked for things he queues to download immediately including on mobile data. An auto-queue rule
firing during a background refresh goes down that same path, so a rule can start tens of
megabytes unattended on cellular. That is fine while his data is unmetered and is the real hole
if it ever is not; distinguishing "I queued this" from "a rule queued this" is the fix, and it is
not in this commit.
1059 tests, detekt 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The security review of the last commit found a confused deputy in it, and it was right. The
bearer was attached on origin alone, and `episode.mediaUrl` comes out of a feed -- so a publisher
could set an enclosure URL on the skip server's own origin, match the origin check exactly, and
have the app issue an authenticated GET to a path of their choosing, storing whatever came back
as that episode's audio. Confirmed by writing the test before the fix: it failed.
Provenance is the first gate now and origin is the second. `authenticated = true` is passed only
for the URL `ServerAudio.resolve` returned, never for one that arrived in a feed, and the origin
check still has to agree -- so a server answer naming some other host is fetched without
credentials rather than sending them there. Both gates have a test, including the case where they
disagree, and OutboundRequestsTest pins that exactly one call site in the app is authenticated.
**Chasing the coverage gate honestly turned up a real bug**, which is the second time this week
it has earned its keep. Rather than file a third COVERAGE_EXCEPTION I went to see what the
uncovered lines in EpisodeDownloader actually were, and wrote a test for the empty-response
branch. It failed: OkHttp hands back an empty body rather than null for a 204, so the existing
`?: run { ... }` guard never fires, the copy writes nothing, and a **zero-byte file is renamed
into place and recorded as DOWNLOADED**. That episode then fails to play and reads as the
publisher's fault. The length is checked after the copy now, which catches a 204, an empty 200
and anything else that arrives with no bytes.
Also tested while there: the media-type to file-extension mapping, which had none. Not cosmetic
-- Media3 picks an extractor partly from the extension, so a .audio file holding mp4 bytes is a
plausible way to get an episode that will not play. Parameters and capitals included, because
feeds send "audio/mpeg; charset=utf-8" and "AUDIO/MPEG".
1059 tests, detekt 0, lint clean, coverage 94.09% -> 94.28% with no exception.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Peter opened the app to six shows in red, every one of them "Could not reach that feed". All six
answered 200 when checked from the server a minute later.
His guess was an auto-refresh on focus. There isn't one -- the only triggers are the button and a
six-hourly worker -- and that makes it worse rather than better: what he was reading was a stale
report of a connection that dropped during a background refresh hours earlier. The line survives
until that feed next succeeds, and the worker is constrained to unmetered networks, so on mobile
data "next" can be a long time.
The error is still worth storing. A feed that has quietly stopped working is indistinguishable
from one with nothing new, which is the whole reason it is kept rather than logged. But one miss
is noise and a pattern is information, and the difference was already recorded: lastFetchedAtMs
is the last time the feed actually worked. So a failure appears once a feed has gone a day
without succeeding -- about four missed attempts at the current cadence. A dropped connection
clears itself and is never seen; something genuinely broken still goes red, the same day.
No schema change; the timestamp was already there.
Two cases stay loud on purpose. A feed that has *never* succeeded reports immediately, because a
subscription that failed the moment it was added is not a blip and somebody is waiting on it. And
a success timestamp in the future is treated as no success, so a clock that has moved cannot hide
a real failure indefinitely.
Not changed, and worth deciding separately: the periodic refresh is unmetered-only, so on mobile
data the library goes stale with nothing saying so. Adding a refresh on launch is now safe in a
way it was not before -- the transient failures it would produce are exactly what this hides --
but it is a behaviour change nobody asked for.
1052 tests, detekt 0, lint clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Groundwork for the server to stop putting the token in /audio/ query strings. Apache no longer
writes those to disk, but a secret in a URL still travels through everything that handles the
URL, and the only reason it was there is that the downloader had no credentials of its own.
Now it does: ServerAudio gains bearerFor(url), ServerSkips answers it from the configured
address, and downloadOverHttp attaches Authorization: Bearer when it gets one.
**The whole risk is in that one question.** This downloader also fetches episodes from whatever
CDN a publisher nominates, so an over-eager match would hand Peter's server credentials to every
podcast host he subscribes to -- strictly worse than the leak being closed. ServerBearer
therefore compares parsed origins, scheme and host and port, never the text of the URL, and the
test is mostly near misses: a host the server's name is a prefix of, one it is a suffix of, the
name appearing in a path or a query or a fragment, a userinfo section ending in the server's name
before an `@`, a downgraded scheme, a different port. Several of those pass a naive string match.
One of those tests needed a test of its own. `https://listen.terst.org@evil.example/...` is
refused, but it would also be refused if the URL simply failed to parse -- in which case the
origin check was never reached and the thing I thought I was testing was untested. So there is an
assertion that it parses, with host evil.example and username listen.terst.org.
The wiring test runs the real ServerSkips rather than a fake and checks the publisher path sends
no Authorization at all, because the unit tests above it fake exactly the component whose
host-matching is the safety property.
The server still emits the query token; this has to be installed before that stops, or downloads
401 in the gap. That is the next change, not this one.
1052 tests, detekt 0, lint clean, coverage 94.06% -> 94.09%.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Two things Peter asked for, both about a cadence the app imposed and gave no way around.
**Opening the app and pressing play was two taps.** The library's Up Next row had no play button:
tapping it opened the queue, and the button was there. Two taps for the single thing the app is
for. The row has a play button now and still opens the queue, which is where reordering and
everything else lives.
**A slow drip had no override.** A drip is a cadence you chose so you would not have to think
about it, and most of the time that is the whole point -- but a cadence you cannot override owns
you. Finish Tuesday's episode when the next is due Thursday and there is nothing to listen to and
no way to ask for more.
"Release the next one now" sits under the drip cadence in the show's settings, and only while drip
is on: a show listing everything already has nothing to bring forward. It honours the show's batch
size and its oldest/newest-first choice, because those are the same decision.
One judgement in it, and the opposite choice is defensible. It **brings the next release forward**
rather than granting an extra: the mark moves to now, so the scheduled one is a full interval away
instead of landing on top of this one. Asking for the next episode reads as asking for it sooner.
The clock restarts even when the archive turned out to be empty, so repeatedly asking an exhausted
show cannot build a debt that bursts when the publisher next posts -- the same reasoning
DripSchedule already applies to the scheduled path.
An empty archive says so. "Nothing happened" and "the button is broken" look identical otherwise,
which is the same fault the drip toggle's own banner was written to avoid.
DripSettings' callbacks are bundled into DripActions, because adding the fourth took it past the
parameter limit -- the same shape EpisodeActions and LibraryNav already use.
Checked on the emulator, not just in tests: the play button appears on the Up Next row and starts
the episode, and the release button queued episodes and advanced the drip mark.
1031 tests, detekt 0, lint clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
**Android Auto was the one caller still streaming from publishers.** `onAddMediaItems` resolved a
browse id straight to a media item without asking whether the audio existed, so an undownloaded
episode was handed to the player as its publisher's URL. That is the worst place for it: the car
is where most of this library is actually heard, and misplaced skips are least obvious there.
It goes through `PlaybackAdvancer.startFetchingIfNeeded` now -- start, and fetch first if there is
no file -- the same decision the in-app paths make, in the one class tested for it. A fetch that
fails stays failed rather than falling back: the publisher's copy carries different advertising,
so the server's measured breaks land in the wrong place, and silence that can be retried beats
skipping into the programme.
With that, nothing reached the fallback, so it is gone. `setUri(localPath ?: mediaUrl)` is now
`setUri(localPath)`, `MediaUrl` is deleted, and OutboundRequestsTest asserts zero remote media
items rather than pinning one. `start` also reports Gone for an episode whose show *and* file have
both gone, which is what made the fallback removable -- an orphan that still has its file plays.
**Two findings from the security review of the last commit, both mine, both real:**
- `Request.Builder().url()` throws on a URL it cannot parse and only IOException was caught, so a
feed with a junk enclosure threw straight past the Result its caller folds. Survivable when this
ran from a worker; not now that every play goes through a fetch, where one bad enclosure in one
feed would stop any episode starting. Caught in the downloader, and `fetchAndStart` turns a
thrown fetch into FetchFailed -- rethrowing CancellationException, which a test now pins,
because swallowing it would report a cancelled start as a failed one and leave a false error on
screen.
- `FeedFetcher` logged whole feed URLs. Private feeds carry a token in the query and some carry
credentials in the userinfo. `FeedFailureText.redact` cuts them to scheme and host, and is
tested as the security control it is rather than as tidiness. The unparsable branch logs neither
the address nor the exception, and says why: that exception's message *is* the address, so
logging the cause would put back exactly what redacting removes.
**The transcript URL no longer carries the token.** Apache logs the request line, so every
/api/transcript fetch wrote the server's token into its access log in plaintext, across fourteen
rotations. It was redundant there: the phone sends Authorization: Bearer anyway and tokenOK takes
either. The audio URL still carries one -- not redundant, the downloader has no credentials of its
own -- so removing that needs an app change installed before the server stops emitting it.
The gate refused this twice and was right both times. The coverage drop was not all deletion: the
redaction and the cancellation contract were genuinely untested, and have tests now. Then detekt
caught an import left behind by moving the redaction into FeedFailureText -- a move I made after
the last time I ran it.
1031 app tests, 376 server tests, detekt 0, lint clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Three things, from one red banner on Peter's phone reading "Playback failed:
ERROR_CODE_IO_BAD_HTTP_STATUS". His words were "arcane and sketchy". Both halves were fair, and
the second was pointing at a real bug rather than a wording problem.
**The app was streaming episodes from their publishers.** `toMediaItem` falls back to the
enclosure URL when there is no local file, and nothing stopped a play reaching it: press play on
an undownloaded episode and it opened the publisher's CDN directly. Three things wrong with that.
It is the automatic publisher fallback the download path had removed on purpose in October ("Do
not reintroduce an automatic fallback for a transient failure"), surviving where nobody looked.
It is an outbound request to a third party that nothing asked for -- the sketchy part, and Peter
was right to read it that way. And worst, nothing in playback checks `audioFromServer`, so the
breaks the server measured on *its* copy were being applied to a copy with different advertising
in different places: skips landing in the wrong spot with no way to tell why.
`PlaybackAdvancer.start` now returns NeedsFetch for any episode with no file, which routes through
the download path that already honours the server rule. One caller still reaches the fallback --
Android Auto resolves a browse id straight to a media item without the advancer, and a car that
silently plays nothing is worse than a car that streams. That needs fetching inside the session
callback; until then OutboundRequestsTest pins the fallback to exactly one line.
Ruled out first, with evidence rather than theory: the skip server (every request in its access
log is a 200), the user agent (both the app's and Media3's get 200 from the enclosure), and my own
deploy the day before.
**The messages.** Media3's constant is now a sentence (`PlaybackFailureText`), and it was not the
only one. The same pass found `Download failed: ${it.message}`, `Could not read that file:
permission denied`, and `FeedFetcher` putting the literal word `UnknownHostException` under a
podcast's name in the library -- that one reaches two surfaces, because the text is also stored as
the subscription's `lastError`. **Two existing tests asserted the machine text came through**,
which is how it survived review; they assert the opposite now.
Accuracy turned out to be the harder half. "It will be retried" reads better than "Try the
download button again" and is a lie: a failed download is deliberately left FAILED. A 404 and a
503 both mean "it didn't work" to a library and are different decisions for the person choosing
whether to unsubscribe, so they say different things. Where the cause cannot be narrowed the
sentence stays vague rather than guessing. Every cause goes to logcat -- which detekt caught me
failing to do in FeedFetcher, three swallowed exceptions after I removed their messages.
**The guardrails Peter asked for**, both watched failing before being trusted:
- `PlainLanguageTest` -- no listener-facing message may be built out of an exception or spell out
an error constant. Deliberately scoped to where errors surface rather than judging all prose.
- `OutboundRequestsTest` -- one OkHttpClient, built in AppGraph, carrying SecureSchemeInterceptor;
nothing may open a connection another way; and the publisher-stream fallback must stay at one
site. The same arrangement the server has in safefetch/audit_test.go and for the same reason:
this app fetches URLs chosen by podcast publishers.
**And the readout, which Peter asked for directly.** The per-show "Detected skips" lines read the
confirmation rows the on-device detector used to write, so since detection moved they could only
ever say "Nothing found yet" -- on every show, including ones the server was publishing breaks
for. Counted off the episodes now. Verified on a device against a staged state rather than argued:
three of five episodes carrying a detected intro, one carrying an ad break, reading "Found in 3 of
5 episodes" / "None found in 5 episodes" / "Found in 1 of 5 episodes". *Not checked* and *checked,
found nothing* are different answers again, which was the whole point of the readout.
1016 tests, detekt 0, lint clean. Coverage 94.58% -> 94.12%, COVERAGE_EXCEPTION for the same
reason as yesterday: the deleted confirmation-row code was covered.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Peter's call: server first. The audio-fingerprint subsystem ran on the phone until detection moved
to the server, and then kept being shipped: FingerprintWorker and MidrollWorker went at the time
and the twelve classes they drove stayed, unreachable, in every APK since. ReachabilityTest found
it on 2026-11-03 once it was widened to classes, and it has been sitting in that test's allowlist
with its reasoning since.
Gone: IntroOutroDetector, AudioCorrelation, MidrollScanner, MidrollDetector, MidrollUpdater,
FingerprintUpdater, MediaCodecClipSource, Decimate, Fft, MonoResampler, PcmCodec, StoredClip, and
the 67 unit tests over them. 3,092 lines.
**Recoverable by name, not by archaeology.** The tag `on-device-detection` marks the last commit
that has it, pushed to the local remote along with everything else from this session, and the tag
message says how to bring it back. The work cost weeks and the approach may be wanted again.
What stayed, because none of it is detection: SkipSummary words the readout, BreakTrack and
BreakPopup draw and explain the timeline's marks, and MidrollClipStore shrank to deleteAllFor
alone -- its write and read halves had one caller each and both were the deleted updater, but a
phone that ran the old version still has clip files on disk and unsubscribing is the only thing
that clears them. Its test now writes the old layout by hand, because that layout is a
compatibility concern now rather than this class's own choice.
IntroOutroDetector.CONFIRM_THRESHOLD and MidrollDetector.CONFIRM_THRESHOLD moved to SkipSummary,
the only thing left that reads them. Both were three and the server's DefaultConfirmThreshold is
also three, checked against each other before the move.
**The database was deliberately not touched.** show_fingerprints, show_midrolls and
episode_midrolls are the server's columns now -- ServerSkips writes its answers into exactly the
columns the on-device detector used to, which is why playback needed no changes when detection
moved. Four MidrollDao methods went because they were the discovery half (upsertCandidate,
deleteCandidate, getUncheckedDownloaded, setMidrollCheckedAtMs) and the reachability check named
them; a DAO method is not schema, so there is no migration here and nothing for a real library to
go wrong over.
Two things found while doing it, neither caused by it, both written up in CLAUDE.md:
- **The per-show "Detected skips" readout can never say anything.** It reads candidate and
confirmation rows, and nothing has written one since detection moved -- the server writes
per-episode ranges and offsets instead. Verified on the emulator, not inferred: a fresh install
with a live subscription shows "Nothing found yet / Nothing found yet / None found yet" while the
server is finding and publishing breaks for that very show. It has been lying since the
migration; deleting the detector only makes it undeniable.
- **RetentionSweeper's pending-episode guard protects nothing**, for the same reason: nothing sets
a pending basis any more, so both id sets are always empty.
The APK barely moves -- 110KB of dex, 72.61MB to 72.50MB -- because it is dominated by the
embedded Python. This was never going to be a size win and is not being sold as one; it is 3,092
fewer lines to read, search and mislead.
1004 tests pass, detekt 0, lint clean. Coverage 95.35% -> 94.58%, which is the documented
COVERAGE_EXCEPTION case: deleting dead code that happened to be well covered.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The last two pieces, both of a kind: a feature that was built, wired and correct, and did nothing
because the thing that triggers it was missing.
**"Waiting for server" lasted until the next refresh.** The server starts fetching the moment it
is asked and its on-demand mirrors finish in seconds -- 183 of them over thirty days, several
completing two or three seconds apart. The phone looked again only on a feed refresh, which is the
5am alarm, a launch or the button, so an episode the server would have within the minute read
"waiting for server" for hours. That gap, not anything on the server, is what made "not checked
yet" a state a listener sees.
A wait now schedules one look back a minute later, through WaitingDownloads, which already bounds
the work two ways. KEEP rather than the REPLACE downloadNow uses: several episodes landing in the
waiting state one after another is the normal case, and REPLACE would push the retry a minute
further out each time until a queue of them starved it. The first wait sets the time.
The hook lives on ServerSkips rather than on a wrapper around it. The wrapper version was written
first and is the sort of thing that rots silently: changing the graph's declared type back to
ServerSkips drops the override, nothing fails, and the retry simply stops. WaitForServerWiringTest
now pins that a wait is reported through the real class, and was watched failing without it.
**Tiers were shipped empty.** The control, the push on every refresh, the server ordering its work
by it -- all built, all tested, and not one of 43 shows ever placed, because placing them was a
tapping job. So the server worked the library in feed order and the news waited behind whatever
else turned up, which is the exact thing the feature was asked for.
TierSeeder reads it off the feeds instead, checked against the real library before it was written.
It puts Tangle, Up First, Science Friday and Wards Way in Topical; both Dan Carlin shows, Radiolab,
Reply All and the bulk-published back catalogues in Whenever; and leaves the weekly middle -- 23 of
the 42 -- alone. Peter named Up First and Tangle as the ones to hurry and Dan Carlin and Radiolab
as the ones to let wait, so the rule agrees with the person it is for.
Publication rate alone does not work, which is why there is a floor. Serial, LOW and The Outer
Reach each measure a median gap near zero because a whole season went up at once: on rate they look
more topical than the news and mean the exact opposite. A gap under half a day is a back catalogue,
not a daily show.
It is a seed, not a policy. It runs once, touches only shows still sitting at the default, and
never a show placed by hand -- and it declines to spend its one run on a library with no episodes
to judge yet, or a fresh install would be marked done having placed nothing. Afterwards the control
in the show's settings is the only thing that decides.
Verified on the emulator rather than argued: Darknet Diaries, fortnightly, placed itself as
"Whenever" on a refresh with nothing tapped.
RetryWaitingWorker joins the three WorkManager entry points already excluded from coverage, under
the list's own rule -- the decisions are WaitingDownloads', and those are measured.
1071 tests, detekt 0, lint clean, coverage 95.29% -> 95.35%.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Peter's call on both, after the view-model work surfaced them as dead code.
SleepTimer was documented as working "in two modes: a countdown, or stop at the end of the current
episode", and armForEndOfEpisode, shouldStopAtEpisodeEnd and extendBy had no caller anywhere. So
"stop at the end of this episode" did not exist in the app, and every duration in the sleep dialog
went to armFor, which resets -- tapping 15m on a timer with thirty seconds left gave 15:00 and
quietly took those thirty seconds away, the one thing extendBy's own comment says not to do.
A duration now adds to a running timer and the buttons say so, "+15m" rather than "15m". The
dialog offers "End of episode", and the overflow entry reads "Sleep timer - end of episode" in
that mode, since there is no countdown to show.
The two modes watch differently on purpose. A countdown needs a clock, so it ticks. Stopping at
the end of an episode needs the moment the episode is done, and a one-second poll means a second
of the next episode playing to somebody who asked to be stopped -- so it follows nowPlaying, which
already republishes every second for the progress bar, and treats the queue advancing as the end
whatever the last position said.
Adding the mode took PlayerViewModel past its function limit, so the whole concern moved to
SleepController -- the answer ListenViewModel got when it outgrew one, rather than raising the
threshold a third time. SleepTimer keeps the arithmetic and stays pure.
ReachabilityTest now covers classes, which is why this was invisible: it scanned `object`
declarations only, and SleepTimer is a class. Classes cannot use the object check's matching --
a call names the instance, not the class -- so they get the DAO check's looser `.name(` matching,
which needed three call shapes before it was honest: the ordinary call, a `::name` reference, and
a trailing-lambda call with no parens at all, which is how OpmlViewModel reaches importFrom.
It found one more thing, allowlisted with the reason rather than hidden: **on-device detection is
dead code.** FingerprintUpdater and MidrollUpdater are never constructed -- every reference from
outside their own files is a KDoc cross-reference -- and through them IntroOutroDetector,
AudioCorrelation, MidrollScanner, MidrollDetector, MidrollClipStore, MediaCodecClipSource,
Decimate, Fft, MonoResampler, PcmCodec, StoredClip and BreakTrack, about two thousand lines
shipped in every APK. The workers went when detection moved to the server; the classes stayed.
Deleting a subsystem is Peter's call, so it is recorded in the allowlist instead.
Two smaller things found on the way. EpisodeDownloader's wait notification went onto ServerAudio,
where the rest of the server's side of a download already lives, rather than becoming a seventh
constructor parameter -- and the first attempt added it *after* the `now` clock, which silently
rebound every existing trailing-lambda call site from the clock to the new hook while still
compiling. The UnusedImports rule enabled earlier today caught a stale import in this very commit.
1057 tests, detekt 0, lint clean, coverage 95.17% -> 95.29%. Checked on the emulator: the dialog
offers End of episode, and arming 15m shows "Sleep timer - 14:52" on the overflow entry.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The coverage gate excluded `**/ui/**` wholesale, justified as "Compose screens are impractical to
unit-test". It also hid six view models -- plain Kotlin classes holding real decisions, every one
at 0%, not one of them a screen -- behind a justification that only ever applied to screens.
PlayerViewModel and ListenViewModel were 150 lines of untested logic the gate could not see.
Done by a subagent; its coverage figure, test count and detekt result were re-derived here from
the XML rather than taken on trust, and its two findings checked against the source.
The exclusion now names each screen file instead of the package. All six view models go from 0%
to 92-99%, the measured `ui` package to 96.6%, and the project to **95.17% against a 94.44%
baseline** -- the gate passes with the exclusion narrowed and no COVERAGE_EXCEPTION. 96 new tests,
suite 951 -> 1048. The tests drive the real SubscriptionRepository, PlaybackAdvancer,
QueueRepository, DripReleaser and FeedResolver against the existing FakeDaos and MockWebServer, so
the banners asserted are the app's own wording rather than a stub agreeing with itself.
Four production seams, all behaviour-preserving: `UiGraph` and `ViewPreferences` over the graph,
`PlaybackControls` over PlayerConnection (the same shape as the `Playhead` precedent), and a
second constructor per view model with the `(Application)` one kept as a delegate. That last is
load-bearing in a way nothing would catch: `by viewModels()` finds a constructor reflectively, so
losing it throws on screen open with a green build and no failing test. ViewModelConstructionTest
is the guard. Its first version checked for the literal ": AndroidViewModel" and so missed
TranscriptViewModel, which wraps its supertype onto the next line -- a check that would have
passed while leaving a seventh view model unguarded in silence. It now cross-checks the two ways
of finding them against each other.
The action and state objects are excluded on a different ground from the screens, and the comment
says so explicitly so the list does not grow by analogy: they construct fine off a device, but
every line jacoco counts in them is one Kotlin generated -- constructor, componentN, copy, equals,
hashCode, toString. Measuring them measures the compiler. A data class that gains a method or an
init block comes back off the list.
Also, found while reviewing: detekt's `UnusedImports` rule is off by default, which is how 71 dead
imports accumulated across nine files. EpisodeActions.kt was eleven lines of data class under
forty of them -- Scaffold, SnackbarHost, LazyColumn and the rest, left behind when the screens
were split per file, which made it read like a screen. The rule is on and the 71 are gone. Two in
that file needed removing by hand: detekt whitelists `getValue`/`setValue` unconditionally because
it cannot tell a `by` delegation from none, and that file has no delegation at all.
1048 tests pass, detekt 0 findings on a fresh report, lint clean, coverage 95.17%.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Two things found by walking the queue screen, which was the one screen the UI pass had not
reached.
It was the only list in the app that went blank. Every other one explains itself when there is
nothing to show -- EmptyLibrary, EmptyBedtime, EmptyRules, the chapter list, the transcript -- but
removing the last episode from the queue left a back arrow, a title and nothing, which reads as a
screen that failed rather than one with nothing in it. Worse, the empty queue screen is only
reachable *by* emptying it: with nothing queued the library hides its Up Next heading and the
now-playing bar is absent, so there is no way in. Blank was therefore the only state that screen
ever showed after the last removal.
It now names the state and says where episodes come from, since none of the three ways in are on
that screen. Test written first and watched failing on the missing text, not on a compile error,
then confirmed green; then read back off the emulator by queueing an episode, opening the queue
and removing it.
The second is wording. The queue is called "Up Next" in the Android Auto browse tree, in the queue
screen's title, in the now-playing bar's icon and in the banner after queueing something -- and
"Up next" in the library heading directly above the row it describes. One name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
formatClock lived in NowPlayingBar.kt and had grown five callers across screens that share no
other code -- the transport, the break timeline, the chapter list, the sleep timer and the
transcript gutter. progressLabel, the one line under every episode title, lived in EpisodeRow.kt
and had three. Both are pure, neither is a view, and each file had defined its own
minutes-per-hour, so changing how the now-playing bar reads a position meant editing the
transcript gutter's formatter.
They are the last two holdouts from a rule this app already follows everywhere else: anything it
says out loud lives in a named file of its own and is tested, not inside the composable that
renders it. SkipSummary, RuleSummary, FoundBySummary, WaitingForServerText, DescriptionPreview
and SpeedChoices are all already arranged that way -- WaitingForServerText's own comment says
so. Compose screens are excluded from coverage, so wording left inside one is wording nothing
checks.
TimeText holds both formatters and one set of constants: formatClock for a position on the
transport, formatDuration for a length. They look similar and are not interchangeable -- 1:02:03
answers "where am I", 1h 2m answers "have I got time for this". EpisodeLabels holds progressLabel
and the release-date wording it uses.
Both had no test at all. The sixteen here were written against the old locations and confirmed
green *before* the move, so re-running them after it is what proves the move changed no
behaviour; written afterwards they would only prove the new code agrees with itself. They pin
the hour boundary from both sides, because everything in this library is under an hour except
the thing the app exists for, and the future-dated episode, which floors to zero days and would
otherwise read "today" for as long as it existed.
951 unit tests pass, detekt clean, coverage unchanged. The one line under an episode title was
read back off a device after the move: "20 Oct 2026 · 1h 20m".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Reviewing the transcript screen on a device: a wall of paragraphs with no times
in it. That undercuts the whole reason the screen exists -- finding the bit you
half-heard at twelve minutes -- and leaves a reader no sign that a line can be
tapped at all, since plain text suggests nothing.
A fixed gutter so the times form a column instead of ragging in and out with
the words beside them, wide enough for "1:02:03" so an hour-long episode does
not shunt the text sideways. Quieter than the words, because it orients rather
than being the thing read. Tapping it seeks, like tapping the words: the line is
one target.
formatClock rather than a fourth time formatter -- this app already had three.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Reviewing the settings screen on a device. The two switches did not line up with
each other: SwitchRow centred the switch against its whole text block, which
looks right while every label fits on one line and goes wrong the moment one
wraps. The second switch sat lower than the first for no reason a reader could
see. Top-aligned now, so the control is level with the first line of what it
controls whatever the text does.
"Race through breaks at 3x instead of skipping" was the label that wrapped.
"instead of skipping" is gone from it -- the detail underneath already draws
that contrast, in better words -- and the multiplication sign matches the speed
chip, which has always used one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Reviewing the episode screen on a device: the notes are cut at 140 characters
and the bottom three-fifths of the screen is empty.
The two-line rule was protecting something real -- long notes used to push the
transport off the screen. That reason went away when the player and episode
screens merged and the notes moved *below* the transport. Nothing is underneath
them now, so there is nothing left to push away, and the rule had been quietly
costing the screen ever since.
Ten lines, which is what the gap the old rule left behind would hold, and the
tap still opens the rest for anything longer.
Three tests failed on the change, all fixtures with the old budget baked into
their text -- "First. Second. Third." for "a third line is cut". Their intent
was always "more than the budget is cut", so they are now sized from the
constant and cannot rot the same way again. The case the old rule got wrong --
a description that fits the budget being shown whole -- is now a test of its
own.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
It matched `fun` at four spaces, so every `internal fun` on a helper object was
invisible to it -- which is most of what this app's UI layer exposes to its own
module. The guard that exists because findFeedLink and QueueRepository.advance
were written, tested, documented and never called could not see that whole
category.
It also credited only cross-file callers, so a helper called by its own object's
public entry point looked dead and needed an allowlist entry explaining that it
was not. Same-file callers now count, with declarations stripped first so a
function cannot find itself -- the trick the DAO half of this test already used.
Both together: a wider net and one fewer exception. The allowlist is down to a
single entry.
Watched failing on a deliberately dead `internal fun` before being kept, and
watched passing with the entry removed -- so the widening caught nothing that
was actually live.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Peter's framing: a few shows are news and stop being worth hearing within a day,
a tier he keeps up with, and a long tail that is not topical at all. It matters
because recognising one episode costs the server about five minutes, so a
five-hour back-catalogue episode arriving the same morning as the news takes
most of a cycle before the news is looked at.
Three tiers and no more. A number would invite fiddling and would not mean
anything; these are the three distinctions that were described.
The tier rides beside the subscription list rather than inside it, so a server
that knows nothing about tiers reads the list exactly as before and a phone that
knows nothing keeps pushing what it always did. Only the shows placed somewhere
other than the default are sent -- "ordinary" for sixty shows is the same
information as nothing, in sixty times the space.
It orders both the poll and the recognition queue. Recognition now sorts on
three things in the order they matter: a topical show first, then an episode
whose answer checks itself against the length gap, then newest.
**A tier only exists for a subscribed feed**, which a test caught: the list and
the tiers arrive in one push, and setting the tiers after the list put back a
placement for a feed that same push had just removed. A resubscription months
later would have inherited it.
Unrecognised tiers are ignored at both ends and read as the default, which is
the one that starves nothing -- the same rule the label store follows for a
verdict it does not know. Schema 20, migrated and checked on a device.
The control says what it does not do as well as what it does: nothing about
playback changes, and a show placed anywhere still plays, downloads and skips
identically. A setting that looks like it changes playback and does not is worse
than no setting.
The coverage gate caught the push body having no test, which was fair -- it is
hand-built JSON going over the wire, where a missing brace is a library that
silently stops being mirrored. Its exact output is now pinned, including a URL
with a quote in it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Three detectors now cut audio out of episodes and the app said nothing about
which. The listener judging a skip wants to know what judged it, and they are
not equally sure of themselves: one compares waveforms across a batch of
episodes, the other reads what was said and checks itself against the declared
length. A break both found is marked as both, because agreement by entirely
different means is the strongest thing either can offer.
"Found by the audio and the words", under the numbers and quieter than them --
it explains them rather than competing with them.
Schema 19. Existing rows default to the audio scan because that is where every
break in the database came from; the words could not produce one until this
week. "Unknown" would have been honest about the column and useless about the
rows. A server that says nothing gets the same default, for the same reason.
The coverage gate caught the new field's default never being exercised, which
was fair: every call site passes it, and the case it exists for is an episode
with nothing cut and nothing to account for.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Reported as "the play button, everywhere, should resume from the listened
position, not start over".
Every in-app surface was already correct, checked on a device before anything
was changed: the library row resumed a seeded 5:00 and played on from 5:07, the
episode screen showed "7m in" and labelled its button Resume, and both go
through PlaybackAdvancer, which is where this app decides where an episode
starts. So the bug was not in the resume rule.
Android Auto does not go through any of that. A Bluetooth button, the system's
resumption and the car all reach playback through the session callback, and that
path had only onAddMediaItems -- which turns a browse id into something playable
and says nothing about where in it to start. The player therefore began at zero.
It survived because it is wrong only where nobody developing the app presses
play.
onSetMediaItems now supplies the position, from PlaybackAdvancer, so the car and
the phone cannot drift apart on where an episode starts.
**The position is looked up from the items as they arrived, not the resolved
ones.** Resolution replaces a browse id with a playable item carrying the audio
URI, and the browse id does not survive it -- which is the whole reason
onGetItem exists. The first version read the resolved item, got null, and
resumed at zero: the same bug wearing a different hat. Found by logging it
rather than by reasoning about it, after the test kept failing with the fix in
place.
Pinned by MediaBrowseTest over the real session protocol, because the entire
defect lives in a boundary a direct call would skip. Watched failing with only
the production change stashed: expected 420000, was 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
A second ad detector, and it finds a class the first structurally cannot.
The audio scan compares episodes mirrored within a minute of each other, so
what it finds is advertising a CDN stitched into all of them -- validated
against the declared-versus-served length gap. A show that inserts nothing has
no gap, which by that measure means it carries no advertising, and the host-read
sponsor block in the middle of it is invisible. Every published transcript the
server can use belongs to exactly such a show, because having no inserted
advertising is the condition for using one. The two detectors do not merely fail
differently; they look at disjoint sets of episodes.
**Density, not phrases.** One marker is a mention. Measured against the 38
transcripts harvested from the live library: a single "brought to you by" is a
one-second tag inside play-by-play and skipping it would cut the game, and a
guest describing how a sponsor came forward for his yacht event says "sponsor"
four times while being the programme -- the same trap the toc=false chapter rule
already documents. A real read stacks different *kinds* of marker inside a few
seconds: who it is for, where to go, what the offer is, what the terms are. Two
kinds and fifteen seconds, the same ad unit the length-gap rule uses.
Every threshold comes from a measurement rather than a guess. The 25-second
bridge is the 17.7-second gap between "presented by Delta" and "12% off" in the
Seahawks Rewind read, with the product description in between. "Slash" needs a
domain in front of it because the corpus contains "a children's movie slash book
for adults".
Across all 38 live transcripts it reports **one** candidate: that Delta block,
41:07 to 41:33, with no programme clipped at either end. That is low recall by
design -- these are the shows with the least advertising, because they are the
only ones whose transcripts can be used at all. The shows with real ad breaks
need speech recognition, which is not built.
**Nothing is published as a skip.** The candidates are stored with the words and
the lines are dimmed on the transcript screen, so the reader can see what the
server thinks is an advertisement and disagree with it. Dimmed rather than
hidden, because a wrong call has to stay visible. Nothing in the playback path
reads them -- same posture as the signature library's shadow run, and the same
reason: a detector acting on its own unchecked first guesses makes skips into
the middle of the programme, which is worse than no skips.
Schema 18 adds the mark to the cue, defaulting to not: a line nobody judged is
not an advertisement. Migrated and checked on a device.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The ⋮ menu gains Transcript, which opens the episode's lines with the one being
spoken in bold and the list following the playhead. Tapping a line seeks to it,
which is the thing anybody actually wants a transcript for -- finding the bit
you half-heard.
It is also why the server refuses a publisher's transcript for an ad-inserted
copy. Tap a line in a transcript of the ad-free master and the audio starts
minutes from where the words are.
The words arrive with the audio rather than when the screen opens. The point of
downloading is that the episode works with no network, and a transcript fetched
on opening is blank on a plane or in a car park, which is where this app is used.
Tens of kilobytes beside tens of megabytes.
One row per cue, not a JSON column. Android reads every Room row through a
CursorWindow that refuses a row over 2MB *on the way out* -- the insert succeeds
and the next read throws -- which is exactly how the oversized pendingClipPcm
crashed the app on every show's second fingerprinted episode. A three-hour
episode is thousands of cues, so one column holding them all is that bug with a
different name. Both tables cascade from the episode. Schema 17, migrated and
checked on a device, including that deleting an episode takes its words.
Three states again, kept apart: words to read, a recorded reason there are none
-- the server looked at the publisher's transcript and would not use it for this
copy -- and nobody having looked. The menu offers the entry for the first two
and the screen says something different for each.
TranscriptSyncing holds the highlighting, apart from the screen and tested,
because the way this goes wrong is quiet: a highlight on the line before or
after the one being spoken looks right at a glance and is useless to read along
with. It holds the last line through a gap rather than flicking off during
silence or music, and highlights nothing before the first line, since an episode
opening on theme music has not said anything yet.
Verified end to end against a real feed before committing, on a throwaway data
directory: Wards Way Podcast mirrored, both episodes' transcripts taken, and the
API served 748 cues whose last one ends 466ms before the measured file does.
Transcripts live on their own view model rather than two more functions on
ListenViewModel, which was already at the size the linter allows -- same call as
splitting Screens.kt, and they have a different lifetime anyway.
The coverage gate caught the replace transaction having no direct test, which
was fair: its clear-then-insert ordering is the thing that would leave a reader
looking at an empty list under a header counting lines.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Two follow-up findings on the same file, both real.
**A proxy would have made the whole check pointless.** http.DefaultTransport
carries ProxyFromEnvironment, so with HTTP_PROXY set the connection goes to the
proxy and the proxy connects to whatever the URL named -- the address being
checked would be the proxy's, and the one that matters would never be looked at.
The safe client now sets no proxy, and a test asserts it.
**"Not RFC 1918" is not the same as "public".** The check is now an allowlist:
an ordinary global unicast address that is not in an IANA special-purpose range.
The ranges that were being let through include 100.64.0.0/10, which is
carrier-grade NAT and routes to a real host on a real network, and 64:ff9b::/96
and 2002::/16, which are NAT64 and 6to4 and carry an IPv4 address inside them --
127.0.0.1 included. None is private by Go's definition and none is somewhere a
podcast is served from.
Checked against the live library before committing: 130 real URLs -- all 44
feeds and two enclosures from every show -- resolve to addresses this permits,
so nothing Peter subscribes to stops mirroring. That check is kept as a test
which skips where the state file is not present, because the failure mode of
being too strict is a feed that silently stops updating.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The dot said only whether anything was waiting. The count beside the title says
that and says how much, so the dot was the row's least informative element
sitting in its most prominent position.
The artwork spans both lines, which is what makes it read as belonging to the
show rather than to the episode named underneath it, and it carries the
caught-up dimming with the rest of the row.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Three things Peter reported about the podcast list.
**A slow-drip show sorted on episodes it was hiding.** The library's count and
its sort key were computed from every unplayed, unqueued episode, released or
not, so New Yorker Fiction ranked near the top on a brand-new episode drip had
not handed out yet -- a show with nothing visible sitting above shows with
something to hear. Both halves now apply the same released-set the show screen
shows. The count was wrong in the same way and for the same reason, so it moves
with it.
**The row now names the one episode you would actually play**, under the show's
name and in a quieter style, with the same Play, Queue and Download controls the
episode list offers. The show stays the focus: this is a list of shows, and an
episode offering different actions depending on which screen you found it on
would be two features wearing one name. `observeNewestWaiting` sits beside
`observeAll` because the two must agree on what "waiting" means -- a row that
offered an episode the count excludes would be offering something the show
claims not to have.
**Android Auto lists shows in the library's order now.** It was sorted, but
alphabetically, which is a different order from the phone's and so reads as no
order at all. `getBrowsable` is gone rather than reordered: the callback reads
`observeAll` directly, so there is one definition of what the library contains
and what order it is in, and the car cannot drift from the phone again.
Alphabetical was also wrong on its own merits -- the car hides played episodes,
so a show you are caught up on browses as an empty list, and burying the ones
with something to hear among them is exactly what a driver can do nothing about
at a traffic light.
Pinned by `MediaBrowseTest.theCarListsShowsNewestWaitingFirst`, which walks the
real session protocol and failed on alphabetical order before the change, five
new drip cases and five newest-waiting cases in `LibraryOrderTest` against a
real database, and `LibraryRowTest`, which drives the row as a composable
because a row offering the wrong episode's controls looks exactly like one
offering the right episode's.
`LibraryScreen.kt` split rather than relaxing detekt again, same call as
`Screens.kt`: the row and its parts are now `SubscriptionRow.kt`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The dependencies for this were already in the build -- ui-test-junit4
on androidTest, ui-test-manifest on debug -- and had never been used.
So the spike was one test, and it passed first run. Eighteen now.
What they cover is the data-driven composables, chosen because a
regression in them looks completely normal: a readout that quietly
stops printing one of its three numbers, a control that stops
reporting whether it will play or pause, a bar that stops naming what
is playing while a screen shows something else.
The episode transport: the ad button is offered only while something
is playing, because with nothing playing there is no advertising to be
in the middle of and an enabled button would record a claim about a
position nobody is at. The primary control says what pressing it will
do. The skip buttons move by the amount they advertise.
The skip readout: all three numbers on one line, the status when there
is nothing to cut -- "nothing found" and "not checked yet" being
different answers is the mistake the old readout made -- and a legend
that names only what is actually on the track.
The now-playing bar: names the episode and the show, opens what is
playing when tapped, and reports play against pause.
Screens that need view models are still verified by eye. This is the
half that did not need them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
401 and 403 are permanent by decision -- a refused token cannot fix
itself -- and the notice saying so was held in memory. So it vanished
with the process and only came back once the next refresh had gone and
been refused all over again, which for 61 feeds is hours of the app
quietly downloading from publishers with nothing on screen to say why.
It now lives in the preferences file and is there at launch.
Saving different credentials clears it at once rather than waiting for
a request to prove it, because that is the one act that answers the
complaint. Saving the same ones again proves nothing and leaves the
notice standing.
Behind a small interface so SkipServer does not have to know whether
it is writing to a preferences file or to nothing: every test wants it
in memory, without a Context to hang a DataStore off.
The stored one takes the reading and the writing as two narrow seams
rather than a Preferences. Passing Preferences dragged a Context in
and made it the one piece of the server client that could only be
exercised on a device -- the coverage gate caught that, which is what
it is for. What it actually decides, when *not* to write, is now plain
Kotlin with five tests on it: clearing runs after every successful
reply, so two hundred successes in a sweep must write nothing.
Verified on a device: a refusal written by one Preferences instance is
read back by another, and four cases around saving credentials behave
as described.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Peter: "combining the player and episode screens is weird. Now I end
up with a different episode playing than shown because it doesn't
follow what's playing. And there should be an ad skip button in the
player."
Both are consequences of the merge rather than arguments against it.
The screen is the player now, so when the queue advanced the screen
stayed on the episode that had finished -- and its transport then
belonged to an episode nobody was listening to, so pressing play there
would restart it over the one that was.
It follows only when it was already showing the playing episode.
Opening an older episode while something else plays is a deliberate
act, and a screen that snatched itself away mid-read would be a worse
bug than this one. The route argument could not answer it alone: the
queue advances with no navigation at all.
The ad button sends the same session command the notification button
sends rather than reimplementing it. That gesture is four meanings
deep -- press, press again, come back inside the jump, come back past
it -- and two copies of it would drift. It carries the same
circle-and-slash so the two read as one control in two places. It is
on the episode screen for the same reason it is on the notification:
detection accounts for roughly 38% of the advertising the feeds imply,
so most of what gets heard was never found.
Verified on the emulator with two twenty-second episodes queued: the
screen was showing the first, playback reached its end, and the screen
moved to the second on its own.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Step 4 of the UI redesign, and the last of it.
The library is one list rather than a list plus a card. Up Next is a
heading and a row, lining up with the rows under Shows instead of
sitting in a bordered box above them. A show row is a dot, a title and
a count: forty-three shows is a list to scan, not a shelf to browse,
and the one thing worth seeing per row is whether there is anything in
it. The count is new -- the query had already counted it to do the
ordering and was collapsing it to a boolean on the way out, so the
screen said "something waiting" where it could say "four".
Settings is three groups ordered by how often they are touched.
Skipping first, because it is what is actively being tuned. The build
hash drops to the bottom under About, rather than sitting between the
automation rules and the subscriptions at equal weight.
Two things left Settings. Playback speed was already a tap on the
episode screen, so the permanent row of chips was a second way to do
one thing. The sleep timer moved to the episode overflow, where every
other secondary playback action went in step 3 -- it is not a setting,
it is something you do once, while listening, usually in the dark. The
entry shows the time remaining, which is the only question anyone has
about a timer they set in the dark.
The reachability test earned its keep here: dropping the speed section
orphaned PlayerViewModel.setSpeed, which it reported as a feature no
screen could reach. It was genuinely superseded -- setSpeedFor
persists the choice per show and applies it -- so it is deleted rather
than given a new home.
Verified on the emulator, which is the only way Compose gets verified
here: the library renders dots, counts and a dimmed errored feed; the
three settings groups read in order; and the sleep timer arms from the
overflow and then reports "Sleep timer - 29:51".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The phone has had two kinds of label and nowhere to put them: a mark,
which is a judgement on a break detection found, and a report, which
is the notification button pointing at advertising it missed. They
catch opposite errors, and the signature library needs both.
POST /api/labels now takes them and state.json keeps them. Episodes
are named by feed and guid rather than by either side's own id -- the
phone never sees the server's, and the server's belongs to a mirror
that forgets an episode after eight. The labels sit beside the shows
rather than on them for the same reason: the corpus has to outlive the
audio it was given on.
A report's end is sent as guessed or measured. It is only measured
once the listener came back and trimmed it; otherwise it is wherever
the jump landed, and a signature cut to that would carry programme.
The phone re-sends everything each sweep and keeps no record of what
arrived. The server replaces rather than accumulating, so a re-send is
free, there is no sync state to get wrong, and a label lost to a crash
comes back on the next refresh. Gated on audioFromServer, like every
other server re-query: a label names a position in a particular file,
and dynamic ad insertion means the publisher's copy is a different one.
Accepting a label writes the state file immediately. Everything else
is written at the end of a poll cycle, which for 61 feeds is hours,
and a tap made once should not wait that long to become durable.
Deployed and checked against the live server: a label is accepted, a
re-send leaves one, an unauthenticated POST gets 401, and the label is
on disk within seconds. The probe label used for that check was
removed afterwards.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The "this is an ad" press jumped 45 seconds, a number argued from
ad-unit arithmetic rather than from the controls that already exist.
Peter: "the jump should stay 25 seconds. Don't go inventing new
timing."
Skipping forward is already what you do to an advertisement, so the
button goes the same distance and additionally says why. One number to
know, and a second press goes the same distance again.
The amount had three definitions already -- the player's increments,
the episode screen's transport buttons, and the notification caption's
hardcoded "Forward 25 seconds" -- and this nearly became a fourth with
a different value. They now all read one, and the captions are derived
from it so a caption cannot name a number its button does not do.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The notification carried four buttons doing two jobs: Media3's default
previous/next (which PodcastPlayer redefines as seek) plus our own
back-15/forward-25 pair. Media button preferences with explicit slots
let the custom pair claim the two seek slots, so the duplicates go and
the freed space carries "this is an ad". No player command is removed
to achieve it, which is the route that once silently killed the
headphone skip button.
One press means four things, told apart by where the playhead lands
rather than by guessing: press claims advertising from here and jumps
past it, pressing again extends the same claim, coming back inside the
jump moves its end to where you landed, and coming back past the press
withdraws it. Outside a 20-second window a seek is ordinary navigation
and says nothing. The window is stored with the label so changing it
later cannot reinterpret old data.
Every backwards seek feeds the gesture, whatever caused it --
notification, headphone remote, in-app bar, dragged slider -- because
you correct with whatever is to hand.
This is the opposite evidence to the tap-a-break popup. That one can
only correct breaks detection already found, and detection accounts for
about 38% of the advertising the feeds imply.
Verified on the emulator: the notification now shows exactly back-15,
pause, forward-25 and the new button; the lock screen shows it too and
pressing it there records a claim without unlocking; all four gesture
arms behave as specified; and the media transport keys still seek by
25s and 15s. Android Auto still needs the car.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Keeps partners on episode_midrolls (schema 15), stores verdicts in their own
break_verdicts table so a server refresh cannot wipe them, and drops invalidated
breaks from skipping on the next tick. Verdicts are local only.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The top bar now names the show (from the already-loaded subscriptions
list, "Episode" if unknown) and the body keeps the episode title, wrapping
to two lines. Chapters are no longer fetched when the screen opens; the
overflow offers the entry whenever a chapters URL exists and the dialog
fetches (cached) on open, saying so if the file is empty. Playback's
ad-chapter path (PlaybackAdvancer/PlaybackSources) is untouched.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Opening an episode now puts you in its transport at the stored position;
pressing play changes nothing about the layout. One primary control
(Play/Resume/Pause) with back/forward, a speed chip that opens the four
offered speeds (stored 1.5/1.75 still play and are named on the chip),
and everything secondary behind a top-bar overflow: queue, download,
played, watch, mark-older, chapters, and the publisher-copy action
(behind a dialog carrying its warning). Description shows about two
lines, the rest on tap.
The now-playing bar, library bar, queue, share receiver and nav graph
all open the playing episode's screen. PlayerViewModel stays the single
owner of playback state; no playback decision moved into the UI.
PlayerScreen.kt and WatchButton.kt are deleted. Coverage drop, if any,
is from removing covered dead code.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
Served / declared / cut on one line, a two-colour legend, and marks on the
track that name themselves and seek when tapped. The per-break list and the
permanent-None intro/outro rows are gone.
Coverage: dropped 94.23 -> 94.15 because covered readout code was deleted.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
HTTP 401/403 from the skip server now downloads the publisher's copy at once
(audioFromServer=false), as if no server were configured. Unreachable, timeout,
404, 5xx, unparseable and pending still wait. The transport reports Body /
Rejected / NoAnswer and makes no decisions. The rejection is remembered (from
episode requests and pushSubscriptions) and shown in the skip-server settings
until a different token is saved or a request succeeds.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
With a skip server configured, a podcast episode it cannot supply yet (pending,
unreachable, bad answer, or audio that fails) now enters WAITING_FOR_SERVER and is
retried on every refresh, instead of falling back to the publisher's differently-ad-
inserted file. Taking the publisher's copy is an explicit action on the episode screen
that sets audioFromServer=false. No server configured, YouTube/Facebook and unresolvable
feeds still download directly. No schema change: downloadState is stored by name as TEXT.
detekt: EpisodeDao and ListenViewModel function-count thresholds raised by one (rationale
in detekt.yml).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The sweep awaited each episode's server query sequentially, and it runs on
every refresh including the library button. Several hundred downloaded
episodes meant a tap that used to take seconds took minutes, and under
WorkManager it risked being killed partway -- the same shape as the
ten-minute ceiling that stopped FingerprintWorker ever confirming.
Six at a time, through a semaphore inside the call's own coroutineScope so
nothing escapes to a background dispatcher. Per-episode failure isolation
is unchanged; CancellationException is rethrown rather than caught, the
bug already fixed once in skipFurniture().
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
publisher audio
A feed refresh never re-asked the skip server for already-downloaded episodes, so
detection improvements only ever reached a show by deleting and redownloading it.
Fixing that safely needs to know which episodes are safe to re-query: a show using
dynamic ad insertion serves a different file on every request, so a server-measured
offset only applies to the server's own copy, not whatever the publisher fallback
left on disk.
- EpisodeEntity.audioFromServer (schema 13->14, MIGRATION_13_14) records which source
actually landed; EpisodeDownloader sets it, defaulting to false everywhere else so a
requeue, retention reclaim or failed re-download clears a stale claim the same way
they already clear localPath.
- New SkipRefresher re-queries downloaded, server-sourced episodes via the existing
ServerSkips.resolve/record pair, one episode's failure not blocking the rest. Wired
into SubscriptionRepository.refreshAll via a new refreshSkips collaborator -- the
choke point every refresh route passes through, including the library's refresh
button.
- SkipSummary's episode screen readout gets a distinct line for a download that can
never be refreshed in place, instead of the misleading "Not checked yet".
Migration verified on-device (gradle-verify connectedDebugAndroidTest, MigrationTest:
14/14). Full connected suite: 31/31. Unit suite: 682/682. detekt/lint clean; coverage
93.86% against a 93.85% baseline.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
|
The toggle chooses what happens to whatever is being cut; the switch above
it chooses what that is. With both on it races through the show's own
intro and credits too, so labelling it "ads" undersells it. Caught in
review -- the labels are the only explanation this feature ever gives.
|
|
The artwork spanned y 46..80 (centre 63) against the 108dp canvas's
own centre of 54 -- 9dp too low, as measured. Shifted every y
coordinate in ic_launcher_foreground.xml up by 9: the arc's M and A
commands, and the M of each earcup path (the rest of each path is
relative, so only the start point needed to move). Now spans y
37..71, centre 54, matching the horizontal centre and well inside
the adaptive icon's 18..90 safe zone. ic_launcher.xml and
ic_launcher_round.xml both reference this one drawable, so no other
file needed a change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AwnALZL6bD4VBtATDVv3B
|
