Aktualisierungsproblem bei der Änderung der Anzahl der APIDs

[TheGreatCornholio]

Hallo zusammen,

ich hoffe ich bin hier richtig, ansonsten verschiebt mich bitte .

Als begeisterter "Streamer" bin ich über das Problem gestolpert, dass anscheinend keine automatische Initialisierung zusätzlicher APIDs bei verschlüsselten Sendern erfolgt, wenn sich die Anzahl der APIDs eines Senders seit seiner ersten Anwahl (Genaueres folgt noch) erhöht. Auch die automatische Aktualisierung der Streaminformationen (Anzeige über Neutrino Streaminfos oder Tonauswahlmenü) scheint nicht zu funktionieren, wenn kein Senderwechsel gemacht wird (aber das gehört eventuell ins Neutrino Forum).


Zur näheren Erläuterung meiner Beobachtungen:

Wenn ich nach dem Reboot der DBox Premiere 1 anwähle und dort eine Sendung mit einer APID ausgestrahlt wird, zeigen die Streaminfos korrekt diese APID an und auch das Tonauswahlmenü (grüne FB-Taste) ist entsprechend nicht verfügbar (ach!? ... bitte Geduld ich komme bald auf den Punkt).

Bleibe ich auf diesem Sender und die nachfolgende Sendung wird dann z.B. in Zweikanalton ausgestrahlt, so ändern sich leider weder die Streaminfos (es wird immer noch eine APID angezeigt) noch wird das Tonauswahlmenü aktiv (das ist das erste Problem). Schalte ich nun auf einen anderen Kanal (z.B. Premiere 2) und dann wieder zurück auf Premiere 1, so werden die Streaminfos aktualisiert und auch das Tonauswahlmenü ist verfügbar, aber wenn ich dann die zweite APID anwähle, um den Ton anzuhören, so höre ich nichts (und das ist mein Hauptproblem). Und wenn ich diese Sendung streame, bleibt die Datei für diese APID auch leer.

Schalte ich nach dem Reboot erst dann auf den betreffenden Sender, wenn beide APIDs übertragen werden, dann ist der Ton auch hörbar und er lässt sich auch aufzeichen (wer möchte, kann sich meine Testreihe dazu in epischer Breite unter http://tuxbox.org/forum/viewtopic.php?t=26086 durchlesen - ist aber nicht zwingend notwendig ).

Bei der Untersuchung des Konsolenlogs ist mir dann aufgefallen, dass immer dann, wenn die camd2 nach dem Umschalten protokolliert

• [camd] starting onid 0001 sid 000a
  descramble onid: 0001 sid: 000a status: 1d1d

der Ton zu hören ist, aber in den Fällen, in denen kein Ton zu hören war, die Meldung

• [camd] refusing duplicate service

im Log stand.

Daraufhin habe ich mir das CVS gezogen und mir in camd.c die Stelle gesucht, an der diese Meldungen generiert werden. Dort habe ich dann gefunden, dass die jeweils letzten acht verschlüsselten Services in einem Array gecached werden, und eine erneute Anfrage an das CAM Modul nur dann gestellt wird, wenn ein neunter Sender hinzukommt. Nun vermute ich, dass beim Hinzukommen weiterer APIDs jedoch ein neuer Request an das CAM Modul geschickt werden muss, damit auch die neuen APIDs aus dem Stream gefischt werden (bitte nicht hauen, wenn ich nun total falsch liege, aber so habe ich mir das als Laie erklärt). Um diese Vermutung zu verifizieren, habe ich kurzerhand die Länge des Arrays auf 1 gesetzt und damit die Reinitialisierung des Caches bei jedem Umschalten erzwungen. Und siehe da, zumindest nach dem Umschalten waren alle Tonoptionen verfügbar und hörbar - auch dann, wenn ich zuvor bereits mit geringerer Anzahl von APIDs den Sender schon einmal angewählt hatte.

Hier kommt jetzt mein erste Frage an euch Profis. Ist meine Vermutung richtig (die, dass bei der Erhöhung der APID-Anzahl das CAM-Modul für diesen Service neu initialisiert bzw. zumindest informiert werden muss)? Oder stoße ich damit nur zufällig ein Folge-Event an, das für die eigentliche Bereinigung des Problems sorgt?

Sollte die Vermutung stimmen, muss dann wirklich das gesamte CAM-Modul reinitialisiert werden, oder gibt es auch eine CAM-Funktion, mit der explizit ein bereits entschlüsselter Service überschrieben/aktualisiert werden kann?

Und dann natürlich meine zweite Frage. Gibt es bereits ein Event, dass gefeuert wird, wenn sich die Anzahl der APIDs ändert (damit man das lästige Umschalten auch noch überflüssig machen könnte)? Wenn nicht, wo müsste ich mich einklinken, um ein solches Event zu erzeugen? Und wenn dieses Event dann verfügbar ist, an welchen Stellen müsste ich es dann auswerten, um den gewünschten Erfolg (die automatisch Aktualisierung sowohl der Anzeige als auch des CAMs ohne Senderwechsel) zu erzielen?

Da ich ein absoluter tuxbox-CVS-Neuling bin, wäre ich über jeden Hinweis von euch dankbar. Nur durch Source-Code lesen und Forum-Stöbern bin ich leider noch nicht im Detail dahinter gestiegen, wo ich bezüglich des Event-Handlings einsteigen müsste. Sorry für die vielen Worte (ich kann leider nicht anders, auch wenn ich mich immer weider bemühe ) und vielen herzlichen Dank an alle Helfer bereits im Voraus.

In freudiger Erwartung alsbaldiger Antworten,
Ralf

[TheGreatCornholio]

Nach dem sich hier niemand erbarmt hat, habe ich mein Glück im #dbox2 chat gesucht und in der Person von obi gefunden (vielen Dank nochmals auch an dieser Stelle - habe mich gefühlt wie bei einer Papst-Audienz).

Hier kurz zusammengefasst die Aussagen:

1) Die von mir beschriebenen "Probleme" haben alle (it's a feature ).
2) Die CAM muss tatsächlich beim Wechsel der APIDs für den betreffenden Service zurückgesetzt werden (Modul camd.c).
3) Das Event und auch die enstprechende Verabreitung, damit der APID-Wechsel auch ohne Umschalten geht, ist berets im Source-Code des Moduls zapit.cpp berücksichtigt, wurde aber auf Wunsch von alexW wegen Instabilität deaktiviert.

