Verwendete AudioPID Merken

[dcdead]

Es gab mal nen patch für die zapit, mit dem neutrino sich die zuletzt benutzte audiopid gemerkt hat.
Das hat auch bis zu einem gewissen zeitpunkt perfekt funktioniert, aber seit ein paar wochen geht das nicht mehr, patch funktioniert, file wird angelegt, aber die spur wird nicht richtig ausgewählt.

Könnte jemand eventuell diesen patch (von barf glaub ich) aktualisieren?

*bettel*

[dcdead]

Werde ich in diesem board bewusst ignoriert oder was ist los?

[Sepp776]

also ich hab von so einem Patch noch nie was gehört. Vielleicht schreibst du barf mal ne PM?

Wenn du was rauskriegst poste es aber auf jeden Fall mal

Ciao,
Sepp.

[dcdead]

hab ihm schon ne pm geschrieben, sogar 2 mal glaub ich, aber keine antwort

Hab im ursprünglichen thema auch schon das gleiche geschrieben-ebenfalss keine antwort

[Barf]

Der Patch funktioniert nicht mehr, weil sich recht viel in den Datenstrukturen in zapit sich geändert hat. Ich habe mich das Ding bei der Zeitpunkt von dcdeads erste Post in dem CDK-Forum angeschaut, und es ist wirklich keinen "schnelle Fix".

Bei der Zeitpunkt das Thema hochkam http://tuxbox-forum.mine.nu/forum/viewtopic.php?t=27600, hat zapit mehre lästige Beschränkungen; mein Patch hat sie alle (imho) beseitigt. Inzwischen hat die offizielle Version alle diese Beschränkungen gefixt -- mit der Ausnahme vom Abspeichern von AudioPIDs zwischen Sessions. Dies muss aber von Anfang an neu Programmiert werden -- am Besten wäre sicherlich die offizielle Devs "unter Druck" zu setzen. Selbst habe ich nicht wirklich Bock, inoffizielle Patches zu unterhalten

Aber wer weiss, auch ich vermisse die Funktionalität, vielleicht komme ich irgendwann dazu... ...

@dcdead: habe keine PMs von dir bekommen.

Barf

[Sepp776]

@barf: Warum machst du's nicht einfach offiziell?
Spricht doch nichts dagegen oder? Wenn du Zeit und Lust hast natürlich

CU,
Sepp.

[Barf]

Eine aktualisierte Version des Patches ist auf mein dBox-Page (WWW unten drucken) erhältlich. Sags Bescheid falls funktioniert/nicht funktioniert.

@sepp776: ich habe, aus einige Grunden, kein Lust, mich as Dev anzumelden. Ich wurde mich aber freuen, falls die Devs den Patch (evtl in modifizierter Form) committen wurde. Aber irgendwie halte ich es als sehr unwahrscheinlich ...

Barf

[jmittelst]

@Barf: Endlich hab ich mal jemanden, der sich mit der Zappit auskennt.
Woran liegt es, das Neutrino bei Multifeed nicht autom. erneuert? Also, wenn z.B. Bundesliga läuft, bevor Premiere mit der Multifeed-Übertragung angefangen hat, muß man zuerst vom Kanal runterzappen, nur wenn man während Multifeed reinzappt, bemerkt Neutrino, das Multifeed da ist und gibt das Auswahlmenü (Spiel1, Spiel2, ...) frei.
Kann man das nicht auch "rauspatchen"?
cu
Jens

[morgoth]

Hallo,

hat jemand den neuen Patch von Barf getestet? Besteht die Möglichkeit eine kompilierte Version der Zapit mit den Änderungen von Barf zu bekommen?

[dcdead]

OK es geht

Vielen Dank

[essu]

Falls Barfs Patch funktioniert, ist es kein Problem, ihn ins Yadi-Image (und CVS) zu übernehmen, aber wie Barf schon geschrieben hat, diese 'inoffiziellen' oder 'outside' Patches sind eine undankbare Angelegenheit, da sie bei jeder Änderung des CVS überprüft und evtl neu angepasst werden müssen. Der bessere Weg wäre direkt ins tux-cvs.

[morgoth]

Cool,

das sind gute Nachrichten, jetzt müsste man nur an diese Zapit herankommen.

[Barf]

zapit binary mit dem Patch ist auf meinem dBox-Page erhältlich. (Wird aber nicht aktualisiert.)

Noch etwas: Falls jemand einen alten audio.conf-File runliegen hat (von frühere Versionen), dies löschen, und zwar wenn zapit nicht aktiv ist. Nicht wirklich kritisch...

[Soli]

@Barf

Patch funktioniert prima..danke

@Devs
könnt ihr den patch nicht ins tuxbox-cvs übernehmen ?

[morgoth]

Bevor es wieder in Vergessenheit gerät. Gibt es Bestrebungen den Patch von Barf ins CVS zu übernemmen?

[Barf]

Ich habe testweise ein "Turboversion" von dem Patch hier abgelegt. Soll etwas sparsammer mit "Plattenplatz" (10 Bytes/channel) und etwas schneller beim Lesen und Schreiben sein. Leider geht dadurch die menschliche Lesbarkeit (und Editierbarkeit) von auto.conf verloren -- deswegen in autoPIDs.data umbenannt.

