Skip to content

Conversation

@janbar
Copy link
Contributor

@janbar janbar commented Dec 20, 2025

Based on the remote filenames of the icons, conflicts can arise, causing a mess:

<icon src="https://static.te.../stations/308/icon320_light.png?v2023_48_0"/>
<icon src="https://static.te.../stations/58/icon320_light.png?v2023_48_0"/>
<icon src="https://static.te.../stations/383/icon320_light.png?v2023_48_0"/>

These cases generates the same icon filename 'icon320_light.png?v2023_48_0'.

The proposed solution no longer uses the original filename; it now generates a user-friendly name from the source identifier of channel (xmltvid), followed by the hash of the full remote URL and, optionally, the file extension. This way, the generated name can no longer conflict with that of another channel, and it is easily identifiable with the xmltv identifier, as it is user-configured.

<xmltv_id>_<remote_url_hash>.<ext>

Now downloaded icon names from xmltv source look like the following.

T18.fr_2fcaf706.svg.png
NOVO19.fr_d890da17.svg.png
TMC.fr_79bd517.png

Thank you for contributing to MythTV!

Please review the checklist below to ensure that your contribution
to MythTV is ready for review by our developers.

It is helpful to regularly rebase your pull request to ensure changes
apply cleanly to the current MythTV development branch.

Checklist

@garybuhrmaster
Copy link
Contributor

While I understand your particular issues,this feels like an incomplete (and therefore wrong) solution.

In my case, for one guide source, the base names are entirely meaningful and useful (includes the channel and network association), and hiding them inside some opaque hash would be a disservice (perhaps unless you want to go whole hog and create a unique uuid based channel icon blob table which has automatic deletion when there are no longer any references, but that is probably a bridge too far).

And the xmltv is only unique within a sourceid (when you have multiple guide sources), as the same xmltv (which is defined only by the source) can be reused by other sourceids (yes, there is the RFC2838 standard,but not all guide sources use it).

Instead, I would suggest that as the xmltv will be only unique within the sourceid, that the (default) names should be something of the form of sourceid_xmltv_base_url_name.

@janbar janbar force-pushed the fix_master_channel_icon_collision branch from 1bf0df3 to 2b48d74 Compare December 21, 2025 09:22
… source

Based on the remote filenames of the icons, conflicts can arise, causing a mess:

  <icon src="https://static.te.../stations/308/icon320_light.png?v2023_48_0"/>
  <icon src="https://static.te.../stations/58/icon320_light.png?v2023_48_0"/>
  <icon src="https://static.te.../stations/383/icon320_light.png?v2023_48_0"/>

These cases generate the same icon filename 'icon320_light.png?v2023_48_0'.

The proposed solution no longer uses the original filename; it now generates a
user-friendly name from the source identifier of channel (sourceId + xmltvId),
followed by the remote name.
This way, the generated name can no longer conflict with that of another channel,
and it is easily identifiable by the user.

  <source_id>_<xmltv_id>_<remotename>

Now downloaded icon names from xmltv source look like the following.

  1_TF1SeriesFilms.fr_icon320_light.png?v2023_48_0
  1_LEquipe21.fr_icon320_light.png?v2023_48_0
  1_6ter.fr_icon320_light.png?v2023_48_0
@janbar janbar force-pushed the fix_master_channel_icon_collision branch from 2b48d74 to e1a35fc Compare December 21, 2025 12:16
@janbar
Copy link
Contributor Author

janbar commented Dec 21, 2025

@garybuhrmaster , I amended the initial commit. Thanks for review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants