276 replies to this topic

[Rob van der Does]

BTW: There is more to 'flagging' then just hide-VBI, such as language/subtitle settings. They also cause issues, as we've seen in other threads.

[littlesat]

Yep... And finally you get it... the complicated solution solves more than 'just' the VBI remember issue...

[littlesat]

Are you actually saying that when I have services (both in and not in bouquets) that do not exist anymore will be deleted without using this option?

If so: why does that option even exist?

Now all services (from a specific position) are purged... by just removing them from the lamedb... so this includes the flags... and that is why the flags are not remembered and also the language prio's etc...

I still did not find a good 'protocol' that cleans the lamedb from the non-existing services. One option I was thinking of was remove the services that are not available in any user bouquet. I was also thinking of keeping a separate file for the flags, but you need to clean this as well with some kind of algorithm. In addition you also need to have something in place when you download settings (e.g. Hanssat) as an upgrade also clears all the flags. A separate file is here also a solution - but you can also consider to make some kind of 'merge' lamedb... 

The mean reason I did not create commit something related here was that I could not define a good protocol....(as einzelganger)

[WanWizard]

A separate file is probably the best short term solution, as that migrates the best to another seperate system in the longer term. Removing services not in any bouquet is imho a very bad idea.

 

Cleanup could be a background task that is started once a scan with cleanup is finished?

[littlesat]

Beside cleaning 'flags' and 'services' we also need to clean unlinked 'transponders' within the lamedb file itself...

 

'Removing services not in any bouquet is imho a very bad idea.'

Why? (note a 'brainstorm' starts...)

Doing it in a 'background' task might also have side effects... e.g. do some scans... planning more scans but in between restart E2 or do nothing due to a recording etc.... clean suddenly starts which removes flags... Oeps.... 

 

To define the whole mechanism is a whole 'teamwork...'

 

Storing the flags in a different file.. by splitting e.g. the lamedb5 file into lamedb5 and prioflagsdb5 was something I tried months ago... But also when trying it I was alone (einzelganger) without help..... Hopefully this thread initiated sowething
 

Edited by littlesat, 26 September 2018 - 11:03.

[WanWizard]

Because that basically removes your "all" list? How are you going to add new channels to your bouquets if channels not in there are removed?

[Rob van der Does]

....One option I was thinking of was remove the services that are not available in any user bouquet.....

Not a good idea:
1- Not being in a bouquet doesn't mean not available and/or useful.
2- When deleted the background scan will bring them back.

[littlesat]

How are you going to add new channels to your bouquets if channels not in there are removed?

They are already automatically added into the last scanned bouquet...

[ims]

It is nonsence remove services when are not in bouquets...

[WanWizard]

They are already automatically added into the last scanned bouquet...

 

That contains the "tast scanned" list, not the all channels list. And they are different if you scan a subset of what you can receive (a single transponder or sat, DVB-C, S or T), etc.

[Rob van der Does]

How are you going to add new channels to your bouquets if channels not in there are removed?

They are already automatically added into the last scanned bouquet...

Of course, but that's a volatile bouquet. The contents is normally saved in the 'all' list, from where it is usable. Unless you decide to delete (parts of) the all-list.....

[Pr2]

Indeed total non-sense to remove services that are not in bouquet. I need to use the All list to sometimes test to confirm a bug on a particular channel that I daily never watch so I don't need to have them into a bouquet and of course I don't want to need each time to scan this TP to access the channel.

 

And why keep a flag on a service that has potentially changed?

 

Again I will explain here (once more) that french providers are used to swap there channels between 2 service references! So if you keep your flags for this particular service reference it won't make any sense to keep it after a scan because the same service reference is now another channel! that's why clean before scan is useful for me.

[Abu Baniaz]

I always select the Clear before scan to always have a clean lamedb.

This has been discussed before, clear before scan will only clear the services on the frequencies that are scanned. If a frequency is no longer listed in the XML file, services will not be removed.

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

[littlesat]

When the userbouquet trick does not work....we end-up in a NOGO solution.... so you CANNNOT solve it... The circle is round... there is actually no good way to free the lamedb from non existing services.

B.t.w. I usually only zap in userbouquets...

 

 

This has been discussed before, clear before scan will only clear the services on the frequencies that are scanned. 

 

This also purges the flags and priorities...

 

But it 'opens' new ideas.... flag them as 'deleted' with a flag and when they are re(scanned) and the service already exists disable this 'deleted' flag (which also means keep all the other flags)...  and after the scan remove (or clean command) the services that are still on deleted...  Or simply ignore to re-read these from lamedb at the next e2 restart...

Edited by littlesat, 26 September 2018 - 15:11.

[littlesat]

We just need some reference about a non existing service that can be removed. I was just suggesting a service should be within at least one userbouquet. When this is not good we need to investigate for another mechanism.... that was why I suggested the delete flag... (we than also probably do not need a separate flag/prio file) with finally pursing services after the scan mechanism you also don’t have too loose flags... we just can set the flags... clear the flag when an ‘existing’ service is scanned. And don’t read the delete flagged services at enigma2 (re)start...

Edited by littlesat, 26 September 2018 - 17:00.

[Pr2]

Why not create a central database in "the cloud" where OpenPli can get the information about a services and retrieve all the the flags? So this database can be maintained and we will know which channel needs to hide the VBI line or not? 

Why make it simple when we can make it complicated? 

[WanWizard]

The flags are user specific, so I don't see the point. 

 

I still wish everyone in the community would be able to move their ego's aside, sit together to design an architecture for "Enigma Next Generation", and then start a properly managed project to turn that architecture into a proper design that can be worked on together.

 

If it is designed properly, with a split frontend (GUI) and backend (core), and a proper and well designed API, every team can still create their own image with their own frontend, without the need to constantly reinvent wheels, while not moving forward at all...

[Pr2]

Compute a hash on the channel name and store it in the lamedb so you can see if the channel name has changed or not during scan... so you will know if you need to restore the flags or not... 

[littlesat]

Channel name is not sufficiantly Unique... so it is not really possible to keep flags when a provider moved a channel...

Edited by littlesat, 27 September 2018 - 06:25.

[Rob van der Does]

For me the problem is fixed by the plugin.
I really don't miss 0,0018518518518519 part of my picture