rss-bridge icon indicating copy to clipboard operation
rss-bridge copied to clipboard

[MrssFormat] Add 'itunes:duration' tag for items with duration

Open tpikonen opened this issue 2 years ago • 8 comments

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.

tpikonen avatar Jun 09 '22 11:06 tpikonen

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

github-actions[bot] avatar Jun 09 '22 11:06 github-actions[bot]

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

dvikan avatar Jun 09 '22 14:06 dvikan

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.

tpikonen avatar Jun 09 '22 16:06 tpikonen

Rebased to master with the namespace fix. Works now, but tests are still failing/missing. Sorry for the buggy pushes previously.

tpikonen avatar Jun 10 '22 20:06 tpikonen

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 Formats.

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.

jtojnar avatar Jun 10 '22 23:06 jtojnar

Thanks for the detailed response. I agree with your analysis. It's probably best to add an Enclosure class that has a duration property.

yamanq avatar Jun 13 '22 07:06 yamanq

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.

dvikan avatar Jun 24 '22 08:06 dvikan

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.

dvikan avatar Jul 04 '22 06:07 dvikan

this one is still relevant for podcast consumers. for op is was for arte7 bridge. what other bridges is this relevant for?

@tpikonen

dvikan avatar Jul 06 '23 12:07 dvikan

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?

Gabriel85 avatar Sep 12 '23 23:09 Gabriel85

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.

Gabriel85 avatar Sep 12 '23 23:09 Gabriel85

see https://github.com/RSS-Bridge/rss-bridge/pull/3759

@tpikonen

dvikan avatar Oct 15 '23 03:10 dvikan

fixed in https://github.com/RSS-Bridge/rss-bridge/pull/3759

dvikan avatar Oct 16 '23 00:10 dvikan