Sagem Zwitscher-Box

[niemand0815]

sorry das ich zzt nicht testen kann. hab deinen deaemon auf der box aber nicht aktiviert, da ich bisher noch keinen einzigen (!) zwitscherer mehr mit der b11 hatte.

[gerry6n]

@newcode

 

Ich werde mal weiter testen, da ich leider keine Beta 11 bekomme :-(

 

Also der 0.91 is schon gut gelaufen meistens hat man den Reset nicht wirklich wahrgenommen, weil nur ein ganz kurzer Ton-Aussetzer da war. Bei hartneckigen fällen fing sie doch an zu zwitschern was aber auch relativ zügig behoben wurde. Alles in allem ist der Deamon schneller wie das Script.

 

Den 0.92 hab ich eben mal ein bissi am testen und hatte auch schon ein schwarzes Bild (Ton lief weiter) nach einem Reset. Diesen Fehler hatte ich mit dem 0.91 nicht....kann aber auch zufall sein.

 

MfG Gerrit

[bahnbooster]

wie sind denn jetzt die Einstellungen richtig für den avia-check ??

 

SPTS EIN / AUS ?

AVIA Watchdog EIN / AUS ?

enX Watchdog EIN / AUS ?

bearbeitet 9. Oktober 2007 von bahnbooster

[newcode]

@gerry6n

Das habe ich auch schon gehabt. Dann ist der avia600 abgeschmiert. Im seriellen Log müßte dann was stehen wie "video decoding stopped -- restart".

Ich weiß zwar wie ich es abstellen kann, aber noch nicht ob es in den kernel-messages einen Hinweis gibt. Muß warten bis es wieder passiert.

 

@bahnbooster

Bei mir ist alles AN:

 

Grüße

[newcode]

@Gio815

 

Es gibt eigentlich gar kein zwitschern :-)

Im Ernst, Du liegst da wohl im Prinzip richtig.

 

Ich habe mal folgendes gemacht:

Box laufen lassen mit camd3 bis sie zwitschert

PW Abo Karte reingesteckt

Sobald die Karte erkant wird (im Log) hört das zwitschern auf

Karte wieder raus, das Zwitschern fängt sofort wieder an

Das kann man beliebig oft machen.

 

Da heißt: Die Hardware incl. Firmware der Chips läuft im Zustand des Zwitscherns einwandfrei, nur die Kommunikation Camd3<->Hardware/Firmware funktioniert nicht mehr richtig bzw. asynchron.

Daß das bei allen camd's so ist, liegt vielleicht am abschreiben. Das zusätzliche laufen lassen eines Programms wird daran IMO nichts ändern.

 

Grüße

[Gio815]

Vielleicht bekommt es ja mal jemand in den Griff, würde hier sicherlich viele User glücklich machen!

[bahnbooster]

Ich denke mal, dass die ABO Karte Signale (ausser den Codes) an die Box sendet, die zur Synchronisation des decodierten Abschnitts (ca. 7 sec ?) mit Bild und Ton dienen, aber eben hardware und zeitnah.

bearbeitet 9. Oktober 2007 von bahnbooster

[Tunina]

@Gio815

 

Es gibt eigentlich gar kein zwitschern :-)

Im Ernst, Du liegst da wohl im Prinzip richtig.

 

Ich habe mal folgendes gemacht:

Box laufen lassen mit camd3 bis sie zwitschert

PW Abo Karte reingesteckt

Sobald die Karte erkant wird (im Log) hört das zwitschern auf

Karte wieder raus, das Zwitschern fängt sofort wieder an

Das kann man beliebig oft machen.

 

Da heißt: Die Hardware incl. Firmware der Chips läuft im Zustand des Zwitscherns einwandfrei, nur die Kommunikation Camd3Hardware/Firmware funktioniert nicht mehr richtig bzw. asynchron.

Daß das bei allen camd's so ist, liegt vielleicht am abschreiben. Das zusätzliche laufen lassen eines Programms wird daran IMO nichts ändern.

 

Grüße

So isses aufgrund eigener Erfahrungen mit ca. 15 Sagem-Satboxen und ca. 5/7 Sagem-Kabelboxen - prizipiell versteht sich.

 

Zwei Drittel der Sagem - Boxbesitzer(Gutmenschen) glotzen prima TV und nie über Kanäle - die nur über Emu hell werden.

 

