Box crashes when I access EPG

[malvin1]

How are you creating the bouquets?
I created the bouquets "completely regularly" in openvix-5.4: create bouquet, add service to bouquet.
Openvix-6.2 install brought them back from the vix-mutant2400-rel-5.4.016-20221014-0900.tar.gz backup.
I am not able to create a new bouquet, as the "Add service to bouquet" crashes in the new system (see the previous crash log).
But I deleted the "Last Scanned bouquet" and started a scan, so the "Last Scanned bouquet" is created by the new (openvix-6.2.010) system.
The EPG crashes in this, also.

What provider?
It doesn't depend on that!
EPG crashes at all channels in the bouquet, meanwhile everything is working in "Satellites" (see jpg-s attached in the previous post)

What country/language?
System language is English.
The language of the EPG-s tested are most different: Hungarian, English, German, Greek, ...

Summarized:
If starting from "Satellites" (see epg1.jpg) all EPG-s are working, starting from bouquet (old or newly created as well) causes a crash at each trial.

[Huevos]

It would seem there is bad encoding in the channels you are trying to add.

5.4.016 was python 2. That would ignore bad encoding.

[Huevos]

First put the bouquets in a zip and post on here.

Then create an empty bouquet and try adding to that.

Report the result.

[malvin1]

I got it !
#NAME SAT - 9°E - Eutelsat 9B / Ka-Sat @ 9° E

The symbol ° interferes.
There were a few bouquets with that, but most of the bouquetnames did not contain it.
After deleting ° symbols from #NAME, everything works.

It's interesting, that in rows 2-3 it does not make any problem:
#SERVICE 1:64:9:0:0:0:0:0:0:0::=== Eutelsat 9B / Ka-Sat @ 9° E ===
#DESCRIPTION === Eutelsat 9B / Ka-Sat @ 9° E ===

The more interesting, that despite of that, the bouquet is visible, the channel selection works,
and it is even editable (rename, move),
only the EPG asked from all bouquets crashes (started from bouquets not containing the ° symbol as well)
and the "add service to bouquet" function also crashes, while it is not known to which bouquet I want to add the channel.

By the way, e.g. the ° symbol is acceptable in the Slovak code table of VIX.
sk.jpg
This is a sw failure, isn't it ?

[twol]

I got it !
#NAME SAT - 9°E - Eutelsat 9B / Ka-Sat @ 9° E

The symbol ° interferes.
There were a few bouquets with that, but most of the bouquetnames did not contain it.
After deleting ° symbols from #NAME, everything works.

It's interesting, that in rows 2-3 it does not make any problem:
#SERVICE 1:64:9:0:0:0:0:0:0:0::=== Eutelsat 9B / Ka-Sat @ 9° E ===
#DESCRIPTION === Eutelsat 9B / Ka-Sat @ 9° E ===

The more interesting, that despite of that, the bouquet is visible, the channel selection works,
and it is even editable (rename, move),
only the EPG asked from all bouquets crashes (started from bouquets not containing the ° symbol as well)
and the "add service to bouquet" function also crashes, while it is not known to which bouquet I want to add the channel.

By the way, e.g. the ° symbol is acceptable in the Slovak code table of VIX.
sk.jpg
This is a sw failure, isn't it ?

The issue is how the symbol was originally encoded, and if the encoding is not utf-8 then there is likely to be an íssue

[birdman]

The issue is how the symbol was originally encoded, and if the encoding is not utf-8 then there is likely to be an íssue

Although I'd argue that shouldn't make Vix crash (i.e. make it unusable). It should just display the offending part using 'backslashreplace' (or 'surrogateescape').

[Huevos]

Although I'd argue that shouldn't make Vix crash (i.e. make it unusable). It should just display the offending part using 'backslashreplace' (or 'surrogateescape').

??? This is a c++ crash. Those files are read and written by c++.

If you know the best way to fix please send a pull request.

[birdman]

??? This is a c++ crash. Those files are read and written by c++.

<337251.5412> 15:20:59.8560 UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc9 in position 9: unexpected end of data

A UnicodeDecodeError looks like Python to me...

[Huevos]

A UnicodeDecodeError looks like Python to me...

1) That is a c++ exception. It happens before the result is returned to python (SWIG).

<337251.5416> 15:20:59.8563 SystemError: <class 'UnicodeDecodeError'> returned a result with an error set

2) That is not the crash we are talking about anyway but if you know how to fix it that would be helpful. Or are you talking about the crash in ABM that was fixed last January? https://github.com/oe-alliance/AutoB...da2010d0306725
3) Currently that c++ exception is protected by a try/except but that leaves a hole in EPG data.
4) The following is the crash we are talking about.

