Align `uptime` behavior with Android and the web

[defagos]

As a Pillarbox team member I want the same rules to be applied for uptime intervals.

Acceptance criteria

• Apple and Android implementations have been aligned.
• No conflict arises with Mapp documentation for this event.

Tasks

• [x] Decide what we should do.
• [x] Implement the decision (create dedicated issues if appropriate).

[defagos]

After discussion with @amtins, @waliid and @StaehliJ:

• The Mapp documentation does mention pos but never uptime. Are these events even meaningful? Maybe @pyby knows, otherwise we could ask the GD. If the event is not useful then we could maybe drop it instead?
• If we want to align our platforms:
  • Either we restore the 30 second initial delay on Apple platforms (probably easy with a .delay).
  • Or Android and the web remove the initial delay.

[defagos]

Next step: Ask for @pyby opinion first, then ask the GD.

[defagos]

Note that uptime is currently only sent in live conditions, as noted by @pyby. So this event might still have a purpose, namely measuring the consumption in live conditions. We should ask ADI / RTS analysts if there are associated reports to find whether uptime is still useful or not.

[defagos]

According to the implementation concept:

The UPTIME event is a special Meida Action that is used by Webtrekk to calculate the amount of concurrent views in a minute-by-minute trending analysis on live streamings. The Media Action UPTIME should be sent every 60 seconds, with a 30 second initial delay form the first PLAY Media Action. Parameters that should be sent within every UPTIME Media Actions are: wt_sendinfo_media(mi, ‘uptime’, mt1, mt2, bw, vol, mut, x); If the live streaming enters the “time shifted mode”, since Webtrekk supports VOD tracking the event UPTIME should not be sent anymore as it only is needed for synchronous tracking of media players connected to the live broadcasting (to analyze the number of visitors connected to the live broadcasting every single minute).

So I guess we should keep our original Letterbox implementation after all.

[defagos]

An issue has been created for the Apple implementation.

[defagos]

The 3 implementations should be aligned for intervals but we still have to check whether we are (more or less) aligned about sending near the live edge.

[defagos]

Letterbox web was not implementing the live edge criterium (since day one). This will be fixed and implemented in Pillarbox web as well.

Letterbox web also implements a different approach to timers (the timer is running all the time and checks after 30s, then periodically every 60s, whether the player is actually playing before sending an uptime).

[amtins]

I took the time to create an issue as well as to reread the official specification very carefully. It appears that the specification contradicts itself, so depending on which definition you use, you have a 50% chance of making a mistake.

Please refer to the scenario in Story 4 (Seeking a livestream) of the documentation standard streaming events: sequence of events for media player actions

Finally, after reading a new specification, even if it's older than the standard specification to be used for players, it mentions tracking the event UPTIME should not be sent anymore so it's SHOULD and not a MUST, what should we conclude from this?

*Edit: I quickly compared with the TP and it's the exact same behavior

[defagos]

We received an answer from the GD that we should likely always send uptime, not only in live conditions.

[defagos]

Tasks created for Android and Apple.