Jump to content


Photo

merge requests for PLi's git


  • Please log in to reply
1748 replies to this topic

Re: merge requests for PLi's git #1741 littlesat

  • PLi® Core member
  • 57,472 posts

+708
Excellent

Posted 28 October 2023 - 07:05

Nope. When there is no network or better no time known yet enigma 3 syncs with to transponder time. It cannot switch back to system time.’this is hard coded in cpp.
In addition why should we need answering at all for this? Better to get this always automatically and take the best time source.
Everyone is so focused here on a setting that was created by me that is not working as it was intended off that we all forgot the real target here and that is what everyone wants..:. Having the best possible time source. And that is simple. Box not on internet (or better no connection to ntp) use transponder time, box on internet use internet time. And I think when there is initially no internet time use transponder time when possible initially and as soon internet times comes up switch to internet time. And that part ‘when internet time comes up’ is a mechanism I have no idea how to create it. Here I need help. And as soon I have help here it can be done right.
And then stil the setting can stay as the above is only valid for auto. For ntp only without the temporary fallback a change in cpp is mandatory.
Next challange is we cannot allow time jumps in enigma2 as timers (eTimer) will behave wierd. This means once the time is set you need slowly adjust when it changes.it can even create interlocks/races. This is a bigger painpoint.
So at the end when a user really only wants to rely on ntp the only easy solution is wait until the network is up and we have nto time. So without fixing the eTimer syndrome afterwards resync to internet time has no added value.
The biggest painpoint here is the design made years ago by those dmm enigneers.

The most easiest way to resolve this is rename the option to e.g. preferable time sync method with the options dvb/ntp. And keep it as is… but then those that have slow network come-up issues do not have ntp… and now again point to the real technical trigger that triggered this discussion. Maybe we need a complete different option to add…. Just out of the box…. Wait for internet is coming up no, with a timeout setting… with eg a popup…

Edited by littlesat, 28 October 2023 - 07:19.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1742 WanWizard

  • PLi® Core member
  • 70,936 posts

+1,835
Excellent

Posted 28 October 2023 - 15:01

Yes, and that hard coding MUST be removed when I configure NTP. If I wanted AUTO, I would have configured AUTO.

 

How difficult is that to understand?

 

 

