On Monday March 13th 2023, our hosting provider will have a maintenance window for our server infrastructure. During this window a cooling issue of one of the buildservers will be addressed, and our 10Gbit NAS storage connection will be made redundant.
This work will commence at 10:00 GMT and may last until 14:00 GMT. In this time window, there will be periods of unavailability to both this forum and the downloads.
I'd like to have LCD display on the STBs and that's why I am using VU+ Solo 4K and Vu+ Duo 4K for my daily usage.
To be really honest without you, I prefer the default LCD skin which already give me all the informations that I want and I'd like the current proportion.
So I could not find any benefits with your modified LCD skin.
I propose a new PR with the channel id filtering. I better describe the constraints that lead to implement this solution, it is slightly improved compared to the first version to avoid some confusing entries in log.
This doesn't prevent to work on implementing the standard DVB language support into EPGImport so please view it as a Quick Win solution both solutions can live together.
End-users doesn't have to learn regex a simple cut and paste of the channel id will do the job (risk of false positive is really low and the log is clearly displaying the filtered "channel id" so debugging is easy). Moreover the content of this file for standard endusers will be explained by Doglover to easily fix there problem. Advanced users that test the solution already found benefits out of it. People can easily turn on/off one particular filter in the file since comments are allowed (line starting with a # are ignored).
The option to enable it or not on the custom.channels.xml is a specific request from Doglover.
I hope that it will be accepted because Doglover (Willy) is really waiting for it.
If the same service reference is present several time during import for the same channel id it was added anyway. So we can have useless duplicate entries in the EPGImport that will just slow it down since the same data will be loaded twice.
This patch also add support for long description to each EPGImport parameters.
Be careful that skinners will need to enable it in there skins in order to display them so for screen name="EPGImportConfig" the widget name="description" should be added.
Using language defined in the GUI won't probably solved the question here since you can decide to receive both french and english language so both will be loaded into memory and then which one will be displayed?
Does GMEPG take care of the language code, how does it handle the EPG when there are several languages available for the same service reference?
If it handles it properly no need for filtering in EPGImport just load all the possible languages for a multi-lingual channel using the same reference (but this will fill up the STB memory).
But then you should extend the number of preferred languages because 2 is very restrictive.
People doesn't have to learn regular expression they can just type the "channel id" name like it appears in the channels.xml but I propose my implementation. This PR is allowing users to have a full control on what is loaded into STB memory.
So sad that I ask for help in the development section of OpenPLi where I explain what I was doing and nobody answer me, now that the patch is ready and fully tested you reject it. I would have better invest my time in doing something else.
Here is a trial to implement the feature requested by Doglover.
Forewords
The filtering is only possible on the channel id and is based on regular expression (regex). I will not fully explain here what the regex syntax is but just a few remarks;
If you want to fully exclude all the EPG for all the channel id from france you need to use this syntax:
.*\.fr
. replace any characters
* means that any characters can repeat anytime
\. is to match the . remember . (alone) means any character for the regex.
fr is "fr"
You can also specify a specific channel id:
Discovery\.dk
This will exclude Discovery.dk is you didn't mention \. then the regex will match Discovery(1 time any character)dk
But most of the time simply specifying Discover.dk should not cause trouble but in case of doubt and if you want to be sure to have a perfect match use the \. notation.
The filtering is not case sensitive (so the whole filter that you will set will be switched to lower case because it is what is also done for the channel id matching.
So Discovery\.dk is the same as DiscoVery\.DK so you don't have to care about the exact case of the channel id name.
So filtering on anything else than the channel id is not foreseen (it is not possible to filter on partial service reference nor on comments). Why? Because the channels.xml file is processed in a true XML way meaning that every element is retrieved independently so this filter will is focusing on the channel id and nothing else (filter by reference is already implemented into EPGImport).
One line per filter a OR operation will be performed between every lines.
Please don't trust the dragnan test he was using OpenATV as main image and OpenPLi with OpenMultiboot so he was using the OpenATV kernel that is patched to enable those device.
So you I can just confirm that it has never worked in OpenPLi.
You are sending a wrong signal with the thread you create because this will let think that OpenPli will look at and fix the 3rd party skins.
Will you take the responsibility to fix yourself all the skin related issues? If so then you thread is legitimate but in the other case what will we do with all those reports?