116 replies to this topic

[Rob van der Does]

Different things.
1- At first I had the epg.dat on USB of the server box; that was not found by PLi. Solved by me by moving the file to the HDD.
2- From then on the manual import worked fine; the automated import failed often (as we described above probably due to trying to read the file while it was still epg.loading.dat).
3- Since flashing the PLi 4/9 image it doesn't work 100% of the time (as described in the later postings).

On the ViX-side nothing has changed, and ViX as server + ViX as client worked and still works fine.

[littlesat]

Look ar our code... the wierd thing above where it gors wrong nothing changes...... so I’m afraid it is a thing out of scope...

Edited by littlesat, 7 September 2018 - 18:38.

[Abu Baniaz]

Should this issue be closed now?

https://github.com/O...gma2/issues/829

[littlesat]

I added some comments there....

[Pr2]

With all your latest changes it is no longer possible to control the epg.dat loading at boot from EPGimport.

You can disable all the option in EPGimport the epg.dat is ALWAYS loaded at boot.

The only way to avoid this is to delete the epg.dat from its location.

 

So I guess that in case of corrupted epg.dat we have a risk to come in an infinite reboot loop. EPGImport was protecting against this by checking the last crash log to see if epg.dat was the culprit and stop loading it.

[littlesat]

Why do you need epginport on a client box as it imports the epg from the server box? I also think there is no relation to the latest changes... the change was not read the initial epg.dat... but download it first from server and then read the imported epg.dat

Edited by littlesat, 14 September 2018 - 06:47.

[Pr2]

I don't use client box, it is on my main box. I have no more control on the loading of the epg.dat

 

But what you still don't take into consideration, is that a client box will only receive the same channels as the server box. As already explained you can have a remote box that have it's own capabilities not present on the server box (for exemple remote box is MIS capable while the server is not, or DVB-T or DVB-C).

 

The former approach was nice, we define a remote fallback tuner and it uses it for channels that client box doesn't receive locally.

[littlesat]

This whole feature is totally not intended for the mega complex situation when the client box also has 'receiver' capability with different receiver capability than the master box. It is just there for a box without having cable, sat or terrestrial connection -or- at least has less of the same options with the tuners. The latest change I made should only disable the inital parsing of the epg.dat in case the feature for fallback tuner has epg download enabled....

 

I don't understand the control of loading the epg.dat on the server box. The box still has it's own control. When the client box needs epg it gives an 'order' via OWIF to the server box to create a new fresh epg.dat which is later downloaded to the client box and then read in the client box. Sorry I don't get your point.

Edited by littlesat, 14 September 2018 - 09:06.

[Pr2]

Forgot about the remote box for my problem:

 

My problem is:

- Even if I disable all the epg.dat loading at boot in EPGimport the epg.dat if it exists is now always loaded at boot.

 

So it is no longer possible to start the box without any EPG information.

 

The only possibility for me is to delete the epg.dat and reboot the box, so I have a totally EPG free box. Perhaps this was always the case and the expected behaviour of Enigma2.

 

So question is:

- How am I able to control the epg.dat loading in Enigma2 today?

If it is not possible I think that we should foreseen an option in the EPG selection screen to load epg.dat at boot or not.

 

I am quite sure that EPGimport has an import mecanism of epg.dat at boot because they also foreseen a "crash log analysis" to check if the epg.dat is corrupted or not.

 

So there is a double "epg.dat" loading at boot if we have EPGimport installed and if we enable it in it.

 

Here is the EPGimport implementation:

 

https://github.com/O...GImport/boot.py

 

Pr2

Edited by Pr2, 14 September 2018 - 10:15.

[littlesat]

So you want to add a feature... do not load epg.dat at startup at any time...?

 

Actually I already did something like that with the epg import from the fallback tuner box as this does the same... Maybe it might be considered to add an extra config to it that aranges the epg is never  'parsed' at an E2 start...

 

So add something here in line 385 of epgcache.cpp (and of course add the config config.usuage.load_epg_dat in python and setup.xml so it can be edited....)

 

load_epg = ConfigManager::getConfigBoolValue("config.usuage.load_epg_dat") && eConfigManager::getConfigValue("config.usage.remote_fallback_import").find("epg") == std::string::npos;

Edited by littlesat, 14 September 2018 - 10:21.

[Pr2]

Yes indeed that's what I am thinking of.

But the option should, I think, check if EPGImport is installed and proposed 3 option:

 

Yes, No, EPGImport

 

So, if people want, they can select which is handling the epg.dat loading at boot.

 

For your information EPGImport also save the epg.dat after Import. ;-)

[Rob van der Does]

It's not a 'mega complicated situation' when the client box also has it's own tuner(s).

My client box has a mega simple setup: all sat-services come from the server box while the client also uses it's own DVB-T tuner for a few local stations. So the locally received DVB-T EPG should be combined with the remote received DVB-S EPG.

[Pr2]

EPG is not the problem with the current approach the problem is that the userbouquets and lamedb is simply overwrited by the new remote server approach.

So if you use the download bouquet you can only use the remote server, the local bouquet are simply overwritten and the lamedb is also overwritten.

 

So on your remote box, if you can receive channels by its own tuner you cannot use the Remote Server import bouquet.

 

This turns me crazy before I discovered what's happens:

- My remote box is capable to receive MIS (Multi Input Stream) the server isn't and I had my channels and favorites containing MIS channels disappeared at boot without any apparent reason, nor warning at all!

 

So in an hybrid mode where both server and remote are capable to use there local tuner this new implementation is frustrating and hard to figure out on what's happens with this mystery channels disappearing.

 

The solutions are:

- Rename the donwloaded bouquet to include remote server name (to avoid overwrting since it is logical that people use locally the same favorites on there different boxes)

