97 replies to this topic

[WanWizard]

If the big Kings off pli (at last that’s what they think of themselves) remain blind to the facts it will never lead to anything and the error will be there even in the year 3000.

 

You seem to have a bit of an attitude problem.

 

There are a few things (fundamentally) wrong here.

 

One, there is a difference between logging and debugging. You need a bit of logging when you run every app, but you don't need debugging. You need debugging when you want to debug. End-users should not debug, and should not run an application permanently in debug mode. It is bound to lead to issues like this. When an end-user runs into an unexplained error, a developer can ask this user to restart the application in debug mode, retrace his/her steps, and send the resulting log to the developer.

 

This requires significant changes, which you don't just "hack" in. You think about it, you design it, you discuss it, you tweak it, and then you build it.

 

And secondly, the current eDebug (and friends) methods are clearly not designed to output logging in end-user mode, and certainly not at the insane amounts gstreamer puts out.

 

So you're fixing the problem at the wrong end. Enigma is already a big heap of spaghetti code, and that is mainly because most people (that have been) working on it, including those at dream, have the same attitude as you, plugging one hole with the next.

 

And this is something we try to avoid, and that is what Mirakels is referring to. There is no need to feel attacked, there is no need to feel superior to someone else. PLi has been the name for over 10 years when you needed a stable and throught-through image. In the last couple of years that image has eroded, mainly because to many changes are merged into "production" code without a proper thought and plan process. A situation we are keen to revert.

[christophecvr]

Well I'm thankful.

This was the last thing that was really annoying me.

Lot's of movies I'm using have external .srt subtitles files.

I would occasionally get the spinner when e2 was trying to process/buffer/whatever with them.

That's now solved as well.

So I'm keeping the patch for my next (and probably last) round of images.

Well You are right,

 

But that's my problem now, Guys who should be real good programmers (at last it's what they say about themselves) do not see the problems ..... And so do not apply a extreme important patch. Which at this time is only to solve the major severe issues which are really present.

 

All the rest is not urgent and yes it should be reviewed and adapted for that it will take time. But the current real major BUG is solved by a very stupid idiot commenting of a couple eDebug rules that is that.

[mx3L]

Note, in the beginning of the streaming there is sudden rush of buffers because decoder's(hw) buffers are empty, which produces too many and not only buffering messages, so it's extreme situation.

 

I think the solution is to use eDebug only for some of these messages as was already suggested.

[theparasol]

Athoik,

 

if I remember correctly this GST_MESSAGE_BUFFERING was one of the first contributions from some years ago to openpli

I'm sure you remembered it right away!

 

After it was committed my shoutcast streams started very slowly compared to before. I even mentioned it on the forum but no one seems to have the same experience as me.

At that moment I thought it was just my slow XP1000 box that suffered.

 

No hard feelings but 5 minutes ago I compared openATV servicemp3.cpp against openpli one (both from previous week while looking for clues for the damn CI+ handler)

anyway guess what...

 

openatv has:

// eDebug("Buffering %u percent done", m_bufferInfo.bufferPercent);

openpli has:

eDebug("[eServiceMP3] Buffering %u percent done", m_bufferInfo.bufferPercent);

Did they actually discovered this point way before we did or was it some kind of lucky code policy like: "disable debug lines if not needed in final code" ??

 

Anyway, I hope sometime soon I can enjoy my radio streams a lot faster again if someone just commits for now those "//"

 

TNX!

Edited by theparasol, 13 January 2016 - 23:50.

[mirakels]

 

But that's my problem now, Guys who should be real good programmers (at last it's what they say about themselves) do not see the problems ..... And so do not apply a extreme important patch. Which at this time is only to solve the major severe issues which are really present.

 

All the rest is not urgent and yes it should be reviewed and adapted for that it will take time. But the current real major BUG is solved by a very stupid idiot commenting of a couple eDebug rules that is that.

 

I'm sure Google has brilliant programmes devoting their time on a very well paid job developping Android. Why then do I still have issues with my phone.  Do they not see the problems? Are they idiots? Didn't YOU tell them that they should push YOUR patch ASAP. And if they don't do it they are not worth living?

 

You are really making friends here.

I just applied your suggested patch as a oneliner. But by doing that I'm now an idiot in your eyes! I think I'll revert it again.

 

