question / discussion: how to make picons service list generation better? --> region or localization tagging?

[dreamcat4]

It seems to me that at the moment, we query either VDR, Enigma, or Tvheadend APIs to 1. buils the SRP service list.

However it would be better to build service list based on the region where the user is situated. And then give them all applicable Picons within that area. For example: DE for a German user. Or US or UK. And so on.

However then it's required to resolve those regoinal information inptu. Into a list of those relevant .snp and .srp lookup files. Or to have some such mechanism to lookup from the srp what region any specific channel(s) belongs to.

And historically (since the beginning of this project)... it seems whenever people add new Picons, this regional information is never required / asked for / provided? For example when i look at the .srp and the .snp file here.... it's just channel names and SRPs. However what if (for example) "channel 5" exists in multiple countries? (but is different channel). And so on. This seems insufficient to provide such regional feature.

Any yet clearly most people are located in a specific place. And this will always be the case... people are only are receiving or are actually interested in broadcasts from a specific (small number) subset of regions, satellites, antennaes. It could be more than 1 region. But rarely ever more than just a selected few of them.

And using regions approach we no longer would encounter missing picons around scanning channels, yet can still cut down the total number of picons to only those available into a specific set of region(s).

For example if there are 100-200 countries. Then selecting only 1-2 regions (where the user actually can "see" all of those channels within those regions)... then cuts down the size of picons folder by a factor of 100. Which is good enough... it's actually not as good to miss channels within a region simply because the antenna cannot "see them" at the time of scanning. Since that then misses any channels that either has a poor reception, or simply were not put online at the time. But later became new channels.

So achieve such goal... is maybe 2-3 main options:

• 1. Either use an external regional lookup service, that holds the list of [same SRPs]
• 2. Or have the format of the exist in-repo .srp expannded to then also require region infos included as extra field(s).
• 3. Maintain 3rd lookup file (for SRP --> region pairs) within repo.

Clearly it would be cool if such 1) resource already existed elsewhere on the web. Such that we could just query HTTP api webserver. And it return back a list of SRP references selction. Which includes all of the channels belonging to the selected N region(s).

I am just wondering now where is such resource... and/or how it is adequately maintained and updated. And if such resource already exists... then why we haven't yet update here our 1. build script to include as another option / ways to generate the service list? To then feed into stage 2.

[AbuBaniaz]

Location should be in the service reference. The namespace in the service reference has the orbital position. Default on all Enigma2 distros is to exclude the Network ID, so that somewhat limits further pin-pointing The orbital position should suffice. As you mentioned, SNP does not allow for regionalisation. Where there are different versions, the service reference is added to the snp file.

Until progress is made, you can always build against a bouquets/lamedb which will only include the ones you have.

And using regions approach we no longer would encounter missing picons around scanning channels,

Please rephrase. People scan, find picons are missing, report, we add links/logs, picons are created. Unless we use SNPs, we will always be playing catchup.

[Lexzie]

About channels with the same name:
If that's the case, f.e. with 'TV1', we have only one of them with tv1=<logoname> in snp.index.
The other will have <service reference>=<logoname> in snp.index.

Although I'm always surprised how little often that happens.

[dreamcat4]

hi again!
Thanks for these infos guys...

can always build against a bouquets/lamedb

OK so after some further looking about on the web, have stumbled across this 3rd party GUI based software tool:

https://github.com/DYefremov/DemonEditor

And it really seems quite good for these purpose! ..since it has some capability to get such Bouquets data from online sources. Which appears to be from LyngSat or KinfOfSat. And lets you select satellites etc.

This is quite nice, and it also has something about picons included too. Although I am still learning how to use these things. And select services correctly...

Anyhow I just thought to say thanks. And see how this one goes for now. Because the data provider seems right for satellites... although was not checked get ground based terrestrial (for example DVB-T/T2, aka 'Freeview' etc.)

[dreamcat4]

ah ok... so for these SRN:

1_0_1_1969_7E6_2_11A0000_0_0_0

• then the 1969 is the SID (service id = channel number ref.)
• and the 11A0000 (hex) --> 282 (dec) --> 28.2E --> astra 28.2

ok but then how is the middle part determined? this: _7E6_2_ ?
[edit] (and it can be different for different services in the same sattellite / same bouquet?)

[AbuBaniaz]

What device are you using? If you are using Enigma2, just get the files from there. I am pretty sure all the UK ones use the same service references.

Maybe we could have different SRP. Index files for each satellite? I don't know. But in essence those files just create symlinks. All the logos are in one folder. Building different versions would need to avoid conflicts.

[dreamcat4]

