Content switch happened later than the specified time.

If you are using a player and experiencing a delay in content switching at playout, make sure you are taking into account the buffer of the player. broadpeak.io performs the manipulation at a given time based on the timing in the manifest. Therefore when playing, the switch happens when the player reaches that given time, and not the actual time of your device/browser.

If you experience a delay of a few milliseconds, this could be an expected behavior as the precision of the platform is 1 second. See the Time/Timings management section for more information.

Content switch happened earlier than the specified time.

HLS: broadpeak.io performs the content switch at the end of the closest fully available segment to the given time. This could be an expected behavior. See Time/Timings management for more information.
MPEG-DASH: as opposed to HLS, MPEG-DASH multi-periods allow to have two different periods on which last and first segments of the respective first and second periods can overlap. It is down to the client to decide whether to perform mid-segment switch or end of segment switch. Therefore, the player can introduce some delays.

Content switch did not occur

In the event the switch between original and replacement content is not happening, we invite you to follow the verification steps below:

When using conditional replacement, make sure that the audience is being provided within the streaming request (zipcode, category), and that the value provided belongs to the audience defined in the MediaPoint.
Make sure the CDN is configured as advised here and forwarding all mandatory query parameters to broadpeak.io. Manifests must not be cached by the CDN.
When creating MediaPoints, make sure that both original and replacement sources are using the same format (MPEG-DASH, or HLS), and compatible format version.
In HLS, both original content and replacement content must be encoded in the same way. When not the case, the contextualization process fails, and content replacement is not happening. More information can be found in the Content Replacement guidelines section

Contextualisation failure

By default, incompatible original content and replacement content prevent the contextualization process to succeed, resulting in the content in the original manifest not being replaced.

This means that a video, audio, keyframe or subtitle variant of the original content does not have a compatible match in the replacement content. This may be due to codec incompatibilities or a language incompatibility between the variant(s) of the two manifests, as highlighted in the matching rules above.

Below is a short list of events which can lead to a contextualisation failure, for ease of troubleshooting:

There is codec incompatibility at the level of the video or audio. In the event of multiplexed audio and audio variant, both audio and audio codecs of the variant must match in both manifests. When using separate audio and audio variants, codecs of the video variant must match between both manifests, and audio codecs of the audio group rendition attached to the video variant must also match.
There is a language incompatibility on audio between both manifests. The language must match in both manifests, or with the first codec-compatible default track set in the replacement content manifest.
The original and replacement sources do not use the same audio or subtitle language code (ISO-639-1 vs ISO-639-2)
For Dynamic Ad Insertion applications, the VAST response does not contain compatible creative. If you are using a Transcoding Service, MediaFiles must be MP4 or Mezz type. Without Transcoding Service, it is expected that the MediaFiles must reference m3u8 or mpd files.

If you have any issue that persists and the suggestions above do not work, we invite you to validate the stream requirements in the related section: Input Formats and to check the troubleshooting Virtual Channel / Content Replacement issues section