Maybe it is time you build engima3 in which everything we ever wanted is working nice and beautifully and with swift performance.

I expect the first stable version (which of course will be the only one as there is nothing to wish for after that) coming Saturday night 21:00 CET sharp so everybody can live happily ever after!

 

Sigh!

[athoik]

Is it ok to send all those events to Enigma? ( m_event((iPlayableService*)this, evBuffering) )


There are no other locking in m_event up to UI?

[theparasol]

@Mirakels: Thanks for pushing this simple change, you made me very happy!

 

@All:

 

Don't be mad at Chris, I know him for quite some time working on oscam, he is very devoted as you all can see but when he discovers something he simply reacts this way.

Not always but in special cases if something has troubled him a long time and I can understand such behavior.

Lets be glad we found a big piece of the puzzle. Now lets wait for some time and inspiration to fix it properly.

I think WanWizard has point, somehow/sometime we have to switch to debug levels, oscam has that too. Perhaps we can even copy / paste some of its code, upgrade it to C++ and

integrate it very easily.

 

http://www.streamboa...unk/oscam-log.c

[athoik]

Athoik,

if I remember correctly this GST_MESSAGE_BUFFERING was one of the first contributions from some years ago to openpli
I'm sure you remembered it right away!

After it was committed my shoutcast streams started very slowly compared to before. I even mentioned it on the forum but no one seems to have the same experience as me.
At that moment I thought it was just my slow XP1000 box that suffered.

No hard feelings but 5 minutes ago I compared openATV servicemp3.cpp against openpli one (both from previous week while looking for clues for the damn CI+ handler)
anyway guess what...

openatv has:

// eDebug("Buffering %u percent done", m_bufferInfo.bufferPercent);

openpli has:

eDebug("[eServiceMP3] Buffering %u percent done", m_bufferInfo.bufferPercent);

Did they actually discovered this point way before we did or was it some kind of lucky code policy like: "disable debug lines if not needed in final code" ??

Anyway, I hope sometime soon I can enjoy my radio streams a lot faster again if someone just commits for now those "//"

TNX!

I still have the message, it was about updateEpgCacheNowNext

[christophecvr]

 

If the big Kings off pli (at last that’s what they think of themselves) remain blind to the facts it will never lead to anything and the error will be there even in the year 3000.

 

You seem to have a bit of an attitude problem.

 

There are a few things (fundamentally) wrong here.

 

One, there is a difference between logging and debugging. You need a bit of logging when you run every app, but you don't need debugging. You need debugging when you want to debug. End-users should not debug, and should not run an application permanently in debug mode. It is bound to lead to issues like this. When an end-user runs into an unexplained error, a developer can ask this user to restart the application in debug mode, retrace his/her steps, and send the resulting log to the developer.

 

This requires significant changes, which you don't just "hack" in. You think about it, you design it, you discuss it, you tweak it, and then you build it.

 

And secondly, the current eDebug (and friends) methods are clearly not designed to output logging in end-user mode, and certainly not at the insane amounts gstreamer puts out.

 

So you're fixing the problem at the wrong end. Enigma is already a big heap of spaghetti code, and that is mainly because most people (that have been) working on it, including those at dream, have the same attitude as you, plugging one hole with the next.

 

And this is something we try to avoid, and that is what Mirakels is referring to. There is no need to feel attacked, there is no need to feel superior to someone else. PLi has been the name for over 10 years when you needed a stable and throught-through image. In the last couple of years that image has eroded, mainly because to many changes are merged into "production" code without a proper thought and plan process. A situation we are keen to revert.

 

 Amazing but Did you really read about what we are speaking here ???

This is going up to crazy levels the whole explanation you made above does not make a sence at all.

 

Do I really have to start fights in a endless way when showing proved and very severe (and now actually it's a critical bug's) ???

 

Just read "WHAT" is written .

 

I child off 6 now .. ok you must be able to read so let say 8 years can do that.

 

1)  The current "USE" of eDebug is placed in many wrong places one off the extrems wrong placings is rule 2089 into servicemp3.cpp

2)  Actually the use off eDebug by the subtittles to be find into rules to find between rule 2522 and 2552

3) my own forgotten removal off eDebug lines handling off toc events lines 2203 - 2256 .

 

They all do cause problems just the eDebug lines nothing else.

 

