rss-bridge
rss-bridge copied to clipboard
[MrssFormat] Add 'itunes:duration' tag for items with duration
Some bridges have items which are links to media. The media linked typically has a duration. Add a 'duration' property for FeedItems and use its contents (if not empty) to add an 'itunes:duration' tag to Mrss output. This allows feed readers (podcast clients) to read the duration of the episode, and allows sorting and searching episodes by their length.
Patch Arte7Bridge to add the duration to items as an example. I'm sure there are also other bridges which can use this property.
Pull request artifacts
file | last change |
---|---|
Arte7-current-context1 |
2022-06-10, 20:04:37 |
Arte7-current-context2 |
2022-06-10, 20:04:37 |
Arte7-pr-context1 |
2022-06-10, 20:04:37 |
Arte7-pr-context2 |
2022-06-10, 20:04:37 |
Our rss format is extended with mrss[0] which supports duration attribute on the enclosures. Maybe we should use that instead?
[0] https://www.rssboard.org/media-rss#media-content
Our rss format is extended with mrss[0] which supports duration attribute on the enclosures. Maybe we should use that instead?
I thought about that, but for example in the Arte bridge, the links are not pointing directly to media files. According to the spec you cited, the media:content
tag must have either an url
attribute pointing to the media file, or a media:player
tag must be present. Something like this would probably satisfy the MRSS spec:
<media:content duration="123"/>
<media:player url="http://www.arte.tv/blah"/>
I've seen plenty of RSS files with media:content
without an URL though, and the podcast clients I care about parse the itunes:duration
tag, so I would like it to stay.
Rebased to master with the namespace fix. Works now, but tests are still failing/missing. Sorry for the buggy pushes previously.
What if we create an iTunes/podcast format?
I do not think a new format is necessary – XML is quite compositional so it does not really matter if we include extra elements from separate namespace and agents will just ignore those they do not support. We already add MRSS elements to both AtomFormat
and MrssFormat
.
I'm not sure I like the growing list of item parameters, especially this one which only applies to some formats.
Agreed. I think deciding on the data model that we will use going forward is essential.
This PR adds the duration field to FeedItem
but, reading JSON Feed spec, we might actually want to create an Enclosure
class and specify duration on that. That would work well with JSON feed as well as Media RSS.
The MrssFormat
could then insert `itunes:duration attribute if there is a singular enclosure and has duration specified.
If readers won't detect this without the namespace declaration at the top, we can add that.
The namespace prefixes (i.e. the part of attribute name before the colon) carry no meaning (mostly) and no properly written agent (that is, one using a XML parser) will work without namespace URI mapped.
Maybe the Mrss format should add
<key>value</key>
for each key=>value in FeedItem::misc. Then this can be implemented with just$item['itunes:duration'] = $duration;
in the bridge definition.
That feels a bit too hacky. It will only work for direct children of item
that store the value as a child, will be too easy to produce invalid feeds (adding elements that do not belong), and it would not cover other Format
s.
An alternative might be to have BridgeInterface::modifyItemFormat(class-name $format, FeedItem $item, T& $itemElement): void
method that would allow the bridge to fully control each format but that would probably be too clunky.
Rich FeedItem
+Enclosure
model still sounds like the best option to me.
Thanks for the detailed response. I agree with your analysis. It's probably best to add an Enclosure class that has a duration property.
I prefer this solution in bridges:
$item['enclosures'] => [
[
'url' => 'https://example.com/1.mp3',
'duration' => 234234,
'explicit' => true,
]
],
The implementation is left as an exercise for the reader.
So currently, enclosures/attachments are defined by a string (url). I suggest we migrate to defined them as arrays instead.
Existing strings can can be converted to arrays: 'http://example.com/1.mp3' -> ['url' => 'http://example.com/1.mp3']
.
If the enclosures has a single element and a duration, we can ad the ns namespace. The other formats should be integrated too. I think we can use the itunes ns in both atom and rss.
this one is still relevant for podcast consumers. for op is was for arte7 bridge. what other bridges is this relevant for?
@tpikonen
this one is still relevant for podcast consumers. for op is was for arte7 bridge. what other bridges is this relevant for?
@tpikonen
At least ARD Audiothek and ARD Mediathek surly would benefit from it. And I was thinking about writting a bridge for BBC Sounds, but right now there is no way to create a a fully working feed for podcast apps. I was thinking about implementing an "ITunes" format, but that doesn't seem to be possible without more general changes to support more variables?
By the way, not only the 'itunes:duration' tag is missing. Serveral other ones should be implemented. It seems to be common to use itunes-tag for almost all fields and include the standard ones mainly for compatibility reasons. I think it would be best to include both types in a new format.
see https://github.com/RSS-Bridge/rss-bridge/pull/3759
@tpikonen
fixed in https://github.com/RSS-Bridge/rss-bridge/pull/3759