Um dennoch diese Featurs zu nutzen, habe ich folgende Änderungen gemacht:

1) Im Modul camd.c, Funktion adddescrambleservice, die Zeilen

Code: Alles auswählen

printf("[camd] refusing duplicate service\n");
return -1;

ausgetauscht durch

Code: Alles auswählen

print("[camd] restarting current service\n");
break;

um den Restart des aktuellen Services auf der CAM beim Umschalten zu erhalten

2) Die Module zapit.cpp und zapsi/pmt.cpp mit Option -DUPDATE_PMT übersetzt um das Eventhandling zu aktivieren, damit auch ohne manuelles Umschalten eine Änderung der APID-Anzahl erkannt wird und über einen Aufruf von zapit der Service restarted wird (Dank der Änderung aus 1)


Nach dem die ersten Tests mittels YADD geklappt haben, habe ich kurzerhand meine geänderten camd2 und zapit Binaries im aktuellen Snapshot-Image vom alexW ausgetauscht und auf meine Box gepackt. Erste Tests waren erfolgreich, wobei der Dauertest noch aussteht.

Ich hoffe, diese Info's interessieren auch noch andere (außer mir).

Liebe Grüße,
Ralf

[Spectre]

Ich hoffe, diese Info's interessieren auch noch andere (außer mir).

Ja, tun sie!

Danke für dein Engagement!

Gruß,

Thorsten

[Z80]

@TheGreatCornholio: danke für deine mühe
Wie wäre es, wenn du die kompilierten binaries z.b. bei homar (remote-admin.de) zur verfügung stellst? das vergrössert nämlich den potentiellen tester-kreis ganz erheblich. die binaries zapit & camd lassen sich ja leicht temporär per ftp ins jffs nach z.B. /var/bin kopieren. dann reicht ja das anpassen der start_neutrino um die gepatchten binaries einzubinden.

[Zwen]

Ich hab die zapit mit UPDATE_PMT bei mir seit ca. 2 Wochen problemlos am laufen. Kann auch kein stabilitätsproblem feststellen. Nach der deaktivierung dieser Funktion durch alexW hat obi aber nochmal nen fix commited, evtl. hat der ja genau diese stabilitätsproblem gefixt...

Zwen

[Squeezy]

Für's Testen könnte ich mich auch begeistern.

[wwershofen]

Jipp, auch bei mir großes Interesse an den Binaries oder Alternativ die Sourcen mit Compile-Anweisung.

Danke für Dein Engagement, Ralf.

cu
wolle

[franky_b]

Ja ich bräuchte die gepatchten binaries auch dringend. Habe jetzt 2x über Timer was aufgenommen und jedes mal fehlte die Dritte Tonspur.

Zur Not wär ich über ne kurze Anleitung (oder Link zu bestehender Anleitung) dankbar, wie ich nur diese Module neu kompiliere (und welche Änderungen genau). Aber binaries wär echt besser.

Danke schonmal

FrankyB

[zexma]

Laut https://lists.berlios.de/pipermail/tuxb ... 14489.html

Code: Alles auswählen