If You can't see eighter understand that ???? Try to blame other persons for that , off You go but You're monologue is completely misplaced.

 

The one is critical and a blocker ???

the 2 is a issue for which a lot of persons tried to find a solution , whell ....... the problem is the eDebug and that it.

The 3 basiccally not such a big problem , but yes may cause uneeded delay during start off media (and may be responsible for the sometimes sync issues at start also only the eDebug lines). Actually when I developped those one I self inserted a comment that the debug message should be removed later on, unfortunately I didn't and yes that's a error of me, and so what only if you do nothing you can't make error . With the patch a corrected this one.

 

What do you wan't more to correct a primary real severe BUG ???? in e2 ???

[mirakels]

@Mirakels: Thanks for pushing this simple change, you made me very happy!

 

@All:

 

Don't be mad at Chris, I know him for quite some time working on oscam, he is very devoted as you all can see but when he discovers something he simply reacts this way.

Not always but in special cases if something has troubled him a long time and I can understand such behavior.

Lets be glad we found a big piece of the puzzle. Now lets wait for some time and inspiration to fix it properly.

I think WanWizard has point, somehow/sometime we have to switch to debug levels, oscam has that too. Perhaps we can even copy / paste some of its code, upgrade it to C++ and

integrate it very easily.

 

http://www.streamboa...unk/oscam-log.c

I added debug levels to libdreamdvd too a long time ago.

In principle there are already levels (debug, warning and fatal), but enigma2 does not do anything special with the level.

I'm working on changing the core eDebug code to make it easier to add levels and allow setting debug levels at runtime.

 

About chirs, yes I see he is devoted and passionate, but that does not give right to push people and be blunt.

But as he can do it will now to:

[BLUNT MODE ON] Chriss, most of the time I do not understand what you write. I can deal with stone-cole-english most of the time and do it onpurpose myself once in a while. But your version is a bit to far off. Maybe you should type your comments in your native language and use google translate to get an english version.

[BLUNT MODE OFF]

Sorry.

[WanWizard]

@Chris,

 

I don't think I was talking about that.

 

I was talking about your attitude, and the tone you use again in this post. it is simply not done. If I were sitting right opposite of you, you wouldn't have the nerve to address me like that, and I wouldn't hesitate to put you back in your place. So don't behave the same way here.

 

And I was disussing a fundamental problem with the way eDebug and friends are used. And the way you (appearently want to) abuse it, with a suggestion on how to premanently address this issue.

[athoik]

I'm working on changing the core eDebug code to make it easier to add levels and allow setting debug levels at runtime.

You might find usefull the patches i've send for review for that. Probably they don't apply anymore but that was the idea.

[mirakels]

 

I'm working on changing the core eDebug code to make it easier to add levels and allow setting debug levels at runtime.

You might find usefull the patches i've send for review for that. Probably they don't apply anymore but that was the idea.

 

Can you give a pointer to those patches/discussion?

[theparasol]

[offtopic on]

I wish I could contribute more to openpli in code but the compile time to test my stupid buggy code ideas and git issues I have to overcome simply is stalling rapid progress and even annoys me. My machine takes a whole weekend to compile a xp1000 image from scratch.

Just recompiling enigma due to 1 line change takes about 20 minutes.

Many times I got into trouble with git, had to erase the whole project and zip... another weekend long waiting.

I think one point is due to fact I use a virtual machine to compile.

Perhaps I should setup my good old pentium4 3 Ghz doing nothing catching dust for a testrun with native linux to see if it can compile faster.

[offtopic off]

[athoik]

I'm working on changing the core eDebug code to make it easier to add levels and allow setting debug levels at runtime.

You might find usefull the patches i've send for review for that. Probably they don't apply anymore but that was the idea.

Can you give a pointer to those patches/discussion?

Sure here it was the pre-mature idea:

https://github.com/a...a5aa6a1d7360550
https://github.com/a...11f61c830dcc421

[christophecvr]

@Chris,

 

I don't think I was talking about that.

 

I was talking about your attitude, and the tone you use again in this post. it is simply not done. If I were sitting right opposite of you, you wouldn't have the nerve to address me like that, and I wouldn't hesitate to put you back in your place. So don't behave the same way here.

 