How you implement AUTO is entirely up to you, my (and Dimitrij's) point is that NTP is not AUTO, NTP is NO TRANSPONDER TIME, NEVER !


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1743 Maros861

  • Member
  • 5 posts

0
Neutral

Posted 1 January 2024 - 21:14

Hi, just wanted to share here information which I find out with a quite a long debugging process. Situation is that I've build latest openpli develop image with python3.11 and I wanted to test SubsSupport plugin, where eConsoleAppContainer.write method is used to write to stdin of the subtitles search application. This was always returning me error:

 

TypeError: 1st arg must be a string, optionaly 2nd arg can be the string length

python/python_console.i#L192

I tried to push unicode, str and also byte objects but the same message always appeared. I've created simple test library to demonstrate quickly where can be the issue.
The issue was masked by the above custom error message, when I've removed the message the true cause was revealed:
 

SystemError: PY_SSIZE_T_CLEAN macro must be defined for '#' formats

This lead me to python api docs
 

Note For all # variants of formats (s#, y#, etc.), the macro PY_SSIZE_T_CLEAN must be defined before including Python.h. On Python 3.9 and older, the type of the length argument is Py_ssize_t if the PY_SSIZE_T_CLEAN macro is defined, or int otherwise.

So if somebody stumbles upon this is the solution.


Edited by Maros861, 1 January 2024 - 21:17.


Re: merge requests for PLi's git #1744 Beeker

  • PLi® Contributor
  • 1,616 posts

+204
Excellent

Posted 6 January 2024 - 23:15

confirmed.

Do you have a working patch?

 

Because this doesn't work with Python 3.12.1 (and with older versions either?).

diff --git a/lib/base/estring.cpp b/lib/base/estring.cpp
index 709d120e7..c12a40a38 100644
--- a/lib/base/estring.cpp
+++ b/lib/base/estring.cpp
@@ -11,6 +11,8 @@
 #include "freesatv2.h"
 #include "big5.h"
 #include "gb18030.h"
+
+#define PY_SSIZE_T_CLEAN
 #include <Python.h>
 
 std::string buildShortName( const std::string &str )
diff --git a/lib/python/python.h b/lib/python/python.h
index e3259407a..dff68ecc7 100644
--- a/lib/python/python.h
+++ b/lib/python/python.h
@@ -6,6 +6,8 @@
 
 #include <string>
 #include <lib/base/object.h>
+
+#define PY_SSIZE_T_CLEAN
 #include "Python.h"
 
 #if !defined(SKIP_PART1) && !defined(SWIG)
diff --git a/lib/python/python_console.i b/lib/python/python_console.i
index 1591570d2..5bb148f83 100644
--- a/lib/python/python_console.i
+++ b/lib/python/python_console.i
@@ -187,7 +187,7 @@ static PyObject *
 eConsolePy_write(eConsolePy* self, PyObject *args)
 {
 	char *data;
-	int data_len;
+	Py_ssize_t data_len;
 	int len = -1;
 	if (!PyArg_ParseTuple(args, "s#|i", &data, &data_len, &len))
 	{

And I've tried many more.


Dreambox dm920, Uclan Ustym4Kpro, Gigablue UHD TRIO 4K and Dreambox dm8000. Wavefrontier T55 13.0|19.2|23.5|28.2 + Ziggo.


Re: merge requests for PLi's git #1745 Beeker

  • PLi® Contributor
  • 1,616 posts

+204
Excellent

Posted 6 January 2024 - 23:44

I had to patch Python3 to suppress the error.

diff --git a/Python/getargs.c b/Python/getargs.c
index 066739f..e85b116 100644
--- a/Python/getargs.c
+++ b/Python/getargs.c
@@ -426,6 +426,7 @@ vgetargs1(PyObject *args, const char *format, va_list *p_va, int flags)
 
         stack = _PyTuple_ITEMS(args);
         nargs = PyTuple_GET_SIZE(args);
+        flags = FLAG_SIZE_T;
     }
     else {
         stack = NULL;

Problem:

The flags variable remains 0 in the whole function call chain unconditional (getsargs.c file).

PyArg_ParseTuple() (defined as 0)- > vgetargs1() -> vgetargs1_impl() - convertitem() -> convertsimple().

The only change in value is:

flags = flags & ~FLAG_COMPAT;

But that doesn't changes the value if flags is 0.

And finally always ends up  in the error, defined as macro in convertsimple().

#define REQUIRE_PY_SSIZE_T_CLEAN \
    if (!(flags & FLAG_SIZE_T)) { \
        PyErr_SetString(PyExc_SystemError, \
                        "PY_SSIZE_T_CLEAN macro must be defined for '#' formats"); \
        RETURN_ERR_OCCURRED; \
    }

Or I overlooked something?


Edited by Beeker, 6 January 2024 - 23:48.

Dreambox dm920, Uclan Ustym4Kpro, Gigablue UHD TRIO 4K and Dreambox dm8000. Wavefrontier T55 13.0|19.2|23.5|28.2 + Ziggo.


Re: merge requests for PLi's git #1746 Maros861

  • Member
  • 5 posts

0
Neutral

Posted 7 January 2024 - 15:34

@Beeker,
I think we can follow the advice which python docs suggest, and to alter the enigma code instead. This worked for me for 3.11 build.

diff --git a/lib/Makefile.am b/lib/Makefile.am
index 7f08a9ecd..7fb787af6 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -4,6 +4,7 @@ AM_CPPFLAGS = \
        -I$(top_builddir) \
        -I$(top_srcdir) \
        -I$(top_srcdir)/include \
+       -DPY_SSIZE_T_CLEAN \
        -include Python.h \
        -include $(top_builddir)/enigma2_config.h



I wanted to provide patch, but in my custom build of openpli with sdl2 in docker configure fails when I want to use python3.9 instead, so I'm not able to verify if this change is backwards compatible. Probably there will have to be some switch added when to use the define(3.9+) and when not.



Re: merge requests for PLi's git #1747 WanWizard

  • PLi® Core member
  • 70,936 posts

+1,835
Excellent

Posted 7 January 2024 - 15:41

We need to start planning an OE upgrade for develop, to Kirkstone (as Scarthgap isn't released until April, and I don't like .0 releases very much).


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1748 rantanplan

  • PLi® Contributor
  • 1,863 posts

+87
Good

Posted 10 January 2024 - 01:30

https://github.com/k.../tree/Kirkstone

I've started, but everything isn't perfect yet. BSP layer has only been updated locally so far.
Kirkstone is 'long support' (4 years).
However, images are still much too large.

But the last rebase is still missing



Re: merge requests for PLi's git #1749 WanWizard

  • PLi® Core member
  • 70,936 posts

+1,835
Excellent

Posted 10 January 2024 - 15:39

Great! I wish I could be of more help, but health wise I'm struggling.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users