Ein Drittel sind unerfahrene Brummi - Lauglotzer. In den Griff bekommen habe ich deren Sagemboxen nie wirklich und ich habe die hier (nicht nur in diesem Thread/Board)geposteten Lösungsansätze rein aus Interesse alle durch. Eine dieser Sagem Sat-Zicken besitze ich selbst.

 

Selbst wenn die Fummelei denn mal erfolgreich war, war es nach einem Emu/Keyupdate oft - same as before.

 

Mittlerweile jibbed(dank Ebay) bei den Lauglotz - Amigos keine Sagemzicken mehr. Da werkeln nun Nokias und die Amigos sind happy. Nur ich selbst habe noch eine Sat-Sagemzicke(neben einigen gutmütigen Nokias und einer gutmütigen Philips ) und warte jetzt auf den goldenen Lösungsschuss für die Zicke.

 

Die Hoffnung stirbt nie.

bearbeitet 7. Oktober 2007 von Tunina

[niemand0815]

@newcode:

ich denke aber wenn man es schafft die box so stark zu entlasten das das timing kein problem wird dann schafft man es vielleicht 80-90% den hänger zu beseitigen.

 

vergleich:

vorherige betas lagen bei 40-50% cpu last => zwitschern

durch die runterpriorisierung der sectionsd hat meine jetzt:

0-1% cpu last => keinerlei zwitschern mehr

 

ich denke nicht das dies alle zwitscherfälle betrifft, da ich persönlich glaube das es mehrere ursachen gibt. aber der "timingfall" könnte damit erledigt sein.

 

und natürlich hab ich hw-sections abgeschaltet, damit der enx nicht noch mehr zu tun bekommt und mit der box und sectionsd reden muss.

bearbeitet 7. Oktober 2007 von niemand0815

[Fazz]

FYI:

 

hab auch noch was interessantes gefunden,...

 

geschrieben von nokia (tmbinc):

 

...

ucode.bin:

 

der originalucode ist beim eNX und GTX der gleiche. er kann nicht descramblen (oder wenn dann anders als die anderen), es gibt keine doku darüber (ausser bei BR), generall handelt er sections komplett anders und dafür fehlt sämtliche doku.

für die anderen ucodes, die aus nem radix-fta-(GTX-)reciever sind (z.b.), haben wir doku und deshalb gibts dafür auch hw sections.

 

warum das nicht ordentlich auf dem eNX läuft ist bis heute unklar. alle reset- und sonstwas aktivitäten sind wenn überhautp work arounds. es gibt nen recht stabilen fix (mit denen boxen tagelang ohne ruckler o.ä. durchlaufen), WARUM der allerdings funktioniert weiss ich auch nicht. WARUM den noch niemand anders gefunden hat ausser einer (ich war's nicht weiss ich auch nicht. Ich hab jedenfalls tagelang rumgemacht und bus-timing kontrolliert, und nichts gefunden. evtl. kann man mit nem logic analyzer mal was ausrichten. oder es liegt doch am ucode, aber das glaub ich nicht.

 

nebenbei könnte man den mal reversen: im enx-treiber ist oder war mal nen anfang von nem debugger drin. man kann nämlich wunderbar durchsteppen durch den code. dummerweise ist völlig unklar was für ne RISC-engine da drin ist. irgendwas von samsung, so wurde berichtet.

 

jump befehle findet man ja recht leicht, aber dann sit auch schluss.

 

tip: die register in der umgebung vom PC sind irgendwelche anderen risc register.

...

[niemand0815]

welcher fix funktioniert? in obigem zitat wird von einem funktionierenden fix geredet. interessant wäre herauszufinden welcher das ist.

 

btw:

bisher immer noch keine zwitscherei bei meiner sagem.

ich bin also ein schlechter kandidat zum testen des daemons.

[tto]

hört sich ja gut an, muss ich bei meiner Sagem wohl auch nochmal probieren (hab gerade eine zwitscherbox von einem Kumpel bekommen)

bearbeitet 8. Oktober 2007 von tto

[sNuuu]

@niemand0815 stell doch mal bitte deine Einstellungen um wie früher um zu sehen ob das Nicht gezwitschere wirklich an dem Einstellungen liegt bevor hier jeder was anderes macht.

[niemand0815]

die einstellungen sind jetzt sogar auf den defaults(! ausser enx und avia watchdog sowie gtproc, welche natürlich angeschaltet wurden) des images.

ich habe nie behauptet das liegt an den einstellungen, sondern muss irgendetwas neues im cvs oder im beta10/11/12 image sein.

 

das einzige was ich sage ist das ich als tester für den daemon deswegen mangels masse ausfalle.

btw:

egal was ich einstelle kann ich keine zwitscherausfälle mehr provozieren.

ich müsste also das beta image runterwerfen, was ich nicht tun werde :-)

