Summary
--start-date / --end-date are silently ignored for podcast episodes whenever a parent podcast's episode_count does not match the number of episodes the library endpoint returns. The episodes are then fetched through Catalog.from_api(), which applies no date filtering at all — so the bounds have no effect and no warning is emitted.
This is the quiet counterpart to #264. That one crashed loudly; this one returns a wrong result set that looks correct.
Root cause
BaseItem.get_child_items() first fetches children through the library endpoint, which does honour the date bounds:
https://github.com/mkb79/audible-cli/blob/master/src/audible_cli/models.py#L224-L227
If the resulting count differs from episode_count, it re-fetches everything through the catalog endpoint instead — passing the original request_params, which still contain start_date / end_date:
https://github.com/mkb79/audible-cli/blob/master/src/audible_cli/models.py#L229-L238
Catalog.from_api() has no start_date / end_date parameters. The values therefore land in **request_params, are forwarded verbatim as query parameters to catalog/products (models.py:682), and the response is returned without any local filtering (models.py:691). Two things go wrong at once:
- Two non-API query parameters are sent to
catalog/products.
filter_by_date() never runs on the result, so every episode is kept regardless of the bounds.
The comment at models.py:531 states that "the end date will be filtered by the resolve_podcasts function later", but Library.resolve_podcasts() (models.py:626) only gathers get_child_items() results and extends the list — it performs no date filtering of its own. So for parent podcasts the bound is intentionally deferred to a step that never applies it.
Impact
Measured against a real account (168 top-level items, 2 parent podcasts) with --start-date 2008-01-01:
Podcast B0C7LLTQ6H: episode_count=10 library endpoint (filtered) -> 8 -> fallback taken
Podcast B08JKR2GYB: episode_count=734 library endpoint (filtered) -> 10 -> fallback taken
Catalog.from_api -> 734 -> unfiltered
Both podcasts trigger the fallback, so 744 of 744 episodes bypass the date filter. The date bounds are completely ineffective for podcast episodes on this account, silently.
Note the count mismatch is the normal case, not an edge case: the library endpoint only returns episodes actually in the library, while episode_count counts all episodes of the podcast. Any podcast where those differ — including every podcast whose episodes were correctly filtered out by the date bound — takes the fallback.
Reproduce
audible library list --resolve-podcasts --start-date 2008-01-01
with a library containing a podcast whose episode_count differs from the number of its episodes in the library. Episodes outside the date range appear in the output.
Open design question
Catalog items carry neither purchase_date nor library_status, so filter_by_date() cannot be applied to them as-is. On the account measured above all 744 catalog episodes had purchase_date = None and library_status = None; the only date field present was publication_datetime.
That is semantically a different thing: --start-date is documented as "books added to library on or after this UTC date", not published on or after. Filtering catalog results by publication_datetime would silently change the meaning of the option for podcasts.
Possible directions, needs a decision before implementing:
- Filter the catalog results by
publication_datetime and document the deviation for podcast episodes.
- Keep the library-endpoint result when date bounds are set and skip the
episode_count fallback entirely, accepting that episodes not in the library are not listed.
- Fetch unfiltered via catalog, then intersect with the date-filtered library result to recover a real "date added" per episode.
At minimum the bounds should be stripped from the parameters sent to catalog/products, and the fallback should log that date filtering does not apply, rather than silently returning everything.
Related
Summary
--start-date/--end-dateare silently ignored for podcast episodes whenever a parent podcast'sepisode_countdoes not match the number of episodes the library endpoint returns. The episodes are then fetched throughCatalog.from_api(), which applies no date filtering at all — so the bounds have no effect and no warning is emitted.This is the quiet counterpart to #264. That one crashed loudly; this one returns a wrong result set that looks correct.
Root cause
BaseItem.get_child_items()first fetches children through the library endpoint, which does honour the date bounds:https://github.com/mkb79/audible-cli/blob/master/src/audible_cli/models.py#L224-L227
If the resulting count differs from
episode_count, it re-fetches everything through the catalog endpoint instead — passing the originalrequest_params, which still containstart_date/end_date:https://github.com/mkb79/audible-cli/blob/master/src/audible_cli/models.py#L229-L238
Catalog.from_api()has nostart_date/end_dateparameters. The values therefore land in**request_params, are forwarded verbatim as query parameters tocatalog/products(models.py:682), and the response is returned without any local filtering (models.py:691). Two things go wrong at once:catalog/products.filter_by_date()never runs on the result, so every episode is kept regardless of the bounds.The comment at
models.py:531states that "the end date will be filtered by the resolve_podcasts function later", butLibrary.resolve_podcasts()(models.py:626) only gathersget_child_items()results and extends the list — it performs no date filtering of its own. So for parent podcasts the bound is intentionally deferred to a step that never applies it.Impact
Measured against a real account (168 top-level items, 2 parent podcasts) with
--start-date 2008-01-01:Both podcasts trigger the fallback, so 744 of 744 episodes bypass the date filter. The date bounds are completely ineffective for podcast episodes on this account, silently.
Note the count mismatch is the normal case, not an edge case: the library endpoint only returns episodes actually in the library, while
episode_countcounts all episodes of the podcast. Any podcast where those differ — including every podcast whose episodes were correctly filtered out by the date bound — takes the fallback.Reproduce
with a library containing a podcast whose
episode_countdiffers from the number of its episodes in the library. Episodes outside the date range appear in the output.Open design question
Catalog items carry neither
purchase_datenorlibrary_status, sofilter_by_date()cannot be applied to them as-is. On the account measured above all 744 catalog episodes hadpurchase_date = Noneandlibrary_status = None; the only date field present waspublication_datetime.That is semantically a different thing:
--start-dateis documented as "books added to library on or after this UTC date", not published on or after. Filtering catalog results bypublication_datetimewould silently change the meaning of the option for podcasts.Possible directions, needs a decision before implementing:
publication_datetimeand document the deviation for podcast episodes.episode_countfallback entirely, accepting that episodes not in the library are not listed.At minimum the bounds should be stripped from the parameters sent to
catalog/products, and the fallback should log that date filtering does not apply, rather than silently returning everything.Related