97 replies to this topic

[littlesat]

That means another if not exists then....

 

The performance is always the best and most unique when using references...

[Pr2]

I agree but when you can get several satellites that all broadcast the same channel or even several provider that broadcast the same channel on different TP,  it is good to have only one picon for all of them.

Is really another if not exists a real problem... it will only reach the last one when picon doesn't exist otherwhise it won't go that deep in the test. 

[Huevos]

Pr2, there are already at least 20 picon set already produced in this format that I know of, and probably a lot more.

 

What you are asking is to limit the names to an even narrower range. I for one want to be able to select the correct picon for the channel (SD or HD) and not be forced to use just one. That means creating an extra fallback (which means even more overhead) for people that want to have a reduced set of picons. Are you really so tight for space that you haven't got room for a full set of picons. And btw one of the main points of this was to be able to avoid using symlinks and create a picon set that even a typical Windows user could produce and to be able to use it directly from a FAT32 formatted USB stick with absolutely no knowledge of Linux, file systems, service references, etc.

Edited by Huevos, 23 December 2014 - 00:53.

[Pr2]

Yes I was talking of an extra fallback so people that have the hd picon available than it is used and if the hd picon name is not there it can try to use the sd one.

This is not a question of space, I have no problem with it, in the past I have all my picons with full service reference, I was just thinking that it was a smart approach drop the hd reference in the channel name when no picon match the "hd" name. Just to make thing even more smart and user friendly. I don't think that this change will be that CPU/IO intensive...

[littlesat]

it is good to have only one picon for all of them.

What is bad about the short link system?

[Pr2]

This sentence means that it is good to have only once the picon name:   channelname.png n the picon folder for all the satellites.

There is nothing wrong with symlink... except for people using a FAT32 filesystem on therer USB stick whch is not my case.

But OK I understand that you don't want to have this improvement implemented so let close the discussion here.

[littlesat]

I'm only talking that the ...hd or ..hd not discussion is something 'wierd'.....

 

But I agree this is an easy implementation to do....

if not pngname: # picon by channel name
    name = ServiceReference(serviceName).getServiceName()
    name = unicodedata.normalize('NFKD', unicode(name, 'utf_8')).encode('ASCII', 'ignore')
    name = re.sub('[^a-z0-9]', '', name.replace('&', 'and').replace('+', 'plus').replace('*', 'star').lower())
    if name:
-       pngname = findPicon(name)
+       pngname = findPicon(name) or name.endswith('hd') and findPicon(name)[:-2]

Edited by littlesat, 23 December 2014 - 15:46.

[Erik Slagter]