[faze]

Welches beta image meinst ihr denn??

 

Im DL Bereich ist das neueste Image vom 7 April zumindest sehe ich da kein neueres!

[niemand0815]

Keywelt 2007 Squashfs September Image V1 Beta12

wird nicht mehr public getestet.

 

bei der beta8 gab es bei mir noch zwitscherer, bei der 10 nur noch wenige, seit der 11 gar keine mehr (bei MEINER box. keine zu verallgemeinernde aussage)

aber wie schonmal gesagt, ich vermute mehrere ursachen, vielleicht wurde eine dieser ursachen im cvs gefixt (oder zufällig umschifft).

 

also im schlimmsten fall einfach mal abwarten und dann die final testen wenn sie public ist. so lange aber den daemon ausprobieren, damit wir eine funktionierende symptombeseitigung haben wenn es vielleicht mal wieder nicht funktioniert.

bearbeitet 8. Oktober 2007 von niemand0815

[bahnbooster]

Gelöscht

bearbeitet 9. Oktober 2007 von bahnbooster

[niemand0815]

das wäre klasse. denn in der 12 würde die sectionsd prio angepasst.

[Xander]

ich glaube auch immer mehr an die sectionsd prio variante:

 

Zitate Wiki

Der Sections-Daemon ist unter Neutrino für das Sammeln, Aufbereiten und zur Verfügung stellen der EPG-Daten zuständig.

 

Er gilt als eine der Schwachstellen von Neutrino, da diverse Instabilitäten und Fehlverhalten von ihm bekannt sind.

 

Das Filtern der so genannten Sections (EPG-Daten) wird wahlweise durch die DVB-API (HW-Sections=aus) erledigt oder durch den GTX-/eNX-Chip der DBox2 in Verbindung mit einer geeigneten ucode.bin realisiert (HW-Sections=ein). Durch das Filtern mit der GTX-/eNX-Hardware wird erstens die CPU der DBox2 entlastet und zweitens das Filtern beschleunigt. Ergebnis kann ein u.a. schnelleres Sammeln und Anzeigen der EPG-Informationen sein.

 

Folgende Versionen der Ucode-Firmware sind als prinzipiell funktionierend bekannt:

 

    * 0013 * 0014 (built-in) * 00F0

 

 

Bei alle anderen Versionen wird das Filtern durch die Hardware zurzeit nicht unterstützt, z.B. bei folgenden:

 

    * 001A    * b102    * b107    * b121

 

 

eNX

 

Diesen Chip findet man in den Boxen der Hersteller Sagem und Philips. Der Demux demultiplext den Datenstrom und leitet ihn an den MPEG-Dekoder bzw. die CPU weiter und er ist auch noch für das OSD zuständig.

 

 

Zusammenfassung:

Der ENX teilt den Datenstrom in Video / Audio / EPG / teletext usw auf (auch die Streams die fürs Crypto zuständig sind)

 

bei HW-sec "aus" erledigt die CPU das filtern der epg daten

bei HW-sec "an" + µcode 0014 übernimmt dieses filtern der ENX

 

der sectionsd Demond ist dann die Auswertung und Verarbeitung der EPG Daten zuständig, bevor diese ans OSD übergeben werden.

 

Der SPTS Mode legt fest ob die Video und Audio Daten getrennt(AUS) zum Avia gehen oder als TS Mux (EIN)

 

Bei eingeschaltetem SPTS kommt anstatt der Zwitscherns ein schwarzes Bild. Wir könnten also hieran vermuten, dass es auf einen Zugriffsfehler zurückzuführen ist ???

 

Ich könnte mir vorstellen, dass der 0014er µcode aus dem enx wesentlich mehr heraus-kitzelt als der 001a. Wenn dann noch der sectionsd mit zu hoher Priorität auf den enx zugreift - oder eventuell der EPG-strom vom sender zu hoch wird, kommt es zu Zugriffsfehlern (oder Timingfehlern) im ENX-Chip.

 

EDIT

Bei µcode 0014a filtert die CPU die Informationen aus dem EPG-Data-Stream - folglich muss auch diese den sectionsd-Demond beliefern. >> kein Zwitschern.

EDIT ENDE

 

 

 

 

