OpenATV 7.2 EPG disappearing

giopet,

Are you an OpenATV tester? How many years does it take the OpenATV team to fix a bug in the skin.py code related to INCORRECT scaling

enigma2/skin.py at 90537c9e213a8e3ff0c6ed0a6e2700b61418b961 · openatv/enigma2

openatv-gui. Contribute to openatv/enigma2 development by creating an account on GitHub.

github.com

def parseCoordinate(value, parent, size=0, font=None, scale=(1, 1)):
*****
****
if "f" in val:
     val = val.replace("f", "*%s" % getSkinFactor()) 
try:
     result = int(eval(val))

WTF ??

getSkinFactor() - returns the scaling factor relative to the currently used resolution something like 0.8 or 0.6 or 1.2 or 1.4 e.t.c.

In the skin it is set something like this

 <widget name="detail-left" position="710*f,246*f" size="266*f,133*f" font="Regular;18*f" foregroundColor="#5499C7" transparent="1" zPosition="2" split="1" dividechar=":" colposition="0"/>

The current code logic (which has not changed there for 6 years) does the following

val = "710*f"
val = val.replace("f", "*%s" % getSkinFactor())
val = "710**1.2" ????? WTF ????? 

You write there to the "writers" of this code what should be like this

if "f" in val:
     val = val.replace("f", "%s" % getSkinFactor())

And then everything will work as intended, and not those "nonsense" as it is now - exponentiation instead of multiplication

Quote from giopet

Test it with next Image Update:

Well, I tested BEFORE I tell you, and found and fixed this error in the code... You are not in a hurry with the "versions" there yet ... I will throw you more corrections tomorrow ... there is a lot more to edit I put this image on my VU+ ... get ready for reasoned criticism

Quote from abu baniaz

Thank you for the correction. There are no dedicated code writers, everyone who submits changes and improvements does so in their free time.

It will be a lot more beneficial if you could submit pull requests for any bugs you find as well as improvements.

The other issue you mentioned about EPG not showing in infobar even though EPG is present affects several images. Possibly something to do with with polling.

1) I understand perfectly well that OpenATV is a "product of the collective mind" and how any open source software can be improved / modified / fixed e.t.c by anyone "who understands what is written in the code"

2) I don't think I'll be doing pull requests for any bugs, I don't use the OpenATV image on a daily basis. Although .. who knows =)

3) EPG import error at 100500% is not an EPGImport plugin error. This is an image C code error. I know python very well, but the last time I wrote in C was 20 years ago =). Yes, I easily read C++ code, but I'm unlikely to look for errors or change something there. I described in sufficient detail how to get this bug. Further, it is necessary to "catch" in DEBUG mode the logic of data generation when writing (overwriting) the epg.dat database

Hi pepsik,

can you please try to find one channel with the import issue.
I need one channel for debug.
It's very complex to debug if there are more channels in the bouquet.

I also need some more info how to run the import, because I do not use the epgimporter.

Quote from jbleyel

can you please try to find one channel with the import issue.

RE: Epg importer ?? There is exactly one channel on which it always dies

Quote from jbleyel

It's very complex to debug if there are more channels in the bouquet.

In fact, there are two errors and they are different:

1) This is a C-code crash as in the example from the link above

2) This is the disappearance of EPG events after they are re-imported. In this case, it is necessary - init 4 / init 3 before re-importing, otherwise the bug with the disappearance of EPG events does not appear. In this case, I will try to find a pattern and prepare a test "option"

Quote from pepsik

1) This is a C-code crash as in the example from the link above

2) This is the disappearance of EPG events after they are re-imported. In this case, it is necessary - init 4 / init 3 before re-importing, otherwise the bug with the disappearance of EPG events does not appear. In this case, I will try to find a pattern and prepare a test "option"

You can send me your settings file for the epgimporter plugin.

I will check issue 1 first. ( .. Travel Channel HD ..)
But I think this is a problem in your bouquet file.
Is this file really UTF-8?

Quote from jbleyel

Is this file really UTF-8?

Of course UTF-8 ... What "suggested" you to the idea that this is NOT "UTF-8"? This bouquet-file contains about 100 entries .. and only on this code "dies" ... This error DOES NOT occur on any of the images except OpenATV 7.2 ... For tests, the same bouquet-files and EPGImport configuration files are used, which are generated by the same software

Снимок экрана 2023-02-01 в 15.14.24.png

Quote from jbleyel

You can send me your settings file for the epgimporter plugin.

I will prepare test configs in which these errors occur and send you

Update:

And I have no crash with this file.

userbouquet.favourites.tv

Please send me all needed files from /etc/enigma2 to reproduce the crash and the import issue.
I need only one bouquet and one channel for each issue.
lamedb and EPG.dat is also needed.

Quote from jbleyel

And I have no crash with this file

Such a serviceref as yours cannot exist, more precisely, it will not be unique and it is impossible to "bind" EPG events to it

#SERVICE 4097:0:1:0:0:0:0:0:0:0

And in my userbouquet

#SERVICE 5001:0:1:8858:f76a:6ae6:1010101:0:0:0:

In fact, in obtaining a unique event hash in the C-code used only

8858:f76a:6ae6

p.s.

REFTYPE:FLAGS:STYPE:SID:TSID:ONID:NS:PARENT_SID:PARENT_TSID:UNUSED - EN 300 468 - V1.11.1 - Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems

I think I need your files.

Quote from jbleyel

I think I need your files.

I have already prepared for you a test set of everything you need and will soon send you a private message

pepsik , not everyone uses DVB(1) as streamtype for live I know they should use DVB(1) but for IPTV sometimes 4097 is better depending on provider.

Now, because of you, I used the EPG-Import plugin on my Octagon SF8008, which is a part of OpenATV 7.2, and when I let it import EPGs of Slovak and Czech stations, there was no problem.

epg1.jpg

epg2.jpg

When I let him import the EPG for German, Austrian and Swiss stations, no problem either.

epg3.jpg

epg4.jpg

Quote from urie

not everyone uses DVB(1) as streamtype for live I know they should use DVB(1) but for IPTV sometimes 4097 is better depending on provider.

You didn't understand anything from what I wrote. For eEPGCache, neither 1:0 nor 4097:0 nor 5001 nor 5002 matters... You can use any "player" - this does not affect the EPG in any way

Quote from Warder

there was no problem.

Because you are doing the wrong thing... I described point by point how to get the problem.

Test files sent to developers. Wait for the results.