Refreshing a configured source asks the player to retrieve or rebuild current data for that source. Importing again can create another catalogue entry, depending on the application. The operations may sound similar, but their effects on local names, favourites and account records can differ.

Before repeating an import, identify the result you need. Obtaining an updated channel list is not the same task as adding a separate account or restoring a deleted configuration. Use the documented operation that matches that intent.

When a playlist is empty. — IPTV USA editorial illustration

Recognize accidental duplication

A common symptom is two similarly named catalogues after someone tries to force an update. One may show older data, while the other holds newly imported entries. Testing the wrong copy can then make the update appear unreliable even though the sources are simply duplicated.

Rename local catalogues clearly if the player supports it, but do not alter private account fields to create a label. A display name is the appropriate place for a distinction such as “temporary comparison.” Keep that temporary purpose explicit so the extra copy is not mistaken for the everyday source.

Choose the next operation

A visible refresh indicator is not proof that the expected remote change arrived. Compare something concrete, such as a deliberately corrected label or a newly dated guide window. Keep retrieval success and the resulting catalogue contents as separate observations.

  1. Identify the existing configured source and its current local name.
  2. Read the player’s refresh, reload and import descriptions.
  3. Record essential local preferences before an operation that can rebuild data.
  4. Use the supported refresh route for the existing source when that is the task.
  5. Check a known catalogue change and remove only a verified redundant temporary copy.

Preserve local preferences deliberately

Favourites or guide mappings may attach to source identifiers. A new import can receive a different local identity even when it uses the same private address, leaving the original preferences behind. Whether a player merges or separates these records is application-specific, so check before deleting the old one.

If a refresh fails, note the exact message and current source configuration without repeatedly adding more copies. Several failed attempts with slightly different labels create extra uncertainty. A single well-identified source and one recorded error are easier to investigate.

For support, state which action you used, whether it created a new catalogue and what specific change you expected. Avoid describing all these operations as “updating the app,” because application software, source data and local preferences are different things. The useful outcome is one current, identifiable source with the intended preferences preserved.

Useful answers

Will importing the same address always update the original source?

Not necessarily. Some applications can create a separate entry.

Does a refresh guarantee that favourites are retained?

Check the player’s documented behaviour and keep a suitable backup before rebuilding data.

What should I compare after refreshing?

Use a specific expected catalogue change or dated guide window, rather than the refresh indicator alone.