128 replies to this topic

[malakudi]

@Chris: running current enigma2 with export ENIGMA_DEBUG_LVL=3 still has issues for you?

 

@MiLo: is the optimization included in eerror.h supposed to disable all eDebug messages in normal operation for non-debug version of the binary? Because it doesn't. You have to set ENIGMA_DEBUG_LVL to 3 or less to disable them. By default all debug messages are shown. The part of the code where:

#ifndef DEBUG

# define MAX_DEBUG_LEVEL 0

#else

# ifndef MAX_DEBUG_LEVEL

#  define MAX_DEBUG_LEVEL 4

# endif

#endif

...

if (((lvl) <= MAX_DEBUG_LEVEL) && ((lvl) <= debugLvl))

 

seems to have an optimization when DEBUG not defined to only allow level of 0 to get printed. However, all enigma2 production binaries seem to have DEBUG defined, because it is in 

lib/python/enigma_python.i , line 141

#define DEBUG

[christophecvr]

I personally have been out since now almost 9 weeks. But the basic debug written by mirakels is very very good. Point is when i made the integration so that at least I user could select (by e2 python interface as an option) it has been revoked extremely brutally by mirakels and some other pli core members without any reason .... ????  Even if they would have put one single reason why not ??? never done except putting -1 on my really CORRECT remarks about it ....

 

Now after 9 weeks we are still (i did not checked the commits yet but only the forum for now) looks like it's still a complete stand down. This for a problem righter TREMENDOUS bug in enigma2 which is most probably THE CAUSE of the unexplainable  tempo lock to even full freeze of e2 ad random at wild .

[malakudi]

@Chris: please forget the -1 man, don't behave like your avatar in Southpark. What is done is done, I will give you ten +1 to compensate. Please test current code and confirm that there is no issue if we set export ENIGMA_DEBUG_LVL=3 before running enigma2.

From my understanding of the code used in eerror.h, I think Milo tried to disable logging completely (except type 0, alert) in https://github.com/O...262d798be2fd442 , so an option for user would not be needed anymore because only alert messages were to be shown for release binaries. But it fails since #DEBUG is defined. If this is not the case, we definitely need to set default debug level to 3 or less.

[MiLo]

The DEBUG define is indeed silly and should be removed.

The "MAX_DEBUG_LEVEL" setting sets a limit to what gets compiled in. If you compile with MAX_DEBUG_LEVEL=4, any output with level >4 will be eliminated from the binary and cannot be enabled runtime. However, the compiler will still process the statement.

If you'd compile with MAX_DEBUG_LEVEL=3, all eDebug() code would be removed, resulting in a smaller binary.

I guess what needs to happen is to re-assign levels. Some eDebugs may need te be promoted (e.g. error messages and important warnings), while others may be demoted so they get removed from code.

Patches to do so are more than welcome, especially if they reduce the amount of useless logging.

[MiLo]

In "enigma2.sh" calling:

ENIGMA_DEBUG_LVL=3 enigma2

would have the effect that running from init will omit all the eDebug output, while starting E2 manually will default to displaying everything.

[MiLo]

And I still don't have a clue what christophecvr wants. Can we please skip the politics?

[malakudi]

@MiLo: as the code currently is, eDebug calls are all still getting executed by default in released images. If that was not the intention and I understood the code correctly, we should either change default debug level to 3 or less, or build the binary without DEBUG defined. Am I correct?

[WanWizard]

I can imagine that for "expirimental" images, you leave the debug level as high as possible, and for stable releases, as low as possible.

[MiLo]

@MiLo: as the code currently is, eDebug calls are all still getting executed by default in released images. If that was not the intention and I understood the code correctly, we should either change default debug level to 3 or less, or build the binary without DEBUG defined. Am I correct?

The current situation is intentional, it outputs the same amount of debugging as the original version. I was afraid plugin builders would get mad at me for changing something.

[littlesat]

I suggest the best we can do is put it like this in enigma2.sh

 

ENIGMA_DEBUG_LVL=3 enigma2

 

Then usually it gives less debug data and when you do init 4 enigma2 you still see more details...

 

But indeed... plugin builders could get MAD...

Edited by littlesat, 31 March 2016 - 12:32.

[WanWizard]

We can solve that with v5: developers should use the expirimental image, not the stable image. And endusers should use the stable image, they don't need debugging info.

[malakudi]

Well, since it is intentional to stay as it was, I guess Chris has a point complaining because he has proven (I can verify his claims) that eliminating many of the eDebug messages delivers a better usage experience of the STB, especially on lower CPU power boxes.

We can't wait till having two production images (stable/experimental). I suggest enforcing default debug level to 3 or less (with enigma2.sh change or code change), and any developer who wants more output can use the environment variable to increase back to 4.

Edited by malakudi, 31 March 2016 - 12:49.

[littlesat]

(I can verify his claims)

->

Do you have a real reproducible example? The gstreamer buffering was very clear... but furthermore I did not see any real concrete example to verify... and as long we only live on rumors there will be no action.... A subtitle sometimes a bit later as it should be can be considered a non major issue... But as far I see for these eDebugs we have already introduced a different level... at least I see some eLogs 5 and 6 levels there.... that should defaultly not been seen anymore...

 

When we do something short term I prefer to change the level in enigma2.sh... This is an easy patch with direct effect... But it also might has disadvantages... When we get GSOD we get also less information....

 

So you have to weight less info in debugs to a the small (or big?) chance of an anomaly occurring due to too many debug info...

Edited by littlesat, 31 March 2016 - 12:58.

[WanWizard]

Malakudi's suggestion seems like a reasonable workaround for OpenPLi 4, the current images are classified as "enduser" images.

 

I am not sure that changing the level gives the same result, as I understand from earlier postings, the eDebug calls are still executed, but don't output. So that needs to be verified before a decision can be made.

[malakudi]

@littlesat: On ET4000 that I still have around (which is a very low powered CPU box), it is more than obvious the difference in disabling eDebug messages when playing back media, especially with multiple audio tracks and subtitles. However, I only test with master-next so can't really tell about OpenPLi 4.

[MiLo]

... as I understand from earlier postings, the eDebug calls are still executed, but don't output...

With MAX_DEBUG_LEVEL the debug code is actually removed (optimized away) by the compiler.

In any case, the eDebug statement and everything in it is completely skipped when the level is not active. So something like:

eDebug("Number: %d", calculate_something());

The "calculate_something" method will NOT be called at all when the debug level happens to be below 4 at that moment. It expands to something like this:

if (debugLevel >= 4) {
  log("Number: %d", calculate_something());
}

So lowering the debug level will make the code run just as fast (give or take a nanosecond) as if the debug statement wasn't there.

[malakudi]

And that explains the difference I experience when settting loglevel lower than 4. It is not placebo.

[WanWizard]

In that case I would like to suggest to go for adding a runlevel to enigma2.sh for OpenPLi 4 (devs can modify that if needed), and go for the compile time option for OpenPLi 5 to create a smaller binary for the stable images.

[littlesat]

+1.... But.....

@malakudi,

Did you only see this difference when playing mkv's with servicemp3? If so we could also consider to give more eDebugs a different level in servicemp3.cpp instead of changing the default level....

Edited by littlesat, 31 March 2016 - 15:22.

[WanWizard]

I would suggest making that two different actions: one is to set the default debug level in the image, and the other a global code review (not only in servicemp3) to make sure all eDebug calls have the correct level.

 

Your suggestion feels a bit like a "quick fix workaround" to me, that doesn't really address what needs to happen...