I see. What i am trying to do is generate the logos output from an online source (for bouquet / service list). Which is then not requiring a working device. To pre-install the correct and complete set of picons for the selected bouquets / region. This is the goal here.

DemonEditor does indeed seem to offer some level of functionality. And the SRP it generates seems to confer with the picon:// URIs being populated within the tvheadend server. So long as these SRPs are following some standardized format... which is what is less clear being some sorts of ad-hoc standard between various projects.

For example: yesterday --> i can right click in DemonEditor here. And it copies (to clipboard) the following SRN:

1_0_1_1969_7E6_2_11A0000_0_0_0

And then over in tvheadend (independantly of DemonMachine tool)... the column in the channels list was filled (from broadcast bouquet) as:

picon://1_0_1_1969_7E6_2_11A0000_0_0_0.png

So this does indeed appear to be the same exact SRN. (at least for this 1 example channel that was picked on, it would be another task to check across all of the entire list of 936 listed services).

So this is the task / goal. Not to require some running TV server (or other hardware) to pre-generate some .tgz archive of the picons. During prior building of the software. Before it can be installed / setup.

[dreamcat4]

which then returns back to this question asked:

how is the middle part determined? this: 7E6_2 ?
[edit] (and it can be different for different services in the same sattellite / same bouquet?)

Since the derivation of the other 2 components of the SRN has now been clearly understood.

[AbuBaniaz]

https://enigma2-http-api.readthedocs.io/en/latest/utils.html

[Lexzie]

ok but then how is the middle part determined? this: _7E6_2_ ?

That's the ONID (Network ID) and TID (transponder ID).

and it can be different for different services in the same satellite / same bouquet?

Yes

[dreamcat4]

Thanks again guys...
In the end, it seems like this is a pretty good description of the reference ID components. Just somebody posted it onto a tv entusiast forum,

https://www.opena.tv/english-section/43964-iptv-service-4097-service-1-syntax.html#post376271

So maybe we could just copy that explanation? I will probably just copy it into a gist myself, for future reference. But would be appreciated something like this included in the picons README. (or just a link to it)...

===

As for the whole "download bouquets online" --> create services list --> generate initial Picons. (before any scanning step). Well this is my main focus and desire.

So what I was able to do was from DemonEditor --> "Save" function. And it spits out a lamedb (v4) file. Which I then tacked onto a basic SRP parser into your 1. first bash script. That if a file named lamedb is detected in the build-input folder. Then it can attempt to parse / generate "something like" SRP list.

However with the information provided by DemonEditor, it might be slightly different than the infos in scans. Which would break the picon:// mathing URL for any (even minor) differences. So it's not really at a level yet to be included.

The other thing is that this 1st version only includes SRP (no SNP)... and it only supports lamedb v4 database file format. I would need to try to do more work on it, in order to improve "enough". To get it into something more complete.

The other thing is - being written in bash it's slow to parse (for larger lamedb database). For example: my own bouquet satellite export file was about 1000 entries in the services section. So to parse 1000 entries it was not unbearable or anything. However it did seem like "nothing happening" for a few seconds.

This then raises a question if it makes sense to calculate how many entries to process (before begin task). And if it's more than N entries... then to inform the user how many it's starting to process. And then every 100 entries print another log line updating like this:

100 / 10,969 entries processed
200 / 10,969 entries processed
300 / 10,969 entries processed
etc...

So if you guys can indicate level of interest / what I can avoid bothering with. For example if none of this is ever going to get accepted or considered. Or which things doesn't matter versus which things does.

Clearly I would like to try and support the lamedb v5 and also try to do SNP generation next. And then see how that ends up. Perhaps (3rd on my list). Would be to try to speed up the per-line processing time. To make it a bit faster (within reason, because to support better channel name processing, that also might incur some added processing time).

[dreamcat4]

Ah yes, another good resource (from a forum post):

https://www.satsupreme.com/showthread.php/194074-Lamedb-format-explained

[mrhotio]

Hey, @dreamcat4

So from my understanding and your desires...imo you can deliver "regionalized" picons as the project is today...it's just underused, preferably people build against their lamedb and thus have "regions"...

Also keep in mind, the picons related aspect only starts from step 2., step 1. just builds the input file which is basically telling step 2 what to do...this file can be generated however you want, even by hand. But as far as I know, nobody build any generator besides me...

As of right now, I do not use satellite tv any longer and don't see mee using it in the foreseeable future, so I have 0 interest in this project, so I haven't kept up with the latest development in the entire enigma community, but if you are able to update the scripts and improve them, I'm happy to review pull requests, you can pm me on my discord server from my other github repo, see https://hotio.dev

[Lexzie]

Maybe indeed a good idea to post some more "How To's". I need some time for that.
Keep this open as a reminder.