I understand that there is a workaround, yes, but the podcast item type really _should_ have a date if it's going to exist at all. I don't want to talk more about the workaround because it's been covered already. I just want to know when – or if – it will be fixed to make the workaround unnecessary. Thank you.
Just adding my vote to this feature request ; ) and my 2 cents...
A Date field is a must to make things simple.
Also, Often times, Podcasts have a Title for "The Show" itself and then every episode also has a Title. So, having a "Podcast Title" (show) and an "Episode Title" is a good idea.
I know there is "Series Title", but that could well refer to another layer of abstraction as many Episodes of the same "Show" could belong to a series of episodes on the same topic.
Upgrade Storage
I understand that there is a workaround, yes, but the podcast item type really _should_ have a date if it's going to exist at all. I don't want to talk more about the workaround because it's been covered already. I just want to know when – or if – it will be fixed to make the workaround unnecessary. Thank you.
A Date field is a must to make things simple.
Also, Often times, Podcasts have a Title for "The Show" itself and then every episode also has a Title. So, having a "Podcast Title" (show) and an "Episode Title" is a good idea.
I know there is "Series Title", but that could well refer to another layer of abstraction as many Episodes of the same "Show" could belong to a series of episodes on the same topic.
Issued: 2020-12-18
Container title: Podcast title
When proper fields for these are added, those will be migrated automatically