OpenPLi / enigma2

Framebuffer based frontend for DVB functions on Linux settop boxes
GNU General Public License v2.0
150 stars 204 forks source link

Include sd, fhd, and uhd in picon.py #3830

Closed kiddac closed 2 weeks ago

kiddac commented 9 months ago

In a world of iptv would it be possible to amend the picon.py to include iptv references like sd, fhd, uhd, 4k

Currently SNP picons look for name and if ends with HD strips the HD

It would now be better if this code also incorporates other IPTV values like SD,4K, FHD, UHD to pick up more IPTV channels

Example new code.

if not pngname:
    name = sanitizeFilename(ServiceReference(serviceRef).getServiceName())
    name = re.sub('[^a-z0-9]', '', name.replace('&', 'and').replace('+', 'plus').replace('*', 'star').lower())
    if len(name) > 0:
        pngname = findPicon(name)
        if not pngname and len(name) > 3 and (name.endswith("fhd") or names.endswith("uhd")) :
            pngname = findPicon(name[:-3])  
        if not pngname and len(name) > 2 and (name.endswith("hd") or names.endswith("sd") or names.endswith("4k") ):
            pngname = findPicon(name[:-2])`     
kiddac commented 9 months ago

jbleyel on openatv has recommended a regex solution instead

if not pngname:
  name = sub("uhd$|fhd$|sd$|hd$|4k$", "", name)
  if name:
    pngname = findPicon(name)
littlesat commented 9 months ago

I agree this is not Pli style. Please improve with 'sub'. Can be done in a kind of oneliner

AbuBaniaz commented 8 months ago

The changes were added to the developer image. I have submitted a pull request to pick it into Release. https://github.com/OpenPLi/enigma2/pull/3861

Issue can then be closed.

WanWizard commented 8 months ago

It might also be beneficial in that context to strip anything in square brackets from ths start. And I have also seen "8K" (which if you're lucky is FHD), so this needs stripping too.

It would be better if IPTV tools would strip all this nonsense at the source though, instead of having to hack this into E2.

AbuBaniaz commented 8 months ago

But if that was done, you would not know what the quality/resolution is supposed to be.

AbuBaniaz commented 8 months ago

Please ignore. This is wrong. On second thoughts and after comment by someone from another image, the wholesale trimming is not the best approach. The original suggestion where the trim is done if the full name is not found would have be better. That would have catered for channels where there are different logos for HD/SD channels.

WanWizard commented 8 months ago

But if that was done, you would not know what the quality/resolution is supposed to be.

I don't understand that, it is fine to strip HD and 4K, but not 8K?

And I was referring to channel name prefixes, which are currently not stripped at all, like

[BE] [8K] Play Sports 4 HVEC

which needs two prefixes stripped, and a suffix which we currently don't strip.

AbuBaniaz commented 8 months ago

My comment was in response to It would be better if IPTV tools would strip all this nonsense at the source though, instead of having to hack this into E2.. Not specific to 8k

My last comment is wrong, trims are done if the full name is not found

AbuBaniaz commented 8 months ago

I have re-opened the pull request for 9.0 branch. I would be grateful if you can consider merging it.

littlesat commented 8 months ago

As far I know this is included in a more smarter way.

AbuBaniaz commented 8 months ago

It is only in Develop image.

pr2git commented 2 months ago

Every IPTV providers has its own way to report there channels resolution (they are very creative on this), the implementation of the resolution strip was initially done for the satellite to have a fallback when there is no specific picon for hd (remember that at the very beginning of HD channels there was specific picon for those channels compared to SD one), so indeed the strip was done for the end of the string because it was there that it is placed on DVB transmission. And I agree that a regex would be better for perform this.

WanWizard commented 2 weeks ago

As far I know this is included in a more smarter way.

Then why is this issue still open?

AbuBaniaz commented 2 weeks ago

Because it is not in release image yet

WanWizard commented 2 weeks ago

Leaving this open doesn't change that.

If it is in develop, the issue is dealt with, and available for the wider public in the net release.

AbuBaniaz commented 2 weeks ago

I have created a pull request https://github.com/OpenPLi/enigma2/pull/4053 I hope you can merge it.