And I was disussing a fundamental problem with the way eDebug and friends are used. And the way you (appearently want to) abuse it, with a suggestion on how to premanently address this issue.

 Sorry if being honest and straight forward is a wrong attitude , ... wel to bad.

But I really say everything again if I would sit straight before You in real live just cause I'm honest and I mean it unfortunately I'm a (very very)bad writer and that's the cause that what I did write is not really understand by the readers.

[christophecvr]

Very nice all now. But ....

 

I launched this topic to pinpoint a major problem into e2 about debugging I must admit that I self already noticed some issues which came only cause you added a eDebug (blablab) line and that they where gone when you removed it. But like I guess many of the guys who work really constructive on some issues I assumed it would only be there cause I worked with console started e2 (from pc  telnet) But that eDebug would have no influence on regular user. Well that was wrong every eDebug must be taken into account even if you do not run with console or log file active.

 

First I really must thank Akki since he continued pushing about sand keeper problems with some media. I had the same box even tried the same image or eighter the same build I well always builded self so I not had the same problems like Akki. What I well have seen in some occasions was the same issue as Akki told. When I wanted to reproduce it , .... it worked all fine by me same box same gst version same pli versions. There is well a Bud .. I since long (and actually was not the only one who did that) commented the line 2089 into e2 with a personal patch. Just cause leaving it actif spoiled all logging about streamed media. Result , my base e2 did not had this sever bug I never could confirm Akki's problem. I even went that far to deliberately change something in mediasink and ...

I never could trigger the problems he had till that level. Untill .... Yes I migrated to master-next  and did not yet had my personal standard patch which commented that line inserted yet. My box showed the problems just like Akki explained. My dm8000 did had actually the same problem it was well  much less pronounced.

 

Now after reporting the first issue almost a week ago reaction NADA message ignored completely.  Some hints left and right .... result NADA.

 

Ok so I ame . After all the first was not just a standard bug but a real critical one.

 

Just to all read the complete next to the point messages from yess, the collection off the guys.

 

mirakels,WanWizard,Athoik and Betacentauri.

 

Not one of them took the problem serious and issued a real positive attitude to it.

Well for me I do not give a shit (well I can build for me alone and fix it just for me. For the rest forget all). If that was the goal I never would had put any topic ever here.

 

I do fight for every users even if I have to battle with the guys who think they are Kings and act like it.

 

Now after this battle yes I see .... the comit done by ...  mirakels ohhh what nice ????

 

Only and only the line by the debug msg commit :

https://github.com/O...443f8ebe07297b4

 

Ok this was the most critical only applicable to all streamed media. Thank's mirakel , but that i needed to make such a fuss before a real critical issue is committed sorry

 

However into servicemp3 2 really severe issues remain.

 

1) idiot I even wrote self that they are there temporarely but must be removed in a later stage I never request it soryy my error I well posted a patch for that now but not applied .....

 

2) Yes as long the debug about srt subtitles is NOT removed do not complain about out off sync to late coming up or out of sync showing off subtitles, The main cause is yes .. the eDebug lines.

 

That I guess mirakels has forgotten in the patch ??????

 

If ever a little sense comes up in future there is hope. If not .....

 

Saying the true straight to maybe hard sometimes . But if that’s  called wrong attitude sorry  ??????? perhaps lying cheating is ok. Diplomacy that's lying , sorry not my thing.

 

What was was.

What is is.

What will be that we can change.

[betacentauri]

Yes, you found the problem. Your the best.

We both totally think different in what is a major problem. A major problem is for me that software crashes regularly and major parts of the software are totally unusable. Here we had spinners showing when a stream started. I never had much problems with it. So for me it's a minor problem. No need to apply the patch within hours.
By the way I can't commit here.

[littlesat]

Maybe mirakels is adding functionality for debug levels... So possibly he commented only the most important eDebug line and possibly later it will be done with debug levels....

[mirakels]

I did only the 'super most serious and world collapsing' part of the patch.

Why? Read back on  the last sentence in post  #41. Especially for fixing issues (this eDebug line is NOT a bug) it should be explained what this issue is and how it solved in the commit log.  The other changes in chris patch were not related to this 'buffer percentage' log overflow issue so should not be in the same patch. I extracted this one-liner one. Will not do the others as they are not that much of a problem anymore.Chris can create new patches for it and if they are clean end well documented (and offered as a pull request) I see no reason why the wouldn't be pulled .