obi         03/11/20 04:15:07
  Modified:    tuxbox/tools/camd camd.c
  Log:
  - fixed bug reported by TheGreatCornholio which caused refusing of
    service updates

ist die Änderung jetzt ins cvs eingeflossen. Da diese camd ja nun "standardmässig" keinen Premiere-Support mehr bietet, ist das Testen ob die Aktualisierung der APIDs bei Premiere nun klappt schlechterdings ohne Selbstkompilierung nicht möglich. Oder?
Falls ich hier etwas missverstanden haben sollte, bitte ich um Aufklärung.

[kerlimann]

recht hast du, das bleibt leuten wie alexw vorbehalten, er hat den patch umgehend gecancled, weil es auf SEINER box nicht lief.

anstelle das zum testen (fuer die selbstcompiler) etwas einfacher zu machen, in dem das das in eine global datei packt, wurden mehrere dateien genommen. auch fuer mich recht unverstaendlich.

wie auch immer - alexw hatte mal wieder das letze wort. wenns bei ihm nicht geht, kann es bei niemand anderem gehen.

fuer mich ist offensichtlich, das alexw ein hardware problem hat. und zwar zwischen den ohren!
traurig!

wenn er fuer sich was testen will, OK, aber warum checkt er es ein, und sagt wenige minuten spaeter:" iss nich"?

[obi]

@kerlimann:
ist es so schwer zu kapieren, dass es ne weile stabil lief und dann nach dem commit gecrashed ist?
wieso stoesst du eigentlich jeden tag mit jemandem an?

die aenderungen sind nunmal in mehreren dateien. egal wie man es dreht. weiss nicht was daran jetzt so schlimm sein soll.

[TheGreatCornholio]

Leute, habt euch lieb' .

Es sieht wohl tatsächlich so aus, als ob die Änderungen noch nicht der Weisheit letzter Schluss sind. Die camd-Änderung läuft bei mir sauber (d.h. nach dem Umschalten ist immer alles OK), aber das automatische Aktualisieren (UPDATE_PMT Code) haut nicht immer hin und scheint auch ab und dann die Box ins Nirwana zu führen.

Genaueres konnte ich leider noch nicht herausfinden, da die Anzahl der Testfälle zu der Zeit, zu der ich zuhause war, in der vergangenen Woche recht klein war.

Es sieht wohl so aus, dass nach dem Reboot die erste anstehende Aktualisierung immer funktioniert. Für die meisten (ich traue mich noch nicht zu sagen: für alle) weiteren Fälle haut es dann allerdings nicht mehr hin. Das Ereignis feuert zwar bei jeder Änderung (habe hierfür zusätzliche fprintfs auf die Konsole eingebaut), aber trotz ausgelöstem zapit-Aufruf sind die zusätzlichen APIDs nicht verfügbar. Und wie bereits angedeutet, hatte ich auch einmal einen Freeze der Box nach der Bearbeitung des Events.

Ich werde zunächst also erst einmal weiter testen, um exakte Info's hinsichtlich der Umstände zu erhalten, wann die Aktualisierung geht und wann nicht und in welchen Fällen die Box einfriert.

Bitte habt Verständnis dafür, dass ich euren Wünschen auf die Zusendung der Binaries nicht nachkommen möchte, da ich aufgrund der Jugendschutz-Thematik keine Angriffsfläche bieten möchte (bin halt ein Weichei).

In der Hoffnung auf Weltfrieden,
Ralf

[Zuppel12]

@Ralf


Seit einigen Tagen klappt es bei mir auch nicht mehr mit der 3. Tonspur. So habe ich nen bischen gesucht und diesen Beitrag gefunden.

Schön, das es schon eine Art Lösung gibt, jedoch bin so richtig der Windoofi

d.h. kein blassen von Linux (Ihr könnt euch garnicht vorstellen, wie Stolz ich war, dieses Neutrino auf meine dBox zu bekommen). Aber jetzt irgend etwas in den camd.c o.s.ä. rum ändern........Oh Gott.....wollt Ihr mich foltern ?????

Wie kann einem einfachen Menschen (User) gehofen werden????

Gruß

Zuppel12

[Homar]

mache eine YADD und gut ists.

Anleitungen dazu kannste unter http://remote-admin.de/TuxboxDevHowtoV15 finden

MFG
Homar

[Zuppel12]

@Homar,


Danke für den Tip. Mensch...warum hat mir den nicht gleich jemand diesen Rat gegeben. Voll einfach!!!!!! Man muss nur darauf kommen.....oh mann....oh mann......da hätte ich auch selber darauf kommen können.

Ich könnt mich so was in den A beissen!!!!!



Jetzt weiss ich endlich genau so viel wie vorher

Gruß

Zuppel12

[Z80]

ich verlink da mal https://tuxbox-cvs.sourceforge.net/foru ... 929#193929