Hi Guys,
First off, I would like to thank you the dev team for such a project.
I just started using Webgrab a few days ago when i decided to implement EPGs to my list of channels and I quickly noticed the amount of manual work and maintenance required to keep webgrab working as an end user...let alone as a dev (Kudos for that).
Scenario:
Currently you can only add one channel with the same ID, hence using multiple .ini files is not possible. This means that
once a .ini stops working temporarily or permanently the user needs to first off, detect that something isnt working as
intended and then search the forum/request aid for the particular .ini in hopes that someone has the time to look into it.
TLDR: The current approach is not automation friendly.
Solution:
I would change the structure of things a bit. Meaning that instead of searching through .ini files and adding a single
channel, this is all done in the backend. All you would need to specify is the country, channel name/ID and the program
would check multiple .inis if required to gather the data rather than checking the specified .ini and giving up if it
yields no data.
This would also come with additional features:
• Encryption on all .inis without the need of searching through the forums (Check user status (donator/dec/etc..) and
make use of the .inis available to a particular tier (ex: through the use of an API).
• Automation friendly for the user, once the required setup of channels is finalised, you can forget about looking
into channel lists and trying to grab a channel from a different .ini.
• One could also consider moving to a more cross platform language (GoLang, Python..) for additional features and
improved performance.
I understand that this would probably mean a total redesign of the core logic but i do believe that this would be worth investing time in since ultimately the goal is to attract more users/donators and having an outstanding masterpiece! :)
PS: I do understand that you put countless hours in such a project and i apologies if I offended you with the above comments.
Awaiting your response :)
Thanks,
x434
i am not familiar with the core, but simply one additional layer would fix such problem.
We have now site+siteid -> xmltv , what we would need is something like that site+siteid -> wgindex -> xmltv , where wgindex may be linked to multiple site+siteid with some priority and single xmltv preconfigured for the desired channels . Potential problem is the matching of site+siteid info, when should go to second, or third, predefined priority would somehow fix this. The core logic will not be affected - channelparsing and data generating, this additional wgindex would stand between generated data and the xmltv write... I am not a programmer, i just say what i think :)
Dev is using .net libraries, so moving to another lang would be a whole new project :)
Thank you both for the suggestions. A few remarks:
- I like the idea of making channel selection easier for users. Indeed it can be problematic for users to make the right selection since a lot of channels are available in several siteini's. An additional problem is that it is impossible to know on forehand the status/quality of the available siteini's for a certain channel . Some might work with all details, some with only a very limited set of epg data and some might be broken. (long ago I used to verify all siteini's before releasing a new program version, but that now is an impossible task). Another problem is that the same channel have different 'names' (xlmtv id and or display name) in different siteini's, because the source sites for these siteini's use different names. This is a handicap for utilities that try to locate the availability of certain channels in siteini's. (clever searching/matching is needed).
I think it is possible to realise this idea in a separate tool, as a kind of 'configurator'. The user runs this, gets access to the siteini pack, makes his choices and gets a config file and runs it as a test. Some years ago, a first attempt of such a tool was developed, but because of the lack of time the project was put on hold. It might be an idea to dig it up for anyone willing to continue its development .. interested ??? Attached is a peek of it ..
- It is a misunderstanding that the program doesn't allow multiple siteini's . To the contrary, that is one of its main features. It is just that, when the channel list of the channels to grab contain duplicate xmltv_id's the program interrupts and will report the duplicates that need fixing
- Another interesting idea .. rewrite the whole program !! It is currently written in C#, .Net framework 4.8 and consists roughly 35000 lines of code. Beside the 'impossible task' of porting that in any acceptable timeframe to another language, I don't see any advantage rewriting it for the purpose of making it more cross platform. Porting its current C# code to cross platform .Net Core however, is something high on my wish list. In fact , some experiments have already shown it feasibility. But as always .. manpower .
@x434
In addition to comment above:
1. Structure: Some channels are unique to a site, no alternatives. For common channels wg++ should verify if the information grabbed from first site_id is correct....if not grab from the second source, probably could be done just in case of "no index page", in any case id something wrong there will be the need to remove lines from config or update site.ini then see point 3.
2. Encryption: All updated siteini are in siteini.pack. There is only the need to add the key for EK type,most probably also this will disappear in the future when license will be fully operational. It's enough to run siteini update.
3. Automation: Sites change continuosly, there are site that change site_id quite often, either because the site number or sitename used for site_id (i.e. Sky Cinema series become #stayhome and change site_id), unfortunately there is the need to run channel list and fix changed channels, moreover there is language issue, you may find "france 24" in 200 siteini but in arabic,french,english, etc. etc. only way to properly identify is the "human" mind.
4. Programming Language: I frankly after creating lots of siteini, can tell you that wg++ is pretty good in performance. I doubt another language may have more performance then the actual one. Lots depends on sites, connection, complexity, if you are lucky to get a site that has all info in index will be very fast, programming language will not make difference. Changing language means re-do the program from scratch, wg++ has been now tested for years and post-process, if required, is very fast. There are no additional features to achieve, wg++ follow the XMLTV standards.
About the code - 100% Understandable, i was wondering if you could move to .net core, just to get rid of mono :)
about the multiple siteini;s , no problem there, but there is no way o use two siteinis for one xmltv, and the idea behind the OP is that if there is NO data from siteini, to use another one. At least this was my understanding.
I was meaning Mapping siteini+siteid to wgindex and then wgindex to xmltv and site name. Example :
Source sorting should be user decision via priority . Skip to next siteini if there is NO data. If user is not satisfied with selected source he can reorder priority, or even remove it.