Yes, I understand your possition. The only thing that you support is the official Dream Multimedia CAM in combination with the free porno card shipped with the Dreambox.

I found some time to test this as well. And this combination does not work either.

Like most users I do not use the Dreambox to view porno. Instead I use it with a KPN Digitenne subscribtion to watch decent channels. To do that one has to replace the Dream Multimedia CAM with a ..... CAM (or buy additional hardware). It has already been indicated before that all CAMs were equally effected by this bug. So, I think it was a fair assumption that if you would have solved the bug for your own CAM, it would have been solved for all CAMs.

Regards, Frits

Thanks for the drivers, we will test it.

I did perform some more tests in combination with different CAMs:
1) Official Dream Multimedia dccam from 26-3-2007 image does NOT work;
[Moderator] The only relevant fact is, that you still have Problems with dccamd and bad signal.
You might post the other stuff in another Board but not here. [/Moderator]
When I revert to the 17-5-2007 drivers all of the above do work.

Both the 17-5-2007 and the 26-8-2007 (the fix) drivers do not perform very well in combination with DVB-T radio stations. Some stations stop playing after a few seconds. This problem is less prevalent in the 17-5-2007 drivers then in the 26-8-2007 (the fix) drivers.

tmbinc. I am a freight there is some more work to do. I fully understand that it is difficult tackle this bug. Thanks for the effort done until now.

Regards, Frits

[Moderator] Why don't you just send them a PN.

And stop spamming the Board with stuff that is in violation of the Boardrules.[/Moderator]

Sorry, please *stop mixing up bugs*.

The problem were that a "bad signal" brings the dreambox into a state where it won't tune again, or freeze completely.

Does that still happen? That's the only thing i care about at the moment.

