Deliver metadata with business errors?

[defagos]

As an SRF app developer I would like to be able to display player metadata for streams that have not started yet. As a product team we should agree whether this kind of feature is compatible with Pillarbox DNA, both technically and from a feature set point of view.

Hints

On Apple platforms errors, both technical (e.g. network issue, 404, etc.) or business (e.g. blocking reason) end up with an error devoid of any metadata even if, in the business case, we could deliver metadata as well.

The SRF app team would like to display metadata (e.g. a thumbnail) also when a business error (e.g. content availability) is involved. This is something that might already be possible on Android and / or the web, maybe something we should support, maybe not.

This could also offer an option to better address related issues like SRGSSR/pillarbox-apple#917. If we provide an availability date with metadata we could namely not only deliver it but also implement an automatic retry mechanism. Not sure there is a team agreement on this kind of behavior so we should really discuss it together.

Acceptance criteria

• The team discussed whether the feature above makes sense and is technically feasible.
• Dedicated stories have been created if meaningful.
• Otherwise the SRF app team has been provided with an alternative strategy.

Tasks

• Discuss within the team.
• Create stories or inform the SRF app team otherwise.

[defagos]

Nice topic for our weekly API discussion. Added to the sprint.

[defagos]

A PoC implementation is available on Apple platforms.

[defagos]

In essence delivering metadata with a business error is similar to delivering a media composition with an unplayable resource URL. So this task could be seen as a consistency improvement rather than a feature.

[defagos]

Current status:

• Web: Already supported.
• Apple: Possible with minimal effort and risk.
• Android: Requires a PoC to evaluate feasibility. Seems not trivial. Would a priori be better to supply metadata beforehand but a PoC could be helpful. A dedicated task has been created.

Next steps:

• PoC on Android.
• After PoC discuss again with 3 possible decisions:
  • Don't do it if not possible on all platforms and consistent behavior is desired. The web team would still like to keep the current behavior (used for logging purposes).
  • Do it everywhere if desired on all platforms.
  • Document as undefined behavior and let each platform deliver the best possible result.
• Inform SRF about our next steps.