E2m3u2bouquet - discussion & support

There are 1,215 replies in this Thread which was already clicked 88,912 times. The last Post () by pepsik.

    Quote from jeepcook

    Compiled just for you ;-)

    It very crude "build" ... serviceapp - on feed for py3.11, and therefore it is not working ... I think there are still many such plugins with old bytecode on feed

    Code
    13:23:13.9194 ImportError: bad magic number in 'Plugins.SystemPlugins.ServiceApp': b'\xa7\r\r\n'

    p.s. There are certain difficulties with multiboot ...

    Quote from pepsik

    It very crude "build" ... serviceapp - on feed for py3.11, and therefore it is not working ... I think there are still many such plugins with old bytecode on feed

    Code
    13:23:13.9194 ImportError: bad magic number in 'Plugins.SystemPlugins.ServiceApp': b'\xa7\r\r\n'

    p.s. There are certain difficulties with multiboot ...

    Yes ServiceApp is broken, it's true. I will see because I have successful installed it on this new version. I'll do a feedback later.

    For multibot the STATUP_x in /boot is copied as STATUP but the process don't reboot the system, just do an enigma2 restart, you have just to reboot to change partition.


    This version is not a beta, not even an alpha .....

    Edited 2 times, last by jeepcook ().

    Quote from jeepcook

    Yes ServiceApp is broken, it's true.

    Theoretically, it's easy to fix it without waiting for feed ... As far as I remember the structure of precompiled bytecode in 3.12 is not different from 3.11 ... so it's enough just to substitute "magic number" in existing pyc files


    Quote from jeepcook

    just do an enigma2 restart,

    That's understandable. I've done all the research.

    Quote from jeepcook

    This version is not a beta, not even an alpha .

    It's true... none of this is for the average user yet.

    Quote from pepsik
    Quote from jeepcook

    Yes ServiceApp is broken, it's true.

    Theoretically, it's easy to fix it without waiting for feed ... As far as I remember the structure of precompiled bytecode in 3.12 is not different from 3.11 ... so it's enough just to substitute "magic number" in existing pyc files


    Quote from jeepcook

    This version is not a beta, not even an alpha .

    It's true... none of this is for the average user yet.

    Your machine will have access to new feeds soon (ore later ;)) The compilation is for the moment at vimastec1500 receiver.


    7.4 was in beta version and stable few days ago, just before the integration of python 3.12. Now it's a dev version. OATV Team made a mistake to share it as beta.

    Installation done on a new home made image compiled for my sf8008 (at least 1000 packages have been recompiled since last build).


    Everything seems ok with e2m3u2 1.3 and OATV team has fixed all detected bugs in the 20240122 build. So now we are still in beta version but a stable one.

    hi pepsik


    Would like to ask if will be possible "schedule EPG" move from "Configure card" to "Provider card"


    reason - have pluto bouquet and request epge update every 8 hours but other bouquets have EPG for 5-7 days

    i see no reason why you should redownload these EPGs every 8 hours just for one bouquet.


    it happens to me several times, when updating "pluto EPG" the other EPGs are not downloaded and the bouquets remain without EPG or only partially updated


    It would be possible to save the settings from the "Configuration card" (on the HDD) as a "provider card" - within the activation of the bouquet and settings


    Thank you

    VU Zero4k ATV7.3

    Quote from sarsan

    "schedule EPG" move from "Configure card" to "Provider card"

    You can make any logic you want. ... as long as it does not contradict the hardware capabilities of your equipment =)

    EPG import consumes almost 100% of resources of your "device" ... You can see it, for example, in top or htop utility ... That's why EPG import is sequential if you have several providers ... i.e. import of next XMLTV will not start until import of previous XMLTV is finished.


    Several schedules with a high probability imply the possibility of simultaneous import of several XMLTV ... i.e. the import of the previous one is not finished yet, and it is already necessary to import the next one and maybe even more than one ... This is definitely "death" to hardware resources of your SAT-reciver ... And the more "schedules" - the more probability of "parallel" launching of import tasks


    Even if we make a “directory” (catalog) of schedules with the possibility of applying them to certain providers, we never know how long it will take to import XMLTV data and therefore there is no unambiguous logic that will prevent the simultaneous import of several sources... and this is, as I wrote above, - the “death” of your SAT receiver


    I hope it's clear up to this point ?


    The solution is to move the "import/not import" to the proider card ... but here's the schedule - one common one

    Quote from jeepcook

    a lock file check by the import process or something else to avoid simultaneous imports.

    These are fantasies from misunderstanding.


    The only way to do this is to create a queue of tasks whose time has already come and constantly check this queue for the presence of tasks according to the schedule, for example once every 10 sec,. or use semaphores of the threading module

    jeepcook

    The main problem is that right now there is only a schedule to update the bouquets. It works the same for both "manual" and scheduled updates. EPG update is an option that may or may not be available after bouquets update. The idea that you "support/promote" requires the creation of a separate schedule for updating only the EPG excluding bouquet updates, and in the context of specific providers, not a general schedule for everyone ... In principle it can be implemented ... but it is necessary to think very carefully about the unambiguous logic understood by all users of the plugin.

    If we leave the existing logic of bouquets creation and the possibility to import EPG after their creation as it is now and just add separate "schedules" for "refresh" of EPG for already existing bouquets created by the plugin, it is most likely, it can be implemented without major changes to the existing code and its logic. I'll have a look/think about it over the weekend

    In reality I support ask from sarsan but I don't really need it. I have scripts which do the job:


    I have a playlist containing a lot of channels and some pluto tv and samsung tv ones, the epg for this list is named epg.xml


    - each day at 8h45 I grab rytec epg and some others

    - each hours I generate an epg containing the 8h45 epgs adding a new grab of pluto tv and samsung tv ones, but the epg.xml is the full version only at 9h05

    - from 10h05 to day +1 at 8h05, I generate a light epg containing only what I need for my favorite playlist and need to be update so essentially pluto tv and samsung tv. The other events have been imported with the generated epg at 9h05 and it's no needing to import them again for the next 24 hours.


    It's just a summary of my manipulations, there are few other options to be sure that 9h05 generated epg is really imported. This description is just to understand how I do to have the solution proposed by sarsan.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login