Wrong movie poster or synopsis on IPTV: where does the data come from?

You open a movie and see a poster for something else. Or the artwork looks right in the library, but the synopsis changes when you open the details. Before assuming the video is wrong, separate three things: the provider’s catalog entry, the information describing the movie, and the video that actually plays. They are connected, but they are not the same data.

With Xtream Codes, the app receives a structured catalog from the server. It can include artwork, plot summaries, cast, and identifiers from movie databases. The player may also supplement the entry with external information. A mismatch at any of those steps can appear on screen even when the movie plays normally.

Posters and plot summaries are metadata

Metadata describes content: its title, year, genre, runtime, poster, synopsis, and cast. Think of a book’s cover and blurb: they help you choose it, but they are not the pages inside. On IPTV, the movie’s description and the address used to play its video also follow different paths.

An English synopsis does not prove that the audio is in English. A “4K” poster does not confirm the file’s resolution. And the wrong artwork alone does not tell you whether the video has been mixed up too. Keeping those distinctions in mind makes a support report much more useful.

How Xtream Codes delivers the data

When you set up a profile with a server address, username, and password, you tell Nebula where to request your authorized catalog. The app sends requests to the provider’s API, usually through /player_api.php. Each request specifies an action, and the server returns structured JSON: named fields with values the app can read.

Xtream Codes is the communication interface, not a universal movie database. Each provider maintains its own catalog and decides which fields to populate. The names below are common in this ecosystem and used by Nebula’s integration, but field availability and data quality vary across compatible servers.

1. The server supplies categories and a movie list

Movie categories can be requested with get_vod_categories. The get_vod_streams action returns video-on-demand entries, or VOD. This initial response lets the app build the library without requesting every movie’s full details at once.

• name: the catalog title, which may include a year and labels such as DUAL or 1080p.
• stream_id: the item’s identifier within that provider’s catalog.
• stream_icon: the image address used for the item’s artwork in the list.
• category_id: the provider’s assigned category, which is not necessarily a movie genre.
• rating and added: a rating and information about when the entry was added, if supplied; added is not the movie’s release date.

Nebula stores the received list locally for browsing. The artwork you see in the library can therefore come directly from the stream_icon supplied by the provider. The app does not need to watch the video or recognize its scenes to display that card.

2. Opening a movie triggers a details request

When you open a movie in an Xtream profile, Nebula requests get_vod_info, passing that entry’s stream_id as the vod_id parameter. In plain language, the request means “send me the details for this movie in your catalog.” Calling the parameter vod_id does not turn the number into a movie-database identifier: it still refers to the provider’s item.

The response typically separates info, containing descriptive metadata, from movie_data, containing item information such as its name and container_extension, the extension used for playback. Within info, fields such as movie_image, plot, cast, director, genre, releasedate, and tmdb_id can supply artwork, a synopsis, cast, director, genre, release date, and a TMDB association.

Xtream can therefore deliver a complete movie description. If plot is empty or movie_image points to the wrong artwork, that gap or mismatch has already arrived through the API. The library poster and the details image can also differ because they came from separate fields and requests.

3. Images are fetched from the supplied addresses

The response generally contains an image URL rather than the entire image. The app then has to download that artwork from an address belonging to the provider or another service. The catalog can load and the video can play while the poster fails because of a broken link, an unavailable image server, or an old cached copy.

The image’s domain alone does not tell you who selected it. A TMDB address may have been included by the provider in the Xtream response. It does not necessarily mean the app performed its own lookup.

Where TMDB fits into Nebula Player

Alongside the Xtream description, Nebula can use TMDB, a movie and TV database, to show richer details. In the movie flow, when this feature is active, the app tries the TMDB identifier supplied by the provider. When no usable identifier is available in the search flow, it may search by title, removing technical labels and using the year when available.

If the TMDB details request succeeds, the enriched screen can use its title, poster, backdrop, synopsis, and cast. If that request fails, the movie flow can fall back to the provider’s description. Enrichment depends on the active features and the outcome of those requests; it does not guarantee an automatic fix for every catalog entry.

Imagine a fictional entry named “Horizon (2021) DUAL 1080p.” The provider could supply the right artwork in the list but attach the tmdb_id of a different movie called “Horizon.” Opening the enriched details would then show that other movie’s description. Playback still uses the provider’s entry: enriching metadata does not replace the video file.

Title searches have limits too. Remakes, translated titles, similar names, and incorrect years can lead to the wrong match. Removing “DUAL” and “1080p” helps the search, but it does not prove the movie’s identity. A correct identifier supplied at the source avoids the ambiguity of a text search; a wrong identifier can carry the mismatch forward.

What about TV series and M3U playlists?

Series follow a similar pattern: get_series lists the catalog, and get_series_info requests a show using its series_id, potentially returning show details, seasons, and episodes. There are more levels to match: season artwork is not necessarily the show’s main poster, and an episode summary is not the description of the whole series.

An M3U playlist does not make those Xtream requests. It may include a name, a group, and an image, for example through the tvg-logo attribute. In Nebula’s M3U flow, the initial details are assembled from imported information, and enrichment may fill in missing metadata through a title search. Our article “M3U, M3U8 and Xtream Codes: what’s the difference?” explores those access formats in more detail.

How to narrow down the problem

• Check the title, year, and content type. A series, a movie, and a remake with similar names are different works.
• Compare the library artwork with the details screen. If only the details change, mention that: it helps investigate the details request and enrichment.
• Check whether the video is the movie you expected. If it is also wrong, the provider needs to inspect the catalog entry and its content association.
• Refresh the catalog using the option available in your app, then reopen the title. This may pick up a correction already made at the source; it cannot fix an entry that is still wrong there.
• Compare another player, if available, using the same account. The same error strengthens the case for a source issue; different results are a clue, not proof, because apps may enrich and cache data differently.

If only the image fails to load, try another network and other titles to distinguish an image-access issue from an isolated catalog problem. If the description is in another language, check the app’s language and report the case to support. The text may come from the provider or an external database with no translation available. Switching languages cannot create a translation that the source does not have.

Who can fix each part?

The provider can review the name, year, image URLs, synopsis, and external identifier sent through its API, as well as the video associated with the entry. Player support can investigate field interpretation, which data is displayed, title matching, and local refresh behavior. An incorrect description in the external database itself needs to be reviewed there.

When asking for help, include the expected title and year, category, app version, and screenshots of both the list and the details, hiding account information. Say whether the artwork, synopsis, or video is wrong. Never publish playback URLs, usernames, passwords, or full API responses: they may expose your access credentials.

Reliable movie details depend on a chain of associations: the right provider entry, accurate fields, accessible images, and the right match in the external database. Understanding that chain makes it easier to locate the mismatch and ask the party responsible for that step to correct it.