Sagz Bescheid wie es funktioniert

[essu]

Ich habe testweise ein "Turboversion" von dem Patch hier abgelegt. [...]

Sagz Bescheid wie es funktioniert

Na, dann hier auch nochmal :
Der alte Patch von Barf ist ja seit einiger Zeit schon im Yadi-Image, wenn ihr den neuen getestet habt, bin ich auch an den Ergebnissen interessiert.

[morgoth]

@barf
wäre es möglich deinen turbo-patch auch als Binary auf deiner HP zur Verfügung zu stellen?

[Barf]

wäre es möglich deinen turbo-patch auch als Binary auf deiner HP zur Verfügung zu stellen?

Nö, sowas wie ein Binary von einem Patch gibt es nicht , aber ein Binary von zapit mit dem Patch appliziert; bitteschön!

[Janus]

Sei bedankt!

Format scheint erweitert, um die weiteren 'Relationen' zu übernehmen, stehen allerdings bis auf die SID hier (DietmarW vom 29.06.04) auf 0000.

Frage am Rande: Warum nimmst Du auch die Dienste mit in die Auflistung, die garkeine weiteren Audio-Pids haben? Da Neutrino in solchen Fällen keine Audiostream-Auswahl anbietet, müssten doch diese Infos verfügbar und nutzbar sein...
Auf jeden Fall würde so die Datei um Einiges kleiner.
(und schneller gelesen und gespeichert)

Ein kleiner Nachteil, insbesondere gegenüber einer 'BouquetEmbedded'-Lösung ist die fehlende Möglichkeit, 'mehrsprachige' Services auch in mehreren 'Sprach-Bouquets' entsprechend den AudioStreams unterzubringen. Da die Bouquets ja keine ID haben ...

Janus


edit Nachtrag: Apropos Bouquet-ID - war da bei PPC nicht was mit 4-Byte Boundary und der optimalen Schreib/Lesegeschwindigkeit?
Wer weiß, was da zukünftig in den Bestand noch reinkommen wird.
(Außerdem wären 16 Byte pro Item im Hexeditor schöner anzusehen ...)

[Npq]

Nur mal so am Rande, die Auswahl über die Audio-PIDs ist eigentlich keine gute Idee, weil die PID sich ändern kann/darf.

Korrekterweise muß man in der SDT/PMT die entsprechenden Deskriptoren auswerten, normalerweise finden sich in der SDT Component Deskriptoren, mit denen man einen Stream eindeutig zuordnen kann.

Und deswegen gehört sowas auch nicht in Zapit (DVB-Ebene) rein.

Es wäre natürlich schon denkbar, die PIDs von der Useranwendung anwählbar zu machen für Härtefalle (Anbieter halten sich ja nicht wirklich an die Standards manchmal).

Dann sollte aber klar davon ausgegangen werden, daß die AudioPID verschwinden kann und es sollte auch nicht standardmäßig für alle Services aktiviert sein sondern eben nur für diese Härtefälle.

[Janus]

Hehe,

gibt es in C++ keine if-Konstrukte mehr?

Die (mögliche) Vorgabe der Audio-Pid ist außerhalb der Neutrino-Welt eigentlich fast Standard. Zumindestens was die Wünsche der 'Aufzeichner' betrifft.

Ich denke ein Auslesen der verfügbaren Audio-SubStreams in der PMT mit anschließendem Vergleich der 'hinterlegten' Audio-Pid (danach käme evtl. das oben genannten Kontrukt zur Anwendung) sollte auch für Linux auf der dBox kein Problem darstellen. Eine mögliche Verzögerung durch Umschalten von einem evtl. gecancelten AudioStream wäre mE vertretbar.
(Immer noch besser als ein nicht vorhandener AC3-Stream auf dem Direkt-Portal automatisch getuned == Schweigen im Walde auf dem DD-Equipment )

Janus

[Npq]

Wieso muß man dafür die PID wissen? Da reicht doch wohl die Info, daß man den deutschen nicht-AC3-Audiostream haben möchte, oder?

Was machst du wenn ein Anbieter 2 PIDs je nach Laune abwechselnd für englisch und deutsch vergibt?

Ja, ich weiß, dann dekodiert ihr den Audiostrom und analysiert die Daten mit Hilfe einer Sprachdatenbank ob es sich dabei um englische oder deutsche Worte handelt.



Ich find's halt nicht gut das in Zapit einzubauen, wenn jemand anders meint, es geht in Ordnung soll es mir egal sein, Begründung wäre dann nur interessant.

Wenn das in Neutrino geschieht ist es ja auch OK.

[insolvenzia]

Ich lese das hier gerade mehr oder weniger zufällig, aber mir fällt dazu ein:
Warum macht ihr das nicht in der zapit über einen Parameter (so wie mit "-u")? Wer das Feature mag, bindet es ein, und wer nicht der nicht. Somit wird auch vielleicht der Feedback größer, inwiefern das tatsächlich Probleme aufwirft

Ich z.B. nutze "-u" wegen den WDR Regionalsendern, und habe keinerlei Probleme.

[essu]

Ich kann Npqs Argumente nach vollziehen, aber trotzdem halte ich es für ein interessantes feature, dass man zumindest mal in einem snapshot testen sollte. Wenn es eine bessere Lösung gibt: Her damit.