106 replies to this topic

[Huevos]

@Littlesat, thanks for your comments. I have a few questions...

 

1. How could I save hundreds of lines? The part that writes the user bouquet file is only 20 lines. This plugin doesn't touch lamedb.
2. How can Fastscan and Cablescan be considered plugins. They include c++ enigma code and can't be moved from one distro to another.
3. How can this plugin create a race condition? It just writes to its own user bouquet file, and with the plugin open what other process is it going to be racing against?
4. What is the difference between creating bouquet files on the STB and creating them with a settings editor and FTPing them to the STB? Both require a reload. Why would you consider creating them on the STB "poking around" and creating them on DBE not so. If there were a race condition it would exist for both.
5. OpenWebInterface is also a plugin that "pokes around" in settings files and does reloads. Is that not OK either?
6. What about RemoteChannelsStreamConvertor, or PLi's built in channels importer. Would you also consider that "poking around" in bouquets?
7. What functions does enigma use to create bouquet files that are available to Python plugins?
8. How does the code duplicate any bouquet parsers? It does not read any bouquets.
9. Is my code really unreadable, slow, and unstructured?

Thanks in advance for your opinions.

Edited by Huevos, 21 May 2019 - 12:56.

[littlesat]

Good questions...

 

1. How could I save hundreds of lines? The part that writes the user bouquet file is only 20 lines. This plugin doesn't touch lamedb.

-> ABM etc. do parse the complete userbouquet and lamedb etc first... all of this code can be removed.

1. How can Fastscan and Cablescan be considered plugins. They include c++ enigma code and can't be moved from one distro to another.

-> In C++ they add services to lamedb and the bouquets without 'poking' in files. They directly add the services/bouquets within e2. The same method can be used in python. It might be of course we need to swig additional functions... but as far I can see 'all is there'

 

1. How can this plugin create a race condition? It just writes to its own user bouquet file, and with the plugin open what other process is it going to be racing against?

You can have two processes... one rights in the files and do a reload, while E2 is e.g. scanning in the background and make updates internally. When ABM is done it does reload the setting and then you may overwrite some changes.

1. What is the difference between creating bouquet files on the STB and creating them with a settings editor and FTPing them to the STB? Both require a reload. Why would you consider creating them on the STB "poking around" and creating them on DBE not so. If there were a race condition it would exist for both.

Yes with a setting editor that writes via FTP (or something else) to /etc/enigma2 you actually have the same kind of issue. The settings editor does 'poke' around. And when you do e.g. at the same time a scan you can get a mess...

 

1. OpenWebInterface is also a plugin that "pokes around" in settings files and does reloads. Is that not OK either?

-> Also the incorrect way to do it... 

1. What about RemoteChannelsStreamConvertor, or PLi's built in channels importer. Would you also consider that "poking around" in bouquets?

-> Also the incorrect way to do it... 

1. What functions does enigma use to create bouquet files that are available to Python plugins?

-> All functions required are available here https://github.com/O.../lib/dvb/db.cpp or better to review here https://github.com/O...op/lib/dvb/db.h

1. How does the code duplicate any bouquet parsers? It does not read any bouquets.

For example here bouquets and lamedb are parsed... Actually all these code is already done and available in the source I mentioned above... So actually you duplicate code in python which is already available in c++... sorry that I did not go in further detail and just took this as example.

 

https://github.com/o...uquetsreader.py

 

1. Is my code really unreadable, slow, and unstructured?

Yes.. actually you duplicate code.... and poke around... while you can directly add/remove services and bouquets in E2 and once adapted you can save all settings instead of doing a reload... 

 

P.S. I understand that to make this better requires more time to investigate... but I'm convinced the end result will be less code (I think only for ABM > 300 lines removed) as you somehow can directly write found services into e2 without doing something like it is done now...

 

1. Force a save setting

2. Parse the settings

3. Adapt the settings for what is found with ABM

4. Reload the settings... 

 

With my suggestions you can do...

3. Adapt the settings for what is found with ABM

4. Save the settings (just to keep them when e2 crashes or the box is hardly plugged out)

 

I hope it is somehow clear now... 

 

Then additionally there is a separate .so to parse the streams... when something general could be added in E2 that can be used by plugins etc... with nice functions to access them then the .so is not required anymore... Might also be nice...

Edited by littlesat, 21 May 2019 - 15:16.

[Huevos]

OK, so you are talking about ABM, not the MIS scanner.

 

Anyway C++ or Python is not important. The majority of the run time is spent reading the transport streams, which takes up to 30 seconds for each transport stream, not the few micro seconds that it takes edit the text files.

[littlesat]

I’m talking about both... and it is not (only) on speed... it is more about a structured way to do it... avoid duplicate code which you have now... etc... and please note I also know it will be more work... but rebuilding the parsers in enigma2 took also time...

Edited by littlesat, 21 May 2019 - 18:36.

[Huevos]

I’m talking about both... and it is not (only) on speed... it is more about a structured way to do it... avoid duplicate code which you have now... etc... and please note I also know it will be more work... but rebuilding the parsers in enigma2 took also time...

Biggest problem is not easy to share from one distro to another like can be done with a plugin.

[littlesat]

But the dB.cpp is still approx the same... and the so file could be migrated to cpp (or actually the complete parser)
But now I started to argue all once... I started here with the creation/adaption of the bouquets

Edited by littlesat, 21 May 2019 - 22:45.

[Erik Slagter]

 

Maybe Lyngsat was "requested" to remove the PLS values (for the reason in the post above). In that case we should grab it otherwise or we could adjust the grabber script to insert them explicitly.

 

Regarding making bouquets, LCN, etc. I don't like them inside enigma, that would mean a pile of code for every provider, no thanks. So a plugin makes perfectly sense.

After exchanging a couple of emails the values have now returned... so no need to do anything.

Nice!

Thx.