> For the complete documentation index, see [llms.txt](https://docs.podigee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podigee.com/documentation/grow-and-monetize/monetization/fix-rss-or-hls-playback-with-wrong-media-or-no-ad.md).

# Fix RSS or HLS playback with the wrong media or no ad

Troubleshoot an RSS or HLS listener request that plays the wrong media, no ad, or an unexpected fallback.

Use this guide when a listener reports that an RSS episode has no expected ad, an audio or video ad is wrong, a break is empty, or HLS playback shows the wrong media. Start with the exact request and decision. Do not change a Campaign because one playback report has not been matched to its recorded result.

## Capture the request context

Ask for the smallest useful set of facts:

* podcast and episode;
* RSS audio or HLS audio/video;
* approximate request time and time zone;
* player or podcast app;
* ad break or approximate position;
* expected Campaign or Creative, if known;
* whether playback started, reached the break, or stopped before it.

Do not ask the listener for a private identity, token, or full technical identifier.

## Check the content and delivery route

Open **Monetization > Inventory > Break Canvas** for the episode. Confirm:

* the episode is published;
* the current audio or video version is the expected source;
* the break exists at the intended position;
* the break is enabled for the delivery surface;
* the podcast show is enabled for the relevant delivery route.

![The current One Podigee Break Canvas shows the selected episode and audio version, the audio player, the waveform, and the editorial chapter timeline.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-d87592de8f25200300b7a5485976461c8a430deb%2Fdoc-monetization-056-break-timeline.png?alt=media)

*Confirm the source episode and break before you inspect the ad decision.*

For HLS, select the video track and confirm that the video version is also current. A source media change can make an earlier break binding or prepared setup stale.

## Find the exact ad decision

Open **Monetization > Evidence & Money > Live ad delivery > Recent ad decisions**. Filter by the delivery method and the request time.

For RSS, select **Podcast audio**. For Podigee HLS, select **Video ad stitching** or the HLS method shown by the Campaign.

![The current One Podigee Recent ad decisions page shows selected ads for Podcast audio, with the Campaign, Creative, podcast, episode, reason, privacy mode, and decision time.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-d7e8fd4ca100c36e85d1231caf853395912d9401%2Fdoc-monetization-056-podcast-audio-decisions.png?alt=media)

*A recorded decision tells you what Podigee selected for the request.*

![The current One Podigee Recent ad decisions page is filtered to Podcast audio and shows selected RSS results with the Campaign, Creative, podcast, episode, reason, and delivery method.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-3a74a33197178ea144ec9389483fce00e46890dd%2Fdoc-monetization-151-rss-decisions-current.png?alt=media)

*Filter by Podcast audio when you investigate a dynamic RSS result.*

Use the request time, episode, and delivery method together. Do not assume that the most recent row belongs to the reported playback.

## Read the result before changing anything

| Result                      | What it means                                                         | Next check                                                                 |
| --------------------------- | --------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| **Ad selected**             | A paid Creative was selected.                                         | Compare the selected Campaign, Creative, episode, and break with playback. |
| **House ad selected**       | An owned fallback was selected.                                       | Read the reason and confirm the paid Campaign eligibility.                 |
| **No ad selected**          | No paid Creative was eligible, or the break rule kept the slot empty. | Read the exact no-fill reason.                                             |
| **Partially filled**        | Some slots received an ad and others followed the break rule.         | Check slot count, duration, and partial-fill behavior.                     |
| **Original content played** | Clean source media was the configured fallback.                       | Check whether the request was eligible for a paid result.                  |

Open the row and read **Why**, **Delivery method**, **Podcast**, **Episode**, **Ad break**, and all slot results. A no ad result is not automatically a delivery failure.

## If the result is no ad

Check the reason in this order:

1. Campaign schedule and Flight dates.
2. Market, content, audience, and privacy rules.
3. Frequency, separation, pacing, and budget limits.
4. Creative media type, rendition, rights, and coverage.
5. Inventory, break capacity, and reservation.
6. Demand source and fallback behavior.

Correct the named source record. Then run the current Campaign checks before you test another request. Do not add a new Campaign to hide a targeting or Creative configuration problem.

## If the selected ad is wrong

Compare the decision with the Campaign plan:

* Campaign and Flight;
* Creative family and exact version;
* rotation weight and priority;
* market and content category;
* effective period;
* delivery method.

If the decision is correct for the recorded request, the report might use a different player, request time, or content version. If the decision is not correct for the request context, stop the affected Campaign only when the issue can affect further requests, then escalate with the short decision reference.

## If RSS playback is missing the ad

Confirm that the listener used the normal Podigee RSS feed and the current episode enclosure. The RSS feed and episode identity remain stable, but the enclosure resolves to the active delivery setup for eligible requests.

Check:

1. The show is enabled for dynamic audio delivery.
2. The episode has a current break binding.
3. The request reached the break position.
4. Recent ad decisions contains the request.
5. The decision result and fallback match the playback.
6. The episode audio version did not change after the request.

If the feed returns clean audio and the decision says no ad, follow the recorded reason. If there is no decision for a request that reached the break, open Operations for a delivery or analytics processing issue.

## If HLS playback is missing or mixing the ad

Open the HLS decision list and filter by **Video ad stitching**. Confirm that the selected decision has the expected Campaign, Creative, episode, break, and media version.

![The current One Podigee Recent ad decisions page shows selected ads for Video ad stitching, with the Campaign, Creative, podcast, episode, reason, and decision time.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-cea052c594c382ab94110b59563d6406d953fce0%2Fdoc-monetization-057-hls-decisions.png?alt=media)

*Use the HLS delivery method to separate video playback from RSS audio.*

Check the HLS source in Break Canvas, then confirm that the player used the current HLS presentation. A player can request several playlists and media parts, but they must use one playback decision. If one session changes Creative or episode, stop further testing and escalate.

![The current One Podigee Ad decision details page shows a selected Video ad stitching result, its Campaign and Creative, the episode and break, the qualified value, and shortened references.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-6fa2d5aa01508c39a5227f63e668a910503f16f4%2Fdoc-monetization-057-hls-decision-detail.png?alt=media)

*The HLS decision detail connects one presentation to its selected media.*

## Check analytics and money evidence

Playback does not always qualify commercial delivery immediately. The listener or viewer must meet the measurement rule. Check the decision, audience analytics, qualified delivery, and revenue for the same request boundary.

Do not treat a missing value immediately after playback as a missing ad. Wait for the documented processing boundary, then use **Reconciliation** if the records still disagree.

## Check cache behavior only when playback is inconsistent

Most operators do not need cache details. Open Operations or escalate when:

* a retry in one playback session returns a different episode or Creative;
* one HLS session changes its selected ad between playlists;
* a range request returns the wrong bytes;
* a second request creates a duplicate commercial result for the same presentation.

Do not use a new listener session as a cache test. A new session can correctly receive a new decision.

## Confirm the repair

After one correction:

1. Run the exact Campaign checks when the source record changed.
2. Test one RSS or HLS request with a known time and delivery method.
3. Open the matching decision.
4. Confirm that playback and decision content agree.
5. Confirm that audience and commercial evidence use the same request boundary.

Keep the current published state active during investigation unless the evidence shows that more requests could be unsafe or commercially wrong. Use the normal pause or rollback control when that decision is necessary.

## Expected result

The operator can tell whether the listener received an intentional no-fill, a fallback, the selected paid ad, or the wrong media. RSS keeps its normal feed and episode identity, HLS keeps one decision for its presentation, and the matching decision, analytics, delivery, cache, and money evidence can be followed without guessing.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.podigee.com/documentation/grow-and-monetize/monetization/fix-rss-or-hls-playback-with-wrong-media-or-no-ad.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.