Add providers for 36e #7
Comments
|
Just send your .py file to the box and reboot. And then test your provider works. |
|
It would also be nice to show the orbital position near the provider names. Some of them (NTV+, Sky) have several satellites serving different regions. |
|
OK I tested. It does find channels and transponders, but generates empty bouquets. Are the NID and TID values decimal or hex? Is the provider entry format correct? What is the method to verify the "Original NID"? |
|
|
|
I double checked all values and I am sure that they are correct. Everything seems normal during the scan process, yet I get empty bouquets. I also tried scanning OrangeTV at 16E (I used this provider entry as a sample) and it also produced an empty bouquet. Apparently these provider records are incomplete. But what should be added? |
|
Where is the LCN descriptor located on those providers because that is not in your entries? Do you know for certain these providers broadcast LCNs? Have you inspected the transport stream and located the LCNs? |
Could you point me to a how-to guide on obtaining the missing data? I do not see it at lyngsat or Enigma's channel info screens.
Yes, absolutely. There are tons of guides specific to their "official" receivers and TVs, which tell smth like "If your box is XXX, go to menu 'this and that' and do the (LCN) channel scan". The problem is that all necessary data is already known by those boxes and is never visible to the client. I do not own any of those. There are two big providers sharing the same satellites (36e and 56e) and they do not want the clients to see the competitor's channels.
How to do it? I do not have the CAM to decrypt their streams, but there are some FTA promo and shopping channels from them. |
I found dvbsnoop (on the box) TSReader and TSDuck tools for analyzing the streams. Now the problem is that I need the raw dvb stream recorded, but the damned box only produces filtered .ts as tv recordings. dvbsnoop cannot get any data. I have 4 tuners in the box but only 1 adapter. When I tune to an Info Channel on a transponder recommended for tuning I have excellent signal quality and the channel runs fine (it is tuner 'C' out of 'ABCD') , but dvbsnoop throws this error. I also tried other numbers (0-4) to no avail. So, is there a working method to extract the raw DVB stream using an Enigma2 box? (My box is Sezam Marvel running OpenATV 7.4). |
|
Instructions for stream recording (if your box is capable): https://github.com/oe-alliance/AutoBouquetsMaker/tree/tools/scripts%20and%20tools/Stream%20recording |
It seems that dvbstream cannot tune to the necessary stream. linuxstb/dvbtools#2 |
|
No, you have to tune the box, e.g. use satfinder on tuner A. Once it is tuned start the recording of the stream. |
Tuner A cannot receive that signal physically. That cable is connected to C and I am far-far away. I have to wait until I can approach the box and change the cabling. |
|
Ok. |
|
I have made the recordings, but this git does not allow me to attach them. "File size too big: 25 MB are allowed, 26 MB were attempted to upload." Is there a way to send them via e-mail? Here is my current version of the new sections in the providers.py file: The plugin is now able to create the "Tricolor" bouquet with channels inside, but 1) I only see the channel numbers without any channel names, 2) the selection bar marker does not move in this list (channel selector works well in other bouquets)
and 3) the "Last scanned" bouquet shows the newly found channels, but the channel names are in the wrong codepage. It looks like the microsoft-cp1251 text was wronly interpreted as iso8859-1.
|
|
The same codepage problem exists with HTB+. There should be an option in the provider entry to specify the 8-bit codepage they use to broadcast the channel names. In this case it can be KOI8-R or microsoft-cp1251. ! Non-LCN scan gets all channel names for the same channels right. |
|
You can send to me. |
'###' hides your email address. |
|
try again please |
I tried to resend that letter but got the same mail failure notice. Meanwhile, you can try these cloud links to the same .ts files. I hope it works. https://cloud.mail.ru/public/V23e/QQiYHH3RA - Tricolor Patched providers.py |
But according to Lyngsat your transponder details are wrong. e.g. |
|
I had to change the frequency and polarization because the transponder (36e 12437 R) I had entered before is/was not available from the LNB at my present location (It is different than a month ago). I forgot to change the other data! You are right that it has to be chaged too. I changed the HTB+ provider entry to: And tested it. It works, but the codepage problem in channel names remains. The screenshots I sent before still apply to both providers. Both HTB+ and Tricolor bouquets created after LCN-scan still contain only channel numbers and the services in them are not selectable. The "bat_lcn_descriptor": 0x83 line is my guess and I suspect that "nit_other_table_id": 0x00 line may be wrong too. It seems to be better to use "BouquetID": 0x3000 instead of "BouquetID": 0x1 because bouquet 3000 lists all the provider's channels and bouquet 1 contains only the basic nation-wide ones. The initial "Looking for transponders" phase also seems faster this way. |
|
Have the cloud links to .ts worked for you? Maybe I can get .ts samples for other satellites and providders (Telecarta, MTS, etc) from another person. |
|
That is wrong, wrong, wrong. Why did you change that? |
|
The transport stream recording says the channel name encoding is ISO-8859-5. |
It was my wild guess based on the fact that TSReader shows that bouquet 3000 contains full list of all relevant channels, while bouquet 1 contains only a part of it. Changing "BouquetID": 0x3000, to "BouquetID": 0x1 or vice versa does not change anything in the scanning output. I do not claim any deep knowledge in DVB standards or the logic inside the plugin and I have no information on how to write a good provider entry for satlcnscan except for the providers.py file itself (which is not enough). I am ready to test and accept any corrections.
OK. Iso8859-5 was extremely rare, but here it looks plausible enough. Anyway the plugin fails to convert the channel names to Unicode and ends up with completely unreadable garbage strings, possibly with illegal unprintable symbols which break something or bad unicode. Just for the context: It has been common case in the past when an 8bit codepage was wronly labeled or not labeled at all causing web pages and text documents to be unreadable. Old pre-unicode software, such as browsers and text editors always had a codepage selector menu to fix that. MS Windows enforced cp1251 as standard and Unix promoted KOI8. |
|
The plugin is handling what the table says is there. ISO-8859-5 is the default. Converted to unicode here: https://github.com/Huevos/SatScanLcn/blob/master/SatScanLcn/src/lamedbwriter.py#L145 This is just a single byte charset. |
|
Does iso8859-1 does not have symbols to encode cyrillic service names. It would explain why all names are empty strings. But it does not explain why digits and Latin letters disappear too. Other plugins can scan the same services and store their names correctly. |
|
Ok, you don't get it. It is a one byte charset. 0 - 255. |
This step ruins it all. converting the numbers to Latin-1 replaces all cyrillic symbols with unrelated (garbage) extended Latin symbols. This DVB codepage standard is not applicable here because the provider just cannot use Latin-1 to encode cyrillic alphabet. It is not iso8859-1 at any step. Just my experiment: This is what happens after replacing "iso8859-1" with "utf8". Replacing it with iso8859-5 causes a python error. By the way, Polish, Czech, Hungarian providers should use iso8859-2 (East European). |
|
You don't seem to get it. In the SI table each char is a single byte, between 0 and 255. Even if the .so converts to iso-8859-1, that is just reversed in the python code (if necessary) and decoded to the correct charset requested in the SI table. |
|
Ok, we are testing "HTB+_0360" only. If you test more than one thing at once you are mixing up the data. So please stop enigma (init 4) |
|
Here are the same files but with the Forced channel names option ON. |
|
HTB bouquet has no channels, just spacers. |
|
|
Your lamedb looks good: If you open channel list, press RED for all services... are the channel names screwed in that section? I will test your lamedb here (in openvix) and see how those channel names look. |
Proof: CLEANSCAN_FORCEDNAMES.tar.gz |
|
By the way, as far as I know openATV have removed this plugin from their feeds. |
|
That should fix the forced names. Pleased test. Then I can look at what is going wrong in the bouquet. |
Great! It works now in both modes. |
I installed it from their feed just days ago. OpenATV 7.4. |
|
Please post the providers.py you are using. |
|
From your log: This looks like complete nonsense that your provider is outputing. |
Definitely removed from the build: |
Issue #900 oe-alliance/oe-alliance-core#900 reported. |
It does not support my Sezam Marvel receivers, which have 4x tuners and transcoding functions, rarely if ever found in other models. |
Maybe the plugin should use NIT instead? Is there a how-to about writing providers.py and what to look for in the .ts sample files? Various sites say that LCN is a proprietary grey zone with many non-standard quirks.
providers.py.tar.gz |
|
You need to look at your transport stream recording for HTB. I see nothing in the NIT for LCN, only BAT. Use a program like DVB Inspector or similar. |
What am I supposed to find there? The variables in the provider enries are not seen in the DVB stream. What is bat_lcn_descriptor and how can I find it? Maybe it is worth to make a fallback mode that would take all Last scanned channels and put them into the generated bouquet? The plugin successfully finds all relevant transponders ignoring ones for the other provider and finds all physically available channels it should find. It just fails to put them into the bouquet (and arrange in the LCN order). Unordered list is better than empty list. |
|
Just open your transport stream recording with DVB Inspector or similar program. |
And?
|
|
|
|
So here is my current HTB+ entry. Since (I think so) you confirm my guess that the bat_lcn_descriptor = 0x83, the only thing in the "bat" section I am not sure about is Bouquet 1 contains the main national channels and that's it. Other similar bouquets (2...B) contain topical channels (Sport, Cinema, Documentary, Kids, Music, etc.). At the same time bouquet 0x3000 references all channels together. What is it for? Isn't it the main content list from which individual parts of the provider's package are referenced? Can I omit I do not see any nit_other_table in the .ts, and you told me that NIT does not provide any LCN data in this case. |
|
So try this: |
These are not regions. HTB+ has two "regions" broadcasted from two different satellites: 36e west and 56e east. They carry slightly different sets of channels. The bouquets here are topical. All of them should be tuned in every geographical region. Therefore I think that "bat_regions" is not the right option. I have tested this configuration but nothing changed. The resulting bouquet is still bogus. |
|
|
And that option in the interface is not needed and is misleading for this provider. There are some "basic" and "extended" packages. Some channels are available to all subscribers (I am not one) while other require extra payment. There might be "basic" and several "premium" bouquets, but not what the interface suggests. |
|
The idea of the plugin is to read the data contained in the SI tables. You seem to want something different. |
I do not know what the SI tables are. I want to get the plugin work and generate a list of channels, even if not ideal. Currently it generates a list of numbered spacers(?). The two providers do have LCN, even if it is a different style than, say, Polsat has. |
|
Service Information tables are the tables contained on the transport stream, e.g. NIT, SDT, BAT, etc. The job of the plugin is to read those tables and create a bouquet. It job is not to decide what is appropriate for any particular provider or user. If the tables are broken on your provider that is not the fault of the plugin. |
As far as I know after reading the net, LCN is not fully standard and there are flavours or quircks specific to different providers. It might be that HTB+ has its own flavour. I do not know the internal logic of the plugin, but it should be able to support different variations. DVB analysis tools recognize LCN numbers and channels in BAT, so it should be parseable, even if the algorythm is a bit different. When the plugin cannot build the correct list of channels, it could have a fallback mode to produce something usable (e.g. list of all channels from the provider's transponders) instead of garbage or at least tell that it has failed. Currently it says to the user that everything is OK, but the result is an empty list (Orange 16e) or a list of useless spacers (HTV+ 36e). I also tested Polsat at 13e and it works nicely. |
I made a possible patch adding two major providers for 36e (NTV+ and Tricolor). Unfortunately I cannot test it because I do not know how to modify the compiled
providers.pycfile correctly or rebuild the plugin package myself.36e.zip
The text was updated successfully, but these errors were encountered: