97 replies to this topic

[Ev0]

Hi,

have you tested with service reference picons? In this area nothing was changed for SNP.

 

ciao

It is ok, there is nothing wrong with the coding, it turned out the picons I was using were 8bit and LCD4Linux requires 32bit for transparency to work.

[Pr2]

Hi,

 

In the same philosophy that you already do with channel name with HD in the name that fallback to the "non HD" picon by name can you please add the following fallback:

 

- if the picon for *4K and/or *UHD doesn't exist then fallback to the channel name without any HD/UHD/4K reference

 

Be careful that some channels used both reference in there name:  4K UHD

 

Exemple on Astra 19.2E:  pearl tv 4K UHD

 

While others use 4K or UHD.

 

Thanks,

 

Pr2

[Huevos]

Every fallback means another check in the file system. Is that inefficiency really worth it for a handful of test channels that most people don't even have the hardware to watch? HD, on the other hand, is mainstream.

 

And what next? Create another fallback so if 4K, UHD and generic are not detected it falls back to HD version?

[littlesat]

I think it is better to remove the fallback and at an option (via a menu or so) that scans for services and picons and set a softlink when for a service an alternative is available....

[Pr2]

Please don't suppress the fallback from HD to "nothing" this is very handy to use, this avoid many symlinks to be created and it is working fine.

For exemple, last french CanalSat provider changes that turns every channel into HD just then dropped the HD mention in the name and channels are all HD now.

This has no impact for me on the picon side since all picons were already there without any symlinks.

 

I was just drawing the attention on the UHD stuff for people that work on having it supported in OpenPLi.

[littlesat]

 this is very handy to use, this avoid many symlinks to be created and it is working fine

-->

I do not agree... the 4K UHD story confirms it.... It makes the code more complicated.... It is still better to have symlinks (on service ref). during normal use no png (of symlinked png), no picon...

Therefore I still prefer to have a tool that is cleaning/adding symlinks... (after e.g. loading new settings and/or picon sets)... For the code in fact much easier and just one picon to catch..... instead of 2 or 3 or event 4.5.6 retries.....

 

I agree for the practical use the picon by service name is a good idea.... but principally it is really wrong....

Edited by littlesat, 28 January 2016 - 16:16.

[Pr2]

I disagree picon by name is clearly much more easier and is the way to go.

I stop using any picon by service ref since this is possible. Service ref picon should be used only in case of conflicting channel name.

 

That the code is little bit more complicated is not a problem and a few more testing doesn't arm at all.

What we should keep in mind is the end-user experience of the image that they used, in this case OpenPLi. So picon by name with HD fallback is nice.

 

Don't change anything yet then, keep it the way it is now.  When HD channels will be the standard the channel names will drop HD mention in the name like french Canalsat does.

We will see then what we will do with the test in code, perhaps simply replace HD by UHD. 

[Huevos]

Symlinks and service references are a pain in the neck. How it is now picons are human readable. You can just transfer them from PC to FAT32 formatted stick and run them from there. Pull the stick out, put it in a different box, etc, with zero user knowhow.

 

These boxes have sufficient processing power to sacrifice some of it making them user friendly for everyone.

[littlesat]

The human readable is not required.....
.... When a script creates them from service named picons...

Edited by littlesat, 28 January 2016 - 21:06.

[Huevos]

The human readable is not required.....
.... When a script creates them from service named picons...

Seeing as channel names are not unique, and service references are, how is that possible?

[guess]

Which picon.py is the latest (and the right one) and should I rename to picon.pyo before extracting to /usr/lib/enigma2/python/Components/Renderer

[Pr2]

when you have file .py it is automatically transformed into a .pyo at reboot so never rename a .py into .pyo because those are 2 different format files.

[guess]

when you have file .py it is automatically transformed into a .pyo at reboot so never rename a .py into .pyo because those are 2 different format files.

Thanks!

[littlesat]

You can get the py on your box when you type

 

opkg install enigma2-src

 

via telnet/putty

[guess]

You can get the py on your box when you type

 

opkg install enigma2-src

 

via telnet/putty

Thanks!

[Robinson]

Hi,

I'm new to "picons by service name".

Where can I find sets of service name picons for various satellites or various providers? Are they available for downloading?

And if there is no service name picon available for a channel, will the box automatically use a traditional reference name picon?

By the way, what is the optimum picon size for FullNightHD skin (although on a HD ready TV)? 220x132?

Thanks.

[Abu Baniaz]

Where can I find sets of service name picons for various satellites or various providers? Are they available for downloading?

 
You can download from Ocram's site. If using windows, use Chrome to download

picons.eu

And if there is no service name picon available for a channel, will the box automatically use a traditional reference name picon?

It works the opposite way round.
It uses the traditional picon name first. If that isn't present, it then uses the SNP name.

[Robinson]

Thanks a lot.