Episode duration

[farski]

With dynamic ad insertion becoming more prevalent, issues arise around indication an episode's duration or file size), as it may not be determined until time of request.

[farski]

Perhaps it's worth having a way to indicate that duration metadata is only an estimate?

[farski]

Is there any benefit to clients enforcing limits on how much of an episode they will play back, if the actual duration and reported duration are vastly different?

[Cj-Malone]

If a longer or shorter ad is inserted it is their responsibility to update the duration where ever documented.

But once the file is downloaded the client should be displaying the time from that and not the feed.

[cqr]

@Cj-Malone that doesn't reflect the reality of how the audio is being produced these days. At any given moment, a file of various different lengths may be served depending on the client making the request, or the result of a PRNG.

I don't know if there's a good solution to this beyond the proposal from @farski to indicate that it's an estimate. There are times when these are off by several minutes.

[CharlesWiltgen]

Duration metadata is sort of inherently an estimate, since clients can play the content at various speeds, remove silences, skip commercials, etc. Platforms like iTunes wouldn't use it either, since they derive this from the actual media file.

Existing references for RSS:

• Media RSS <media:content> has an optional duration attribute

[cqr]

@CharlesWiltgen shockingly enough, iTunes does use this (or did last time I checked) - if you play an episode through the podcast browse interface on the desktop client (not through a subscription) which has a duration attr shorter than the actual media file, iTunes just cuts it off at the time in the feed.

[cio-blubrry]

First, the itunes:duration is for display purposes. I think what you are actually concerned with is the length attribute of the enclosure. If you are not familiar the length attribute is the size in bytes of the media file.

Rather than propose a tag that replicates the length attribute value of the enclosure tag, why not propose a new tag that indicates that the file size is dynamic.

e.g. yes</namespace:dynamic-enclosure>

Apps that recognize this tag will then know not to use enclosure length attribute when downloading the file.

Technically podcast apps this far along should not be using the length attribute, but as @chrisrhoden noted, even iTunes is doing this along with some other big name apps. My 2 cents is that if we can agree to use the length attribute as an estimate this new tag would not be necessary.