Zitat von cmatte

FATAL: epgcache.cpp:136 ASSERTION pos <= 4108 FAILED!

Dear DMM, this problem is still there here (dm8000)...November through February and counting...(post comes from here
Release Image 3.2 soeben veröffentlicht - CrossEPG, Senderliste Prozentanzeige & andere Funktionen aus dem Gemini/iCVS Alternativimage? ).

DMM, we NEED a fix, I find plenty of people in plenty of different forums lamenting the same exact problem. At random times boxes are unusable for the whole day. EPG is NOT an optional function of the box. Even more if it locks the entire box, included webif, streaming, remote controls, breaks launched recording timers, etc... Also I want to report that all the developers out there, those who worked and work hard to bring us third party images, agree on the fact that this is a problem of the ENIGMA software. A problem that is there since Enigma1 and that is well-known, reported, and never solved, almost not by you, DMM. They also say that when e2 was open enough they could patch it their-selves but as actually it is not, YOU NEED TO APPLY THE SAME (KNOWN? PUBLIC? DISCOVER-ABLE?) FIX these developers applied in the last years for you and for your clients' sake. Believe me, this situation that is months and months old and blooding isn't acceptable anymore. Users are a lot angry. You are loosing correctness, belief, seriousness, competence and the kindness of your clients. Your boxes worked good as far as you also let someone else work on those. Now that you forced them to use your binary of e2 they can't anymore work for you in these case where you lack. YOU really need to fix it. Now. I'd like to see these fixes soon in the public e2 repositories of the unstable branch. Can you promise you will try to dig into this issue, really?

Zitat von kenatonline

(A hint: be polite and not that aggressive, if you want someone to think about your points;
and no, it is not true that a bunch of money you paid excuses questionable manners )

kenatonline, that's surely true. What makes me mad and so angry to DMM is a lot of things including rumors and things read somewhere else that I can't be sure are true but they likely are because I found many say the same like:

• it's a bug there since e1
• never fixed by dmm
• fixed by 3rd devs when e2 was open
• it isn't fixed by dmm with the same known ways when they decided to make it close-sourced or just after
• they denied it's a problem because I had reported this before and they rudely, shortly and fastly said it's just a problem of the 3rd part image. More rudely then me now for sure. That's really bad because if you know how a 3rd part image as mine works, you know it's 99,9% original with more "apps" / skins and similar. Every day the system is even updated with new packets from dmm. It's like Micros**t denies to help because you installed any 3rd part software on Windows
• since e2 3.2 coming out, November 2011, my box doesn't work for the whole day when it likes
• it's a box which costed 1k € to be unusable randomly with DMM denying the problem and the support since months for sure or even years if the devs at poing 1,2,3,4 aren't in chorus saying lies
• I'm not English and I can be rude without wanting to, sorry for that

Is that enough ?
Anyway, let's try to leave aggressiveness and rudeness apart and try to troubleshoot the problem.
I wait some official answer by dmm and I'm available to help if needed.

Zitat von SiennaRoot

cmatte,
can you isolate the EPG problem on which satellites / Channels this "FATAL: epgcache.cpp:136 ASSERTION pos <= 4108 FAILED!" comes up ?

Nope, because it's a general problem non channel-provider-source related. It appears if you open epg guide's data with dmm or 3rd party guide or by opening webif. Sometimes even when you use channel list that has to read epg data. It's something like epg data downloaded from the net or coming from OpenSAT or both together in some particular cases makes the box unable to read epg cache correctly and so it fills up memory and comes out with a green screen with that error. And it does this every time you'll use the same source of data. That's what I came to understand, but I am not a coder, not in these languages to be precise, and actually it would be of no utility due to the closeness of e2, so I -really- can't understand what's going on exactly...

Zitat von kenatonline

cmatte
You hit the nail on the head. It IS a problem of third party software.
Don't understand me wrong, I don't want to deny that the EPG handling of DMM is more than
poor. They made a design decision which was not taking into account, that someone wants
to use non-broadcasted informations seamlessly integrated.
Unfortunately they MADE this decision and there NEVER was a working fix (the crossepg
patch was not working flawlessly; it just made the problem appear more infrequently) by
3rd parties. I tested them all (at least I hope I found all of them) and none of them worked
flawless.

You want to blame DMM for poor EPG support? I will stand should to shoulder.
You want to blame DMM for something a 3rd party software causes, which was never part of
the design and want to call it a bug? I do have a problem with this.
To catch your Micros*ft example: You want to blame MS for not fixing a Windows crash which
is caused by a 3rd party software manipulating a system library, but instead telling you to not
use the software to extend Windows.

For "unknown" reasons, DMM decided to NOT offer an API to add EPG informations.
Blame them for this. And do it harsh, because it IS a shame.
Ask for a clean solution which has the API for external additions of EPG entries included by
design not by "hacking".
I will be the first to support you with this.

Alles anzeigen

You are exactly right! That's a good point and it seems the correct point of view too. I didn't dig into the issue in the code because I'm unable to, but I worked as a coder so I understand what you mean exactly and you can't but be right. Problem is DMM should support epg better, full stop. How? With an API that allows to inject correctly formatted epg in the system without workarounds used actually by 3rd parties. Or/and...
I want to add something on a point... They made a design decision which was not taking into account, that someone wants to use non-broadcasted informations seamlessly integrated.
... that seems not completely precise to me. Ok, they have made such a decision probably, but they are also NOT supporting all the broadcasted information! My provider does broadcast information in an OpenTV standard. Strangely there are 3rd party works that can manage it without having to worry on licenses afaik. The name itself sounds like it's an "open" standard? I don't really know if this is true or not, please elaborate on this if you can. But even if this is not true, well, I think there are also legal ways to do that. I could perfectly live without using 3rd party apps that do try to use non-broadcasted epg data and mix them with broadcasted data if only the broadcasted data was read by the system itself, not with the now/next event only, completely, because data is just there on some transponders. Also, this is not a standard used by my provider only, there are some that use that one. I would like to know if DMM is trying / had tried to understand and implement OpenTV and if there have been / are impediments by OpenTV. That could be the case, if you think about it deeply. But, as kenatonline said, you could just create a working API and woila, the rest of the work can be done externally and not by you, if you're unable to because of interests of OpenTV.