Picons: Service Named Picons

Interesting, seems pretty simple and i can appreciate the benefits of this. Renaming picons has become annoying to say the least....
Few questions.....

1. Will this work on cable and terrestrial Channels ?
2. What about multi sat set-ups??...( channels names will be the same on multiple satellites.... but picons are differant currently )
3. Can hard drive still be used as picon location ?

Thanks

Quote from jenseneverest

2. What about multi sat set-ups??...( channels names will be the same on multiple satellites.... but picons are differant currently )

The conventional service refernce picons are higher up in the selection list. So use those as normal. Same thing applies to the ITV channels. If you have picons with the region name on them, continue to use the ones with the service reference name.

- - - Updated - - -

I have uploaded a couple of sets here. There are Ocram's ones fron October on the Openvix download site.

Quote from manuel06

What about XPicons? Do we need a new XPicons.pyo or this is only for picons?

Yes, please alert skin author.

An aside, the front display one has been commited

Script to rename the picons. Thanks to Huevos and McQuaim.

Just to add, Service Named Picons (SNP) have been in all mainstream images since 2014. Surprisingly, people still want to use Service Reference Picons (SRP) and keep changing the names whenever there is a transponder change

SNP code was introduced to OpenPLI on 8th November 2014 in this commit: https://github.com/OpenPLi/eni…ba36c3205af179b93fad86e38

SNP code was introduced to OpenATV on 5th November 2014 in this commit: https://github.com/openatv/eni…8701f55aa4b382e525031966e

To recap:

Instead of using the service reference for the picon filename, the channel name is used instead, but at that time these were conceived it was decided to only allow lowercase ASCII letter and number characters. i.e. a-z and 0-9. All other characters, spaces, symbols, etc. were sent to the dustbin. This approach allowed for frequency and identifier changes and still continued to work, and was human readable.

The limitation/problem with Service Name Picons is that the algorithm only allows a-z and 0-9 and no other characters. This is ok for channels that use the western alphabet without accents or special chars but not for Arabic ( اسم قناتي ) or Bulgarian ( Диема ХД ) or even western European ( Áèíöúñ ).

UTF-8 Service Name Picons:

Support for UTF8SNP was added to OpenPLI on 1st April 2024 in this commit:https://github.com/OpenViX/eni…57765a766dad42d67d13b502a

Support for UTF8SNP was added to OpenPLI on 1st April 2024 in this commit: https://github.com/O...2f53d1b522ac3a4
Support for UTF8SNP was added to ATV on 11th December 2024 in this commit: https://github.com/openatv/enigma2/comm ... f0862711ac

UTF-8 is a character encoding system, created in 1993, that can represent more that one million characters. UTF-8 has become the de facto standard and today almost all webpages worldwide use this encoding. You can read more about it on Wikipedia ( https://en.wikipedia.org/wiki/UTF-8 ). Also, UTF-8 is the default encoding in Python 3 (which all images have now migrated to) and the characters are fully compatible with the Linux file system. So now the channel "Диема ХД" can have a picon with the filename “диема хд.png”. This type of picons are already in the feeds (packages marked utf8snp).

Some of the picon packs on the image's plugin server are built from https://github.com/picons/picons so any problems with the packages should be reported there. The support for SNP on that project will be removed at some stage, so please start using the utf8snp sets and report issues before SNP sets are stopped.

You must uninstall the other versions of picons (SRP or SNP) before installing the utf8snp version.

You can have all three types in one folder. The priority of searches by Enigma2 is:

Exact SRP

Modified SRP (e.g namespace/dvb type changes)

Utf8SNP

SNP

With ocrams picons packs, you cannot change between picon packs, you have to uninstall one before installing another. For argument's sake, if you installed an SRP version and wanted to install an SNP one. You installed 220x132 220 x132 but wanted to use 220x132 190x102. You installed dark on light and then wanted to install light on transparent. Any of these type of changes will result in a clash. You have to uninstall the first one before installing the next.

For Ocram's packs, I decided against adding utf8snp links in the SNP.index files. People get confused by the fact that logo names and picon names are different. We would then have ask is that the SNP name or utf8snp name? Moreover, there are a lot of dead links. The utf8snp packs contain more working links than SNP ones anyway.

If you are using another SNP picon pack or ones from kiddac's plugin, you could rename them. But why would you when both naming types work.

If you install the "missing picons" plugin, it creates CSV files with symlinks to SRP which you could apply. But they will only work for current names and valid references. Better to just rename them when they change. This is why I find that other picon thread to be inefficient.

A script to rename SRPicons to UTF8SNPicons by Huevos is here

https://gist.githubusercontent.com/Huevos/17a267b68851319f48c4dcd272882b03/raw/2affe9daa30c183378366ff778999aa14b2901a0/picons-rename.py

Download and transfer to /hdd. Ensure it has 755 properties

Invoke by issuing following command

python /hdd/picons-rename.py

It will create the renamed picons in /tmp directory of your receiver

Your question are specific to your personal requirements, not to this generic thread.

As SNP strips characters out, how is a computer meant to read a picon name and guess what has been stripped out?. As I mentioned to you in PM and on the other forum, you don't need to rename from SNP to UTF8SNP. Both naming systems as well as SRP are supported by Enigma2. If you are determined to convert them, perhaps a different thread is better. You will have to use the output from missing picon to create commands to rename files. But you run the risk of renaming files that will be needed later in the process. You are duplicating files with different filenames. You wanted to reduce number of files but doing the opposite. As I said in PM, you are better off having symlinks instead of duplicating file names.