A simple library providing programmatic access to the iTunes search API for podcasts.

Love the ease of use on the library. Was hoping to get individual image URL if present added to the list too (or am I doing something wrong that I cannot pick it up?). I think I traced it down to :

episodes.add(Episode.of(
          item.guid,
          item.title,
          item.description,
          item.link,
          Utils.parseRFC2822Date(item.pubDate),
          item.author ?? item.itunes.author,
          item.itunes?.duration,
          item.enclosure?.url,
          item.itunes?.season,
          item.itunes?.episode));

Do let me know if this is possible, please. If you have any suggestions otherwise, I am keen to learn that too.

The RSS parser is looking for either an <author> or <itunes:author> tag in the RSS feed as the channel author; however, <author> is an item level tag which can result in the wrong author begin returned for the podcast.

To reproduce this, load a podcast that uses item level authors such as 'What Is Money?':

https://feeds.simplecast.com/MLdpYXYI

This PR adds the "value" tag to podcast item search result as specified by podcast index 2.0 schema (https://github.com/Podcastindex-org/podcast-namespace). The value tag defines the payment model of the item and supports lightning payments. In addition I have modified the _buildSearchUrl method of PodcastIndexSearch to buildSearchUrl so it can be reused by only changing the url and demonstrated a way to use a custom search provider via a unit test. The option of custom search provider is useful when the caller wants to use different API endpoints to search using podcast index and my intention is to use such custom provider when using anytime podcast app as a dependency inside Breez while I am avoiding significant changes to the low level library.

This PR implements "charts" API for podcast index using trending call. In order to filter trending results the charts API was also modified to get additional query parameters that will be passed to podcast index endpoint. Specifically in Breez we would like to use it to filter those that can be used with lightning payments and for that purpose we will pass "val":"lightning" filter as introduced in the additional test I added. Also a small fix for default 'lastUpdatedTime' was added.

I am getting this error after using the example provided. I have checked for internet connection of my device and it seems this library is the only one having issues.

I think it is more accurate to get the author from the 'author' property. Also from my research it is always returned in podcast index various search API while ownerName isn't.

My question is just that, can the top podcasts be paginated? I don't think podcast_search should take care of the pagination aspect but can we just pass in an offset variable that can be used to get a specific page?

I couldn't find any documentation of that top podcasts api from itunes online so I couldn't confirm if this is even possible? Can you please look this up and let me know? Because it'd be much more useful to get a paginated response from itunes which I can directly use in my app.

Hi, At line 295 of model/podcast.dart, you assert that item.pubDate is not null [assignment of Episode.publicationDate as Utils.parseRFC2822Date(item.pubDate!),], but the specification indicates that "<pubDate> is an optional sub-element of <item>." See https://validator.w3.org/feed/docs/rss2.html#hrelementsOfLtitemgt

https://github.com/amugofjava/podcast_search/blob/026b5b7c54b7c24934f7941feae44ad342c9317d/lib/src/model/podcast.dart#L295

When the code encounters this, it throws an exception when pubDate is not present on an item.

The feeds I am having trouble with publish a DublinCore dc:date field for each item, and the W3C RSS validator recommends that a feed only include one of dc:date and pubDate, since there is no official precedence between the fields.

Thanks!

The chapters parser will return an empty set of chapters if the JSON file does not match the spec exactly. Whilst chapters should match the spec the parser needs to be tollerant of small variations; specifically handling JSON files that are reported as text/plain rather than application/json and handling numerical time values that are presented as a String.