There are some known issues that apply to the use of AMD failover. Review them before adding this functionality to your property.

General issues

The table that follows illustrates some known issues that apply to all use cases.


Issue	Description
Working with Range Requests	A range request allows a client to request specific byte ranges of an object. If a transparent failover occurs during a sequence of range requests, andthe objects are not binary identical, playback decoding may experience errors. If range requests are required, then either of the following apply: You can't use the transparent failover recovery method, or You need to ensure content is binary-identical across all origins.
Content must be synchronized	For failover to work properly, content on your primary and backup origins must be synchronized. More on this in Before you begin with AMD Failover
Large objects and Partial Object Caching	If you're using Partial Object Caching, AMD origin failover is supported for the initial request, but not for subsequent segment fetches.
AMD Failover does not work with Watermarking	Currently, AMD failover doesn't work if you also include Watermarking. This should be fixed with an upcoming release.

Are you using Media Services Live?

If you're using Media Services Live (MSL) as your Origin Type, various caveats apply.

Stream failover

MSL traditionally implements failover at the stream level. For example:

Primary. https://customer.akamaized.net/hls/live/1234567/index_900.m3u8
Backup. https://customer.akamaized.net/hls/live/1234567-b/index_900.m3u8

Both streams use the same domain name, but a different path component, specifically the stream ID is appended with a "-b" suffix (1234567-b above). So, the following apply to this use case:

IP Avoidance can't be used. You can't set Enable IP Avoidance to "On" when setting up your recovery policy. This is because MSL uses the same origin for primary and backup streams, and this conflicts with AMD origin failover.
Dissimilar object names. If the primary and backup streams have dissimilar object names (for example, primary/index_900.m3u8 and backup/back_900.m3u8) then advanced metadata must be used to alter the backup paths accordingly. Talk to your account representative for assistance.

Origin and stream failover

In certain cases, a second hostname is assigned for the backup stream, along with the "-b" suffix. (For example, this would apply if you're implementing a geo-diverse backup origin.) This yields a distinct backup origin hostname that can use Enable IP Avoidance. For example:

Primary. https://baseballvids-xjp.akamaized.net/hls/live/2003458/baseballvids-xjp/index_900.m3u8
Backup. https://b-baseballvids-xjp.akamaized.net/hls/live/2003458-b/baseballvids-xjp/index_900.m3u8

Notice how both the hostname (baseballvids-xjp.akamaized.net vs. b-baseballvids-xjp.akamaized.net) and the stream ID (2003458 vs. 2003458-b) are different in the examples. So, the following apply to this use case:

IP Avoidance can be used.
Dissimilar object names. If the primary and backup streams have dissimilar object names (for example, primary/index_900.m3u8 and backup/back_900.m3u8) then advanced metadata must be used to alter the backup paths accordingly. Talk to your account representative for assistance.