128 replies to this topic

[malakudi]

I agree with WanWizard, we could also change the default log level (not MAX_DEBUG_LEVEL), like this in main/enigma.cpp, line 189.

debugLvl = getenv("ENIGMA_DEBUG_LVL") ? atoi(getenv("ENIGMA_DEBUG_LVL")) : 3;

instead of current default which is 4.

 

@littlesat: media playback, not just mkvs, mp4 as well, flv/avi with external subs too.

Why search which eDebug makes more trouble? eDebug, as the name shows is for debug purposes. Anyone who wants to view that, can make the change himself. A user doesn't want to run a debug enabled version, he is not a beta tester. He has to get the best performance possible. We the developers can handle the change, the average Joe can't.

[littlesat]

I was thinking about putting it in enigma2.sh... and by default when you run it at prompt keep it at level 4 so we get the outcome as we're used to... When you run enigma2 by prompt you're 'debugging' and by default you get more info automatically. That was what I think the charm of changing the default level in enigma2.sh....

 

i did not mean playing MKVs only.... I meant stuff played via servicemp3.cpp...

And it should be a balance... performance and enough crashlog for us to investigate/improve...

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

[MiLo]

Crashlogs are usually either segfaults, which basically means there's no useful information at all, or Python stacktraces, which usually plainly lists the cause already without any further help from the rest of the logging.

Having thought about it, setting the default in C code is the more logical way to do it. I don't think we actually really use the debug output anyway, so it'd be interesting to see where this would lead...

[Erik Slagter]

+1 for sure.

 

Debug output is for debugging. When you're done, remove the debug code. I've never had any use of debug prints already in enigma, in the end I always had to add my own.

[Taapat]

Segfaults usually really not provide useful information, but it is sometimes useful to see the point at which they occur.
Therefore, personally I am for debug, which is switch off by default, but the user can easily switch it on.
Not all segfaults developer can repeat.
This would allow the ask to user switch on debug, and get an extra log when necessary.
Of course if this debug not be removed by compiler, it would not provide a big benefit when working.

 

You can always compile and give the user binary with debug, but I am afraid that no one, without a special reason, not want to do so, and therefore it will reduce support for users.

Edited by Taapat, 31 March 2016 - 21:32.

[MastaG]

So.. we apply chris' patch but change it so it defaults to level 0.
And if a user experiences troubles, we tell 'em to set it to 4 (the current default) so he/she can submit a report.
Problem solved, everyone happy.

[littlesat]

I think that is also not optimal... As far I see only aervicemp3 is impacted... So I'm for level 3 with the enigma2.sh trick and move critical logs to level 5 and above and critical but helpfull logs to level 4...

[MiLo]

Almost nothing reports at levels 0..3 currently, so setting to "3" has about the same effect as "0" would. And given the insane amount of useless logging that E2 does, I suspect setting the level to 3 will have a noticable performance effect for example during startup.

[Taapat]

I wanted to add that change the log level in enigma2.sh certainly not a simple way to enable the log for not experienced user.
There is a high possibility that the user can do anything wrong.

I think that it should be realized through the config.

As I understand it has not yet offered a good solution how to do this.

[malakudi]

I think that is also not optimal... As far I see only aervicemp3 is impacted... So I'm for level 3 with the enigma2.sh trick and move critical logs to level 5 and above and critical but helpfull logs to level 4...

 

I don't understand this, why have the default level to 4 and only change it from enigma2.sh? Anyone who is going to run enigma2 directy from telnet is well capable of setting the environment variable to whatever level he/she wants. Setting default level to 3 (or 1) in the enigma2 code is the way to go.

[littlesat]

So when you do init 4 and then enigma2 by the console you still can see more.... And when it is running 'normaly' you see less... this is a feature you get for free this way... Without doing something extra's so why not doing this.... And when you still need more -or- less in the console you can still set the environment variable... but this is always something extra's...

 

I would not prefer to remove it at compile levels... When doing this I would only do it for level 6 and above...

 

Just my 2 cents...

 

So level <=3 in enigma2.sh - so logs will contain these

From console level <= 4 - you get one level extra without setting an environment variable when running from prompt.

Level 5-6-7 or so via environment

Level >= 8 arranged that it will not be compiled basically (you need to create your own binary)

 