- Do not delete the existing userbouquet that are not on the server box.

- Properly merge the entries in the lamedb (and not overwriting it!)

 

Today this Remote Server is only valid for tunerless remote box (which is quite restrictive I think). I think that people will rather use it on hybrid mode where we want to define the remote server (like they where doing before with the remote fallback).  Or at least set a big red warning to inform user that all the local bouquet and lamedb will be lost if the download remote bouquet option is enabled!

 

Pr2

[Rob van der Does]

EPG is not the problem with the current approach the problem is that the userbouquets and lamedb is simply overwrited by the new remote server approach.
So if you use the download bouquet you can only use the remote server, the local bouquet are simply overwritten and the lamedb is also overwritten.

Yes!

[littlesat]

That is indeed true... And note the feature for getting the settings was never intended for your 'complex' situation.... It was intended for having a fallback tuner which is at least capable of having everything the 'client' box also has.... In the situation you describe you should 'join' the stuff manually... You NEVER can do a CLEAN synchronization of 'settings' in that situation when the client box can receive by itself channels that the fallback/server box does not have. You simply CANNOT solve it... The cullpit here are not the userbouquets (however you can have the issue of 'ghost' userbouquets when you do something to this). but the lamedb that 'needs' to be merged and currently is just one file. 

 

When someone can invent a merge E2 service settings 'software'... we can discuss further trying to get that feature 'merge bouquets and lamedb' added... (I was aware of it and I repeat for now it was out of scope of the design)...

 

During the design of this feature these kinds of complex things were out of scope. The Goal was first create it for clients, without tuners in use (-or- at least was just capable of tune into itself what the fallback/server also can do). So what it is download the settings from the fallback/server box. When succesfully downloaded remove the settings from the client and then install the downloaded settings on the client... You indeed loos the extra 'gadgets' the client is capable off... (Which also means the client is not a clear client!!!)

 

A work-a-round for you might be considering to get the services for the extra special tuner added to the server (by adding the bouquet with a settings editor which also add them to the lamedb on the server box)/... this also enables you to use these channels on the server box as you can set it here as fallback tuner without synchronizing settings. But you need to perform some manual actions after you scanned these services. Optimal is of course add the special tuner to your fallback/server box.

 

it is valid for a client box with a tuner... but all services the client can tune... the server/fallback tuner must also be capable to tune...  When the client can tune something the server/fallback can't... it is getting tricky

Edited by littlesat, 14 September 2018 - 14:10.

[Rob van der Does]

Well, I 'solved' (actually 'worked around') the issue for my simple setup by adding the DVB-T bouquet to the serverbox, as the last bouquet (where those services obviously are greyed-out).

[Rob van der Does]

So in an hybrid mode where both server and remote are capable to use there local tuner this new implementation is frustrating and hard to figure out on what's happens with this mystery channels disappearing.
 
The solutions are:
- Rename the donwloaded bouquet to include remote server name (to avoid overwriting since it is logical that people use locally the same favourites on their different boxes)
- Do not delete the existing userbouquet that are not on the server box.
- Properly merge the entries in the lamedb (and not overwriting it!)

This seems to be a fine solution to me. This way it will also work for a tuner-less box, as there are simply no local services.
In fact the same as RemoteChannelConvertor does; but that one doesn't take EPG on board.

[Pr2]

@Littlesat,

 

Yes but how people can know the current limitation of the implementation?  There is absolutely no warning at all, even when the remote client query the server we saw no prompt at all.

End-user must be clearly warmed of the current limitations, it takes some times for me to find the culprit of my MIS channels and favorites dissapearing.

 

So please rename the userbouquet to reflect where they are coming from to at least not overwritte the local usebouquet. And moreover we will saw where the channels are coming from. And only overwrite those userbouquet and not any other one with other names. This will at least allow to use this feature on hybrid system without having yet the proper lamedb integration.

 

To add entries in the lamedb the only problem is to get the TP details.  So if you are collaborating with OpenWebif to get a json object returning for the imported bouquets the "lamedb needed" informations, we can then add the information into the lamedb.

 

But if we think further why do we have to add channels into the lamedb?  If you convert the #SERVICE 1 into #SERVICE 4097 (since it is IPTV now) you wlll also get the EPG on the channels.... give it a try. :-)

You don't need to have entries in lamedb to have EPG informations loaded.

 

Conclusion:

- Rename the userbouquet file name to add the server

- Change the userbouquet header to mention the server

- Replace all #SERVICE 1: by #SERVICE 4097:

 

And I think that your implementation will also cover the hybrid system.

 

Pr2

[ims]

why change 1 to 4097 ? I am using this feature for copy bouquets to next machines (with tuner and dish) home ...

Edited by ims, 14 September 2018 - 14:42.

[littlesat]

@Pr2, 

There is no simple solution for that unless someone invents a very complicated merge settings code. And the actual issue is that E2 does not have a manual. What you're trying to do is totally out of scope. The way the settings in E2 were designed is working against it... And you can do a work-a-round, by performing a relative 'simple' manual action which also arranges you to view the channels that you cannot receive on the server can be received on the server!... 

 

The comment at the setting is now...

_("Import channels and/or EPG from remote receiver URL when receiver is booted")

 

We could consider to change it to

_("Copy channels and/or EPG from remote receiver URL when receiver is booted")

 

Which maybe better describe what it does.... (and change all other 'import' to 'copy' texts in that code).

 

I also recommend not to investigate further. Believe me I started some investigation how you can 'merge' service settings bouquets and lamedb and I did not find a real solution yet without having a risk of endless growing lamedb and bouquets and having other side effects.... this is not simple....! And for a full client box or a client that cannot receive stuff the server can't adding it is not required at all...

Edited by littlesat, 14 September 2018 - 15:02.