< 37259.6921> [eRCDeviceInputDev] emit: 1
< 37259.6927> [InfoBarGenerics] Key: 352 (Make) KeyID='KEY_OK' Binding='('OK',)'.
< 37259.6929> [ActionMap] Keymap 'OkCancelActions' -> Action = 'ok'.
< 37259.7005> [Skin] Processing screen 'BouquetSelector', position=(0, 0), size=(1920 x 1080) for module 'BouquetSelector'.
< 37259.7344> [Skin] Processing screen 'SimpleSummary' from list 'BouquetSelectorSummary, ScreenSummary, BouquetSelector_summary, SimpleSummary', position=(0, 0), size=(255 x 64) for module 'ScreenSummary'.
< 37259.8462> PC: 75c14bd4
< 37259.8462>     00000000 00000001 00000000 7705a020
< 37259.8462>     0000762f 0000762f 00000006 00000000
< 37259.8462>     00000007 00000001 75d40000 75d80000
< 37259.8463>     75d400f4 75d78c24 75d78c3c 75ebf3c8
< 37259.8463>     0000762f 75d30000 75d30000 00000006
< 37259.8463>     00000001 00000000 04b3c4a8 01231bcc
< 37259.8463>     00000018 75c51b90 00000000 00000000
< 37259.8463>     75d34580 7fb84910 00000000 75c14bc0
< 37259.8466> Backtrace:
< 37259.8471> /usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x46F058]
< 37259.8472> linux-vdso.so.1(n/a) [0x77099540]
< 37259.8474> /lib/libc.so.6(n/a) [0x75C14BD4]
< 37259.8476> /lib/libc.so.6(gsignal) [0x75BCDC3C]
< 37259.8478> /lib/libc.so.6(abort) [0x75BB86B8]
< 37259.8478> -------FATAL SIGNAL (6)

[birdman]

1) That is a c++ exception. It happens before the result is returned to python (SWIG).

Agreed, but I think it happens after python passes in a "string" that isn't utf-8?

4) The following is the crash we are talking about.

.....

No idea about that one

[ocean]

4) The following is the crash we are talking about.

< 37259.6921> [eRCDeviceInputDev] emit: 1
< 37259.6927> [InfoBarGenerics] Key: 352 (Make) KeyID='KEY_OK' Binding='('OK',)'.
< 37259.6929> [ActionMap] Keymap 'OkCancelActions' -> Action = 'ok'.
< 37259.7005> [Skin] Processing screen 'BouquetSelector', position=(0, 0), size=(1920 x 1080) for module 'BouquetSelector'.
< 37259.7344> [Skin] Processing screen 'SimpleSummary' from list 'BouquetSelectorSummary, ScreenSummary, BouquetSelector_summary, SimpleSummary', position=(0, 0), size=(255 x 64) for module 'ScreenSummary'.
< 37259.8462> PC: 75c14bd4
< 37259.8462>     00000000 00000001 00000000 7705a020
< 37259.8462>     0000762f 0000762f 00000006 00000000
< 37259.8462>     00000007 00000001 75d40000 75d80000
< 37259.8463>     75d400f4 75d78c24 75d78c3c 75ebf3c8
< 37259.8463>     0000762f 75d30000 75d30000 00000006
< 37259.8463>     00000001 00000000 04b3c4a8 01231bcc
< 37259.8463>     00000018 75c51b90 00000000 00000000
< 37259.8463>     75d34580 7fb84910 00000000 75c14bc0
< 37259.8466> Backtrace:
< 37259.8471> /usr/bin/enigma2(_Z17handleFatalSignaliP9siginfo_tPv) [0x46F058]
< 37259.8472> linux-vdso.so.1(n/a) [0x77099540]
< 37259.8474> /lib/libc.so.6(n/a) [0x75C14BD4]
< 37259.8476> /lib/libc.so.6(gsignal) [0x75BCDC3C]
< 37259.8478> /lib/libc.so.6(abort) [0x75BB86B8]
< 37259.8478> -------FATAL SIGNAL (6)

Most likely it crashes when trying to display character. To fix it you would need to find out where it uses that string.

Fix could then be similar as in movielist.py, chardet.detect()

Ofcourse C++ code should also be fixed so that it does not crash. I did mention this before here:

https://www.world-of-satellite.com/s...encoding/page9

[Huevos]

Most likely it crashes when trying to display character. To fix it you would need to find out where it uses that string.

Fix could then be similar as in movielist.py, chardet.detect()

Ofcourse C++ code should also be fixed so that it does not crash. I did mention this before here:

https://www.world-of-satellite.com/s...encoding/page9

It is a "º" in a bouquet file causes the crash when trying to add an additional channel to the bouquet... but the bouquet is from Py2 version. So first test he need to do is create the bouquet file using the current version.

[Huevos]

Agreed, but I think it happens after python passes in a "string" that isn't utf-8?

No. The service ref is passed to EPGCache. The junk is in the EPG data. The return value from EPGCache to python is returned with the exception set. There is a workaround in python to avoid the crash. https://github.com/OpenViX/enigma2/c...21e2f8facb78cc but we need to workout how the junk data is getting in. Maybe the wrong encoding flag is being sent in the SI table, or none at all.

[birdman]

No. The service ref is passed to EPGCache. The junk is in the EPG data.

That was certainly the case several years ago.
Anything using externally-supplied data should be able to get by without crashing regardless of what is sent, since in practice you have no control over it.

[Huevos]

There is nothing wrong with the query. You can even play with the duration and find out exactly which program is responsible, but not part (title, description, etc).

The exception is return from this function: https://github.com/OpenViX/enigma2/b...pgcache.h#L221

I would be interested in feedback from @ocean.