Add both description and encoded content fields when retrieving episodes

[welsh11]

I had a look at the source for the partytime parser and it seems that when creating the 'description' field, it uses the rss description first and then falls back to using content:encoded otherwise.

Often, podcasters will use both of these, with a plain text, shorter description in the description field, and the long form show notes in the content:encoded field.

It would be useful to have both of these.

I know that the encoded content could be long, so is probably not a good fit for the episode list APIs, but could it possibly be added to the episodes/byid endpoint as an optional flag?

Thanks for the great work!

[daveajones]

Can you give me an example podcast showing what you mean? I’ll look into it and see what makes sense. The episodes table is enormous (over 50 million episodes), so any text fields added have the potential to blow that size out of the water so it has to be done with care.

[welsh11]

Hi Dave,
Yeah, so a lot of the RelayFM shows follow this pattern, Connected is an example:
Connected

I can image that table is huge. The way I am currently dealing with it is to cache the 'show notes' in a separate table in the back end when someone subscribes.

Not a biggie for me, but something to be aware of.

[daveajones]

Thanks for the example. Let me dig into it and see. I'm actually in the aggregator code right now looking at some other stuff.