What may be interesting, some services may be your local cable TV operator, same as the ones broadcast over satellite, but the service reference will be different and there will probably no picon sets that cover your local cable TV operator. For that situation, some fallbacks might be preferrable (and indeed also try with "[-_ ]*HD[-_ ]*" removed, I think it's a good idea).

[Rob van der Does]

But 'service name picons' don't use service-reference at all.

[Pr2]

@Erik,

 

Thanks for your support; and even on satellite you can have the same situation, that's why I switch from service-reference to service-name for my picons more easy to manage. And if logo changed we change 1 file and the logo is then changed for all providers.

 

@SatKierkerd

 

Yes we are not talking of service-reference at all here but of picon based on service name, Erik just gives another example between sat and cable where it can also be usefull to try the search without the HD at the end.

[littlesat]

Sounds like we should search for service name before we search for service reference....

[Huevos]

Sounds like we should search for service name before we search for service reference....

No, bad idea as explained earlier.

 

Here is an example. UK ITV has more than 10 regions. But the service name is always ITV. In this case we need to use service ref picons with priority, so the correct picon is selected. No way to do it with service name. But we also have a generic picon with itv.png as the filename that catches any new unknown ITV region or that covers any change of service ref.

[Huevos]

What may be interesting, some services may be your local cable TV operator, same as the ones broadcast over satellite, but the service reference will be different and there will probably no picon sets that cover your local cable TV operator. For that situation, some fallbacks might be preferrable (and indeed also try with "[-_ ]*HD[-_ ]*" removed, I think it's a good idea).

Erik, there are only alphanumeric ASCII characters used in SNP filenames.

[Huevos]

 

Sounds like we should search for service name before we search for service reference....

No, bad idea as explained earlier.

 

Here is an example. UK ITV has more than 10 regions. But the service name is always ITV. In this case we need to use service ref picons with priority, so the correct picon is selected. No way to do it with service name. But we also have a generic picon with itv.png as the filename that catches any new unknown ITV region or that covers any change of service ref.

 

Basically service ref picon needs to take priority so that it can be used where there is an unfavourable collision with filenames.

[littlesat]

When someone posted on github good picon sets without any complications this can indeed be helpfull I suggest... It would also be helpfull to get the scripts to create good background etc to the picons (I do not like to draw a background seperately).And indeed it works with any provider as long the names are the same.... And spaces and change characters are removed so the chance to find a fix increases...

Edited by littlesat, 24 December 2014 - 08:58.

[Pr2]

I agree with Huevos, service reference should remains the 1st choice since this is the only way to have a real unique ID and so it is the only way to solve conflict in channel names/picons.

 

About the background personnally I would prefer to create a full bunch of empty backgrounds and then apply the TV channel picon with transparent background on top of it.

This is the more flexible way of working.

 

Of course for people that want very specific picons with some light effect on it, they select no background and then the TV channel picon needs to include the background and the effect.

But this is not really the scope of this thread. 

[littlesat]

I would prefer to create a full bunch of empty backgrounds and then apply the TV channel picon with transparent background on top of it.

This is the more flexible way of working.

 

This means that you in fact need to render picons twice (background, than the transparent icon).... And you need config stuff for the background... etc... etc...

 

I prefer complete sets with backgrounds included.... The set you loaded decides the background you get... In fact the rendering is done where you generate the picon... No extra setting stuff is required at all...!!!

 

How easy can it be?

 

this is the only way to have a real unique ID 

 

That was why we choose this method years ago... at that time IHAD did use service names and they had exactly this issue....

Edited by littlesat, 24 December 2014 - 10:45.

[arn354]

When someone posted on github good picon sets without any complications this can indeed be helpfull I suggest... It would also be helpfull to get the scripts to create good background etc to the picons (I do not like to draw a background seperately).And indeed it works with any provider as long the names are the same.... And spaces and change characters are removed so the chance to find a fix increases...

 

Hi - we did PiconsUpdater about a year ago. Basically the intention was almost the same (not in full, but the first step) - we wanted to reduce the maintenance efforts for picons if a service reference changes or if multiple service references exist for one service name. And for some cable providers no picon sets existed at all.

 

We store png's on Github named by servicename (reduced by some specialchars, lowercase etc.).

PiconsUpdater reads all service references/ service names in Bouquets and then downloads the picons from Github by service name. Missing png's on Github are written in a logfile.

In addition PiconsUpdater is able to merge the picon with a selected background on downloading and to optimize final png size by pngquant.

Finally we still save the picons with service reference - to further reduce amount of picons we could/should store as service name.

 

A lot people are using PiconsUpdater but only a few are supporting by adding the missing picons. Right now Germany, Austria and Switzerland is covered quite good.

 

https://github.com/g...s_PiconsUpdater

[Huevos]

BTW, for anyone who wants to convert service ref picons to service name you can use this script.

 

Put it in /tmp

Telnet to the STB

cd /tmp

python rename-picons.py

 

Output will be a zip file: /tmp/picons.zip

Attached Files

•  rename-picons.py.zip   1.67KB   86 downloads

Edited by Huevos, 24 December 2014 - 11:25.

[Pedro_Newbie]

Thanks!