Login issues

If you receive this kind of message at Login:

It may be because Third Party Cookies are disabled on your browser. Indeed, on some specific (and rare) occasions, utilizes third-party cookies to Authenticate third-party Identity providers and requires that your browser accept third-party cookies.

If you need to do it, we advice to use this guide from our friends.

Playout issues

This section will help you troubleshoot playout issues.

If you are experiencing delay in content switch or no content switch at all, please check that your origin packager has proper time synchronization - see Understanding behavior. If you are still experiencing issues, the following sections might help.

HTTP errors at playback:

Some errors might be returned by the platform when something goes wrong. Here is a list of these errors and their meaning.

404 Errors:

  • 404 Internal error (From the origin or MM)
    --> The origin returns a 404 error when attempts to retrieve the manifest(s).
    --> Something is wrong with the provided stream retrieved from the origin. It can be that the stream is not supported by You can find more information about Input streams requirements here Input Streaming Formats
  • 404 Bad Gateway of the origin server
    --> The origin or the Ad server has returned an invalid response to
    --> The origin or the Ad server has taken too long to respond to and has been considered as timed out.
  • 404 Service temporarily unavailable error of the origin server
    --> The content stopped being available from the origin or is temporarily unable to retrieve it.
  • 404 Failed to join the origin server
    --> The origin is not reachable from Make sure the appropriated inbound and outbound firewall rules are set at the origin level. You can find more information here.
  • 404 HTTP version is not supported by the origin server
    --> The protocol to retrieve the manifest used by is not supported by your origin.

50X Errors:
For any 50x Errors returned by the platform, please contact us at [email protected].

Timeout from

If you are using a CDN and receiving a timeout from the CDN, then the CDN might be faulty. It is also good practice to check that the CDN configuration is correct and that the right behavior, and caching policies are set. You can find more information here Using with a CDN
In case the issue persists, please contact us at [email protected].

Content keeps switching every couple of media segments when using a CDN

When caching is enabled on the CDN, the manifest retrieved by the player from the CDN might not be the one intended, and the content described in the manifest might reference a content targeted for another audience. Make sure to disable manifest caching on the CDN. You can find more information in the following section.

Player freezes or crashes

Not all players software providers have fully implemented the Apple HLS and MPEG-DASH standards and, as a result, some of them do not support stream changes during playback. HLS players need to support discontinuities, while MPEG-DASH players need to implement multi-period support. You can find more information here (lien manquant).

REST API issues

403 Errors: an API Key must be provided in the Authorization header as a bearer token to make any API call to the API. Keys may have an expiration date depending on how they were generated. Without providing a key or with an expired key, a 403 error is returned by the API.

More information about key generation can be found here Generation your API Key

If you are experiencing any issue with the REST API, we invite you to consult the API Reference documentation. If the issue persists, please contact us at [email protected].

Content Replacement/Virtual Channel issues

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. 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 Understanding behavior for more information.

Content switch happened earlier than the specified time.

  • HLS: performs the content switch at the end of the closest fully available segment to the given time. This could be an expected behavior. See Understanding behavior 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:

  1. 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.
  2. Make sure the CDN is configured as advised here Using with a CDN and forwarding all mandatory query parameters to Manifests must not be cached by the CDN.
  3. When creating MediaPoints, make sure that both original and replacement sources are using the same format (MPEG-DASH, or HLS), and compatible format version.
  4. 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 Understanding behavior

Ad Insertion issues

No pre-roll pre-packaged ads inserted

In case pre-packaged ads are not inserted at the beginning of the playback (live or VOD) check the following:

  1. Check that the ad server is correctly configured and reachable from You may use the status icon next to the ad server URL in the source edition page or next to the ad server name in the service edition page. forwards the client user-agent, so if the Ad Server filters by user-agent, it might be a root cause of your issue.
  2. Check that the ad server returns a VAST or VMAP that links to the desired pre-packaged ad. You may point your browser to the ad server URL with appropriate query parameters.
  3. Check the logs of your ad server to verify that it received a correct request from

No live pre-packaged ad replacement (SCTE-35 markers)

In case a live service containing ad placement opportunities signaled through SCTE-35 markers does not receive pre-packaged replacement ads, check the following:

  1. Enable live pre-roll on the live service and check that pre-packaged ads are inserted when the session starts. If not, see the section above.
  2. Check the logs of your ad server to verify that it received a correct request from If not, check that your live service does include SCTE-35 markers that are compatible with requirements. See Preparing your content.

No transcoded ads inserted

In case ad transcoding is enabled on your ad insertion service and no ads are inserted, check the following:

  1. Configure your ad server to always return the same ad. Play your service a first time and check that your ad server received a correct request from Wait for a few minutes, to give enough time to transcode the ad. Play your service a second time. If the ad plays, then your service is working correctly.
  2. Disable ad transcoding, configure your ad server to return a pre-packaged ad and check that ads are inserted. If not, see the sections above.
  3. If all tests above failed, please contact us at [email protected].