Kann ich die sectionsd prio in meinem laufenden image von hand verändern? Wenn ja wie??

 

Gruß Xander

bearbeitet 8. Oktober 2007 von Xander

[cy_coe]

Kann ich die sectionsd prio in meinem laufenden image von hand verändern? Wenn ja wie??

Aber selbstverständlich geht das. google mal nach 'man renice'

Zu fast jedem Linuxprogramm gibts ne manpage (Hilfe-Seite) die man mit "man 'Programmname' " angezeigt bekommt. Das dbox-flash ist allerdings ziemlich klein, also kann man da keine manpages abfragen (sind nicht installiert). Also einfach nach googlen...

 

Ich hab gerade mal bei mir alle Prozesse von sectionsd reniced:

renice +15 186 187 188 190 193 194 195 196

+15 -> Priorität verringert

186 187 188 190 193 194 195 196 -> die entsprechenden Prozesse

 

Denk dran, daß Du erst mal die Prozess-IDs auf Deiner box per ps herausfinden mußt...

bearbeitet 8. Oktober 2007 von cy_coe

[gerry6n]

@newcode

Also die 0.92 avia-check Version läuft bei mir nicht so gut wie die 0.91. Diese konnte alle Zwitscheranfälle beenden. Die 0.92 macht gerne ein schwarzes Bild und zwitschert auch ma weiter

[bahnbooster]

wenn ich HW Sections auf EIN stelle, hab ich nur Bildrucken - also keine Alternative für mich, es sein, denn ich muss dafür noch zusätzlich was einstellen (SPTS AUS/EIN ??).

[Fazz]

Man kann den sectionsd ja sogar komplett killen,

("killall sectionsd")

damit der aber nicht von alleine neu startet, muss man ihn vorher im

Keyweltmenu->Systemmenu->Keep-alive-Menu ausschalten.

 

Dauert bei mir zwar dann länger(vieleicht auch nur einbildung) bis zum zwitschern,

aber zwitschert halt trotzdem irgendwann. :-(

 

greetz,

Fazz

[tto]

tritt auch auf

[schubsi]

wenn ich HW Sections auf EIN stelle, hab ich nur Bildrucken - also keine Alternative für mich, es sein, denn ich muss dafür noch zusätzlich was einstellen (SPTS AUS/EIN ??).

Moins...

 

Mal was prinzipielles zum HWsections:

 

Wenn ich das hier (Zitat Quote von Fazz:) "warum das nicht ordentlich auf dem eNX läuft ist bis heute unklar" (Zitat Ende) richtig interpretiere, ist die Einstellung HWsections=AN nur was für Boxen, die mit dem GTX bestückt sind, also Nokias, denn meines Wissens sind in Sagem und Phillips ausschließlich eNX verbaut worden.

 

Meine Erfahrungen mit dem sectionsd: Man kann durch das Killen oder Vermindern der Prio des sectionsd zwar die Laufzeiten der Box (subjektiv?) verlängern, aber Bildhänger/Zwitschern oder "Freezes" (Kanal nicht verfügbar) nicht komplett ausschliessen.

 

Bei wichtigen Aufnahmen nehme ich mir immer die Zeit, vorher die Box runter zu fahren, bzw. einen manuellen Timer zu setzen, der rechtzeitig vor der Aufnahme die Box in den Deep-Standby schickt. Damit hatte ich in 99% der Fälle Glück...

 

Interessant finde ich, dass die Box manchmal (Kanal nicht verfügbar) so derartig aus dem Tritt gerät, dass der Tunertreiber zu NIX mehr überredet werden kann... Habe aber noch keine Idee, wo man(n) da ansetzen könnte. Manchmal kündigen sich solche Hänger durch leise Knackgeräsuche an.

 

Muss dazu sagem (Ha! kleine Wortspielerei ) - ne - also sagen, dass ich offensichtlich einer der Glücklichen bin, dessen Sagem nun eigentlich so überhaupt gar nicht zwitschert (ich hörs nur manchmal, wenn ich das Antennenkabel ziehe ), aber die Freezes finde ich manchmal auch ganz schön anstrengend, weils sie immer dann zuschlagen, wenns am spannendsten ist, und dann das Warten auf den Reboot...

 

PS: der µcode.001A machts bei meiner Sagem übrigens nicht sonderlich viel besser als der 0014...

 

Nun denn, soviel zur Philosophie, und nun zurück zur Werbung!

 

-==[schubsi]==-