Al all critical logs must be at least level 4 or above....

[MiLo]

I wanted to add that change the log level in enigma2.sh certainly not a simple way to enable the log for not experienced user.
There is a high possibility that the user can do anything wrong.
I think that it should be realized through the config.
As I understand it has not yet offered a good solution how to do this.

I think that no one is actually ever going to ask a user to do so. My suggestion therefore would be to postpone implementing this until after it's been demonstrated that we really really need it.

There are way too many settings already in E2, adding yet more isn't going to make things better.

[Robinson]

Maybe there should actually be 3 levels of Enigma2 user configuration, something like simple, advanced, superexpert and such options as the one discussed here could be placed in the superexpert configuration. Me, personally, prefer to have a lot of settings, but I understand a simple user would rather avoid it, so perhaps access to the superexpert config could be hidden or otherwise made difficult.

[WanWizard]

I think the biggest issue with the settings is not the number of options, but the fact that virtually nobody knows what they all mean or exactly do. There is no description, no help, just a long list of sometimes not even related options. Mainly because we're still working with a GUI that was designed in 2006 (yup, 10 years ago).

[littlesat]

And even longer... development of enigma2 actually started already before 2006....

 

That was also why I recommend to set the level to 3 in enigma2.sh... and you get level 4 for free with the console...

 

En then change the levels of the real critical logs to 3 or below...

Edited by littlesat, 1 April 2016 - 09:51.

[malakudi]

@litlesat: I still don't get it. Anyone willing to run enigma2 from telnet, can do:

init 4

ENIGMA_DEBUG_LVL=4 enigma2

[littlesat]

Yep... Technically that would work indeed...

 

But practically you need to type "ENIGMA_DEBUG_LVL=4 " extra... and I suggest when running from console you want to see more.... (you're really working)... so you get one level extra when running from the console for free!!!!

[MiLo]

En then change the levels of the real critical logs to 3 or below...

Which isn't as easy as it sounds. Whether or not something is a "critical error" or just "to be expected" depends on the context, and usually isn't known at the point where the fault is triggered.

For example, take the PNG image loader. It will complain when the image cannot be opened. It would seem logical to elevate that message to at least "error" status.
But in context, the "spinner" code just loads images spinner1, spinner2, spinner3 etc. until it fails to load. The failure is a simple loop termination, which will always occur, and is clearly not an error.
Currently nobody noticed the error message, but if you were to change the levels and make E2 run rather silently, you'd always see a bit error message at startup.
(and please, don't go "fix" this by changing the spinner code into something that checks for file existence befaore loading it, I'm merely using this as an example for "context" determining whether a fault is an error or not)

[littlesat]

Which isn't as easy as it sounds. Whether or not something is a "critical error" or just "to be expected" depends on the context, and usually isn't known at the point where the fault is triggered.

--> I agree.... but most eDebugs are there for more than 10 years... I suggest they can simply stay there...

The only critical reports I saw really confirmed was from servicemp3.cpp.... Until know I did not see any evidence that there might be more... so why should we change there???

[mirakels]

 

En then change the levels of the real critical logs to 3 or below...

Which isn't as easy as it sounds. Whether or not something is a "critical error" or just "to be expected" depends on the context, and usually isn't known at the point where the fault is triggered.

For example, take the PNG image loader. It will complain when the image cannot be opened. It would seem logical to elevate that message to at least "error" status.
But in context, the "spinner" code just loads images spinner1, spinner2, spinner3 etc. until it fails to load. The failure is a simple loop termination, which will always occur, and is clearly not an error.
Currently nobody noticed the error message, but if you were to change the levels and make E2 run rather silently, you'd always see a bit error message at startup.
(and please, don't go "fix" this by changing the spinner code into something that checks for file existence befaore loading it, I'm merely using this as an example for "context" determining whether a fault is an error or not)

 

 

 

Ok, so we should switch all gui messages to that for example say 'service not found' because maybe the user/system  was just trying tuner settings until a black screen is shown.

 

Your example about this png file loading is  exactly why the eDebug message should be there: so one can fix the code in this case to check for file existence instead of just assuming it is there.

Now everybody talks about 'debug' because the function to show info is called 'eDebug' but there are enough messages that are useful but are not really debugging info.

 

PS: I'm not trying to say that the 'information' flow should not be changed...