(I absolutely *don't* care if dccamd or any other cam does work or does not work, at least not the moment, in this thread. This thread is about another bug.)

Of course feel free to start a new thread about that, if you believe that a recent driver has a regression.
Feel also free to report here if the box still freezes or displays those "timeout while reading PAT"-errors without tuning in again before a reboot.

Reporting other bugs in this thread doesn't help a minute, it only makes it more communicating more complicated.

Zitat

Sorry, please *stop mixing up bugs*.

When I experienced the bug 2 months ago for the 1st time, I noticed that the bug appears only on encrypted channels. I discovered that I could get rid of the bug by commenting out dccam in /etc/init.d/bootup and using a hardware CI module instead.

I had very poor DVB-T signal with which I have been able to reproduce the bug within minutes (see the crash.mpg in previous posts) when I was using dccam. After I disabled dccam and installed a hardware CI module I had no problem at all for over 2 months.

So if dccam does not work, how should I be able to verify that the problem has gone?

Regards, Frits

Ok, that's a point. Can you please open a seperate thread, and describe exactly what's not working? Please use a 100% CVS image with updated drivers (no 3rd party images! They often do *very strange* stuff concerning cams, which can cause issues).

I'm more than willing to look at that problem (especially because we have found no problems using dccamd), but as said, please seperate it from this thread. After we fixed your dccamd problem, we can continue here.

Zitat

Originally posted by tmbinc
(dreambox-dvb-modules-dm7025-2.6.12.6-20070826.tar.bz2) treiber

bisher stable mit CC

tmbinc. I did sent my answer to your last post via PN.

Regards, Frits

Hallo,

Box läuft bisher mit den neuen Treibern sehr stabil. Keine Tune Failed Meldungen oder Totalausfälle. Werde in den nächsten Tagen nochmal berichten.

Danke und Gruß,
Oliver

So ... zu den kernel module von gestern dann einmal folgendes feedback fuer meine 7025cc. Zuvor waren komplette haenger der ganzen box zu verzeichnen. Dies trat bisher nicht mehr auf. Lediglich zweimal blieb das bild auf VOX stehen. Konnte dann durch einfaches umschalten auf einen anderen kanal und zurueck auf VOX wieder zum laufen gebracht werden. Lange nicht nicht wie es sein soll aber schon zu 2/3 besser. Wenn ich diesbezueglich irgendetwas troubleshooten soll oder logs im init4 dumpen kann dann lasst es mich wissen.

--rgds sourcexx

Der Fehler scheint echt gefixt zu sein, danke das ihr das gefixt habt.
(Bisher allerdings nur Sat getestet, mom keine Lust den Kabeltuner wieder einzubauen).
Allerdings gibt es da noch ein weiteres Problem, wenn ich im Pausemodus meine Aufnahme verlasse, steht das Tv Bild auch auf Pause. Das war früher nicht so und wikrt etwas störend.

den pause bug gab es früher schon mal und wurde m.e. zwischendurch auch schon mal gefixt.
Regloh

Auf das Hollandische SAT4ALL board gibt es nog viele Meldungen das es auch mit die neue Treiber nicht functioniert. Nur die Treiber von 17.5.2007 functionieren ohne Regenbug.

M.f.g., Frits

I have been testing further. With the new drivers I can get it to hang within a minute as well. On http://www.fwiarda.com/etc/dreambox/crash2.mpg a video of a crash that I did made today.

I am using the original Dream Multimedia image from 26-3-2007. I have enabled the official Dream Multimedia dccam (although I cannot use it for decoding the Dutch KPN Digitenne DVB-T). I placed my KPN Digitenne card in a CONAX CI module inserted in the Dreambox. This configuration is fully supported by Dream Multimedia!!!

I manually changed the frequency of one of the DVB-T bouquets from the Arnhem frequency to the Nijmegen frequency, so that I have very bad reception on this bouquet. The stations SBS 6 and RTL 7 are on the bad bouquet. The stations RTL 8 and TV Gelderland are on a good bouquet.

I restarted the Dreambox and I recorded the output on of the RF modulator on a DVD recorder (and converted it later to the mpeg file). As soon as the Dreambox had started up, I did start zapping between the above stations. In the beginning there is still signal on RTL 8 and TV Gelderland. Then I goto RTL 7, where I have enough signal for the EPG, but not to get picture. Then I go to SBS 6. You see on the EPG lines N/A. Now the Dreambox hangs. I zap back and I get everywhere no picture and no EPG.

The only drivers I came across that do not hang are the 17-5-2007 drivers. Another way the avoid the bug is to disable dccam in /etc/init.d/bootup.

I think this post clearly shows the bug has not yet gone. To get it hanging one needs very poor signal on an encrypted channel and a soft CAM running (e.g. dccam from Dream Multimedia). Remove any of these three conditions and it will not hang!

Regards, Frits

Servus,

habe eine ähnliche Konfig (dccamd ohne die Karte, ohne CI) wie fwiarda und genau das gleiche Problem. Vielleicht sollte noch erwähnt werden, das zum Hänger kein verschlüsselter Sender notwendig ist. Ich gucke über DVB-T z.B. ARD und drehe dann die (Zimmer-)Antenne weg, ist die Box sobald die BER vierstellig wird, auch weg. Ohne dccamd läuft die Box, sobald das Signal kommt, wieder weiter. Auf Satellit darf die BER noch etwas höher klettern, bis die Box aussteigt. Es ist immer noch genau das Verhalten, welches die Box schon immer gezeigt hat, also keine Verbesserung diesbezüglich.

Ok, thanks.

So it seems at the moment the only possible workaround is: a.) disable all cam software, and b.) use the most recent drivers.

We are of course working on a real fix.

lordgay666: Hängt die box bei dir denn, oder tuned nur nicht mehr? Wenn letzteres, kannst du mal bitte per "dmesg" (im telnet) schauen, was da kommt?

ich habe ja absolut nix mit Dream- Multimedia zu tun, aber ich bin auch Software- Entwickler...
Und wenn sich jetzt noch jemand wundert, warum das Fehler- beheben so lange dauert: Dieser Thread ist ein Paradebeispiel:

Ein Fehler wird gemeldet "Box hängt bei schlechtem Signal".
Die Developer fragen nach und bekommen hier ein Log und da ein log, teilweise sogar hilfreiche Informationen.

Aufgrund dieser Informationen gelingt es Ihnen den Bug zu beheben. Doch kaum scheint der Bug gefixt, kommt plötzlich eine komplett neue Information irgendwoher:
He, das ganze passiert aber nur bei der Verwendeung der CAM....

Als Entwickler kriegt man da SO nen Hals, und ich bewundere tmbinc und die anderen, dass sie so "ruhig" hier bleiben: Ich glaube mir wäre der Kragen geplatzt, wenn ich Monate nach einem Bug suche, und dann erst neue relevante Informationen zu dem Bug bekäme...

Deshalb meine Bitte (ich denke ich spreche im Namen jedes Entwicklers auf der ganzen Welt):
GEHT NICHT ist keine adäquate Fehlerbeschreibung.
Wenn man versucht den Fehler erst mal so genau wie möglich zu beschreiben (wann kommt er vor, unter welchen Begleitumständen, was ist aktiviert, installiert, etc), dann ist er schon halb gelöst.
Wenn man dann noch den Skill hat ein wenig mehr beizusteuern (dumps, logs, etc), dann erleichtert das den Entwicklern die Arbeit ungemein.

nur mal um meinen Senf dazu zu geben...

Tode

Sorry tode: das ist ja mal ganz grosser Quatsch. Wenn du aufmerksam beide Threads zu diesem thema gelesen hast dann wirst du feststellen das diese Info bereits lange gegeben wurde. Nicht nur von seinen Kunden auch von der Entwicklung kann erwartet werden das Problem anhand der gesammelten Infos zu bewerten (wobei ich denke das dies auch von tmbinc erfasst wurde) Ich arbeite ebenfalls in der Softwareentwicklung und weiss grundsaetzlich wovon du sprichst, aber hier wurde selbst telefonischer kontakt von einigen Nutzern angeboten und die community ist zu 50% auch geekmaessig veranlagt. Also eine recht gute troubleshooting basis.

Also muss ich leider sagen: deine 2cent sind leider was diesen fall angeht relativ unangebracht.

Fuer mich selbst ist das Problem nun weitaus geringer denn mit den neuen Kernelmodules ist zumindest kein kompletter freezeup der ganzen kiste mehr vorhanden. Also schon 50% geschafft. Wenn jetzt das demuxen sich noch selbst recovered wenn es mal kurz haengen sollte haben wir es doch schon fast geschafft.

Servus,

tmbinc
die box hängt nicht komplett, sondern der Bildschirm ist schwarz. Ob die Box tuned oder nicht, kann ich schlecht beurteilen, da SNR und AGC genau das anzeigen, was ich beim jeweiligen Transponder erwarte und die BER nach Neuausrichtung (oder Wechsel auf SAT) wieder bei 0 ist.
hier die Ausgabe von dmesg, nachdem der Bildschirm schwarz ist, bzw 30 Sekunden später, da mein PC ein Stück weit weg von der Box ist:

pcr extracted on pipe0, unit0!
SYNC: old: 1 -> new: 3 (requested: 3)
SYNC: old: 0 -> new: 3 (requested: 3)
PCR is soo far away that we cannot recover with clock pulling.
[AUDIO] enable sync
MPEG: Sequence header!
SYNC: old: 3 -> new: 2 (requested: 2)
select 0
select 1
select 0
select 1
select 0
select 1
select 0
select
select 0
select 1
select 0
select 1
select 0
select 1
select 0
select 1
select 0
i2c0: irq with inactive waitqueue
select 1
select 0
select 1
select 0
select 1
i2c0: irq with inactive waitqueue
pcr disable (0:0)
SYNC: old: 2 -> new: 1 (requested: 2)
SYNC: old: 3 -> new: 1 (requested: 3)
state is idle, denying.
AUDIO_CLEAR_BUFFER
clock pulling from pipe 0![pid_pcr_set] new filter for pcr (pid:06ff, pipe:0)
SYNC: old: 1 -> new: 0 (requested: 2)
SYNC: old: 1 -> new: 0 (requested: 3)
[pid_pcr_set] same as video
[xilleon_pcr_check_pid] we have to use now an different index
[pid_pcr_set] same as video
[xilleon_pcr_check_pid] nothing changed
audio_j1_streamtype_set(2)
SYNC: old: 0 -> new: 1 (requested: 3)
pcr extracted on pipe0, unit0!
SYNC: old: 1 -> new: 3 (requested: 3)
SYNC: old: 0 -> new: 3 (requested: 3)
MPEG: Sequence header!
[AUDIO] enable sync
SYNC: old: 3 -> new: 2 (requested: 2)
pcr disable (0:0)
SYNC: old: 2 -> new: 1 (requested: 2)
SYNC: old: 3 -> new: 1 (requested: 3)
state is idle, denying.
AUDIO_CLEAR_BUFFER
tda1004x: setting up plls for 53MHz sampling clock
tda1004x: found firmware revision 25 -- ok
clock pulling from pipe 0![pid_pcr_set] new filter for pcr (pid:1111, pipe:0)
SYNC: old: 1 -> new: 0 (requested: 2)
SYNC: old: 1 -> new: 0 (requested: 3)
[pid_pcr_set] same as video
[xilleon_pcr_check_pid] we have to use now an different index
[pid_pcr_set] same as video
[xilleon_pcr_check_pid] nothing changed
audio_j1_streamtype_set(2)
SYNC: old: 0 -> new: 1 (requested: 3)
MPEG: Sequence header!
pcr extracted on pipe0,
SYNC: old: 1 -> new: 3 (requested: 3)
SYNC: old: 0 -> new: 3 (requested: 3)
PCR is soo far away that we cannot recover with clock pulling.
[AUDIO] enable sync
SYNC: old: 3 -> new: 2 (requested: 2)
pcr disable (0:0)
SYNC: old: 2 -> new: 1 (requested: 2)
SYNC: old: 3 -> new: 1 (requested: 3)
state is idle, denying.
AUDIO_CLEAR_BUFFER
clock pulling from pipe 0![pid_pcr_set] new filter for pcr (pid:0221, pipe:0)
SYNC: old: 1 -> new: 0 (requested: 2)
SYNC: old: 1 -> new: 0 (requested: 3)
[pid_pcr_set] same as video
[xilleon_pcr_check_pid] we have to use now an different index
[pid_pcr_set] same as video
[xilleon_pcr_check_pid] nothing changed
audio_j1_streamtype_set(2)
SYNC: old: 0 -> new: 1 (requested: 3)
pcr extracted on pipe0, unit0!
SYNC: old: 1 -> new: 3 (requested: 3)
SYNC: old: 0 -> new: 3 (requested: 3)
PCR is soo far away that we cannot recover with clock pulling.
[AUDIO] enable sync
MPEG: Sequence header!
SYNC: old: 3 -> new: 2 (requested: 2)
missed sync in queue 30, resetting...
missed sync in queue 30, resetting.
missed sync in queue 30, resetting...
missed sync in queue 30, resetting...
missed sync in queue 27, resetting...
missed sync in queue 27, resetting...
missed sync in queue 27, resetting...
missed sync in queue 27, resetting...
missed sync in queue 27, resetting...
missed sync in queue 27, resetting...
seq error
seq error
seq error
printk: 741 messages suppressed.
missed sync in queue 30, resetting...
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error
seq error

Das ist Teil eins, weil das Forum nicht mehr als 10000 Zeichen zuläßt.
Edit: Teil 2 folgt in 10 Minuten, da ich innerhalb dieser Zeit nicht zweimal Posten kann.

p.s. wenn Ihr in Lünen sitzt, habt Ihr doch auch DVB-T. Über DVB-T kann ich den Fehler mit meiner Zimmerantenne in maximal 10 Sekunden reproduzieren.