Transedit veraltete Sender entfernen

[Flepp]

Hallo

 

 

Bin absolut begeistert von Transedit. Ich kenne keinen besseren, schnelleren und flexiberen Scanner.

 

Hätte hier noch ein paar Vorschläge die Wahrscheinlich nicht zu schwer zu realisieren sind.

 

- Wünche mir eine Option wo nicht mehr vorhandene Sender automatisch entfernt werden.

- Ebenfalls eine möglichkeit mit [X] gekenzeichnete Transponder aus der Channels.dat automatisch zu löschen.

 

 

Viele Grüsse.

 

Flepp

[Griga]

die Wahrscheinlich nicht zu schwer zu realisieren sind.

Was nicht schwer zu realisieren ist, ist bereits realisiert

 

Zunächst müsste definiert werden, unter welchen Bedingungen ein Sender als nicht mehr vorhanden gilt, und das ist das große Problem. Solche Automatismen beinhalten immer die Gefahr von Irrtümern. Eine zeitweilige Empangsstörung oder eine Änderung der Service ID, und schon fliegen Sender raus, obwohl sie der DVBViewer noch empfangen könnte.

[Flepp]

@Griga

 

Empfangsstörungen sehe ich nicht so als das Problem, das gleiche könnte doch auch vorkommen beim suchen neuer Sender.

 

Man könnte das gleiche Algorithmus nutzen wie Transedit neue Sender erkennt, so müsste es doch in umgekehrter Weise auch erkennen dass Sender nicht mehr vorhanden sind.

 

Unter Filter 3 würde ich zusätzlich eine option setzen um verlorenen Sender anzuzeigen um dann nachträglich die Möglichkeit zu haben sie alle oder einzeln zu entfernen.

 

Viele Grüsse

[Darwin]

Solange die Indentifikationsmechanismen nicht wirklich eindeutig sind - siehe Fehlverhalten bei der Zuordnung von Favoriten - würde ich mir das als Automatik nicht wünschen.

 

Für den Notfall reicht mir der Scan mit dem internen Scanner und das nachfolgende manuelle Löschen der nicht fettgedruckten Services im internen Editor.

Da könnte ich mir eine Option: "Lösche alle nicht aktualisierten Sender des gescannten Bereichs" als durchaus praktisch vorstellen.

Das Merkmal 'aktualisiert' muß ja für die Schriftumstellung vorhanden sein.

Ich denke, das könnte relativ einfach zu lösen sein.

 

Für die Fehlerkorrektur mache ich danach einen weiteren Suchlauf.

Edited September 23, 2008 by Darwin

[Griga]

Man könnte das gleiche Algorithmus nutzen wie Transedit neue Sender erkennt, so müsste es doch in umgekehrter Weise auch erkennen dass Sender nicht mehr vorhanden sind.

In der Anleitung wird darauf hingewiesen, dass die Wiedererkennung in der Kanalliste vorhandener Sender keine sichere Bank ist. Nicht umsonst gibt es eine Möglichkeit, den Schwellwert für die Anzahl übereinstimmender Merkmale in den Settings anzupassen.

 

Außerdem erfordert die Identifikation nicht mehr vorhandener Sender in der Kanalliste ganz andere Voraussetzungen. Angenommen, du scannst einen einzelnen Transponder. Nun veranlasst du, dass nicht gefundene Sender aus der Kanalliste gelöscht werden. Das wären dann praktisch alle, außer die Ergebnisse auf der einen Frequenz. So hast du dir das sicher nicht vorgestellt, oder?

 

TransEdit müsste in diesem Fall als ersten Schritt eine Untermenge der Kanalliste ermitteln, nämlich alle Sender, die auf einem bestimmten Transponder zu erwarten wären. Dabei können keine service-spezifischen Merkmale wie Service ID, Video-PID, Audio-PID usw. verwendet werden. Die Identifikation müsste sich allein auf Merkmale stützen, die spezifisch für den Transponder und das DVB-Netzwerk sind (Frequenz, Polarisation, Symbolrate, FEC, DiSEqC, Tansportstream-ID...).

 

Dabei stellt sich wieder die Frage, wie "scharf" man dabei vorgeht. Viele dieser Merkmale sind nämlich unter bestimmten Bedingungen beliebig oder zumindest variabel. Zum Beispiel ist bei einer Ein-Kabel-Anlage die Polarisation egal. Die Frequenz kann bei Satellit um ein paar MHz abweichen, ohne dass es den Empfang verhindert. DiSEqC ist beliebig, wenn die Außenanlage kein DiSEqC braucht. Auch wenn die Transportstream-ID falsch oder = 0 ist (z.B. aufgrund eines fragwürdigen Imports), gibt der DVBViewer den Sender noch wieder. Und so weiter... wenn es um Löschen geht, würde ich "sehr scharf" vorziehen, auch auf die Gefahr, dass tote Sender übersehen werden.

 

Die so erzeugte Untermenge der Kanalliste wäre dann mit den Scanergebnissen des betreffenden Transponders abzugleichen, und alles, was der Scanner nicht gefunden hat, könnte man in einer zusätzlichen Liste (also einem Extra-Fenster) zum selektiven Löschen anbieten. Vollautomatik wäre mir hierbei zu riskant. Dabei ist noch zu klären, wie man die Daten zweckmäßigerweise darstellt (als lineare Liste wie die Scanergebnisse oder als Baumansicht entsprechend der DVBViewer-Kanalliste, was die Orientierung erleichtern würde), und wie man mit Audiospuren verfährt - es gibt Fälle, in denen bestimmte Spuren nur zeitweise gesendet werden. Trotzdem möchte man sie wahrscheinlich in der Kanalliste behalten.

 

Und nun erzähle mir noch jemand, das wäre einfach

 

Solange die Indentifikationsmechanismen nicht wirklich eindeutig sind - siehe Fehlverhalten bei der Zuordnung von Favoriten - würde ich mir das als Automatik nicht wünschen.

TransEdit verwendet einen ausführlichere Art der Identifikation, die auf mehr Merkmalen beruht. Trotzdem - eine eindeutige Identifikation gibt es nicht und wird es nie geben. Eine solche Erwartung ist praxisfremd. Die Frage ist vielmehr, wie man mit den immer vorhandenen Unschärfen und Mehrdeutigkeiten umgeht.

[Lars_MQ]

Da könnte ich mir eine Option: "Lösche alle nicht aktualisierten Sender des gescannten Bereichs" als durchaus praktisch vorstellen.

Auja, ich seh das schon: Scanne eine frequenz und wähle die option und schwupps ist die kanalliste sehr, sehr übersichtlich...

Es gibt gute gründe, warum nicht alles gemacht wird, was möglich wäre...

[Flepp]

TransEdit verwendet einen ausführlichere Art der Identifikation, die auf mehr Merkmalen beruht. Trotzdem - eine eindeutige Identifikation gibt es nicht und wird es nie geben. Eine solche Erwartung ist praxisfremd. Die Frage ist vielmehr, wie man mit den immer vorhandenen Unschärfen und Mehrdeutigkeiten umgeht.

 

Ok danke für die ausführliche Beschreibung des Problems. Ist mir schon klar dass zuviele Variabeln im Spiel sind um ein automatisches löschen zu verantworten. Die Ergebnisse könnten niemals 100 prozentig berechenbar sein.

 

Aber könnten man nicht neben den Optionen "Send","Update" zusätzlich ein "Replace" einfügen damit man die einzelnen Transponder oder ganze Kanallisten einfach manuel und unter eigener Verantwortung mit dem Suchlauf-Ergebniss ersetzen kann ?

 

 

Viele Grüsse

 

Flepp

[Darwin]

des gescannten Bereichs

Ob ich mir dabei schon was gedacht habe?

Wir wollen doch nicht permierezertifizierte Humaxfirmware emulieren

 

 

eine eindeutige Identifikation gibt es nicht

Mmhhmmm, deshalb ist auch die DVB-Spezifikation eher nutzlose Fleißarbeit ???

Das System mit den Systeminformationstabellen ist doch klar hierarchisch organisiert, mit vorgegebenen Referenzen, runter bis zum letzten ElementarStream.

Selbst wenn sich bei temporären Feeds im Satbereich nicht daran gehalten wird (TSID=1, ONID=1), bleiben immer noch physikalische Umgebungsparameter wie Frequenz, Symbolrate, FEC und eventuell weitere, die eine zusätzliche Differenzierung für diese Sonderfälle ermöglichen. DXer werden zudem ihre Feed-Scans wahrscheinlich nicht mit den Transponderlisten für die Provider-Bouquets mischen.

 

Allerdings habe ich mir - mangels Verfügbarkeit - noch keine Gedanken über IPTV gemacht.

Da hat die Telekom leider den Tellerrand gemacht...

 

 

Ich habe hier z.B. bei meinen ~6000 Sat-Services keinerlei Schwierigkeiten, die mit referenzieller Integrität in eine relationale Datenbank (DataSet) einzulesen.

Was mE die Eindeutigkeit der von mir verwendetet Referenzen bestätigt.

 

Sagen wir daher vielleicht lieber:

Eine eindeutige Identifikation mit den derzeit im DVBViewer zu diesem Zweck verwendeten Daten gibt es nicht.

 

Dem könnte ich mich allerdings anschließen!

 

 

Aber, wie gesagt, ich habe ja meinen manuellen Workaround.

Ich für meinen Teil würde sowieso ein baldiges 'Goto Angela' in TransEdit vorziehen.

[Moses]

Ein Sender in IPTV ist eindeutig durch IP+Port spezifiziert.

[Scan_Speedy]

Und wenn man ne Art Timestamp einbaut.

 

Alles was älter als X Tage ist, fliegt raus.

Wer 1x pro Monat scannt, der übernimmt dann die neuen Sender, und alle wieder gefundenen bekommen einen neuen Timestamp.

Man wählt dann selbst aus, z.B. "alle Sender älter X Tage" löschen.

 

So entfernt man dann alle Sender, die seit X Tagen inklusive der Scans nicht mehr gefunden werden.

 

PS: Ich hab einige Sender doppelt in der Senderliste, da ich Update mit Send verwechselt hatte.

Gibts da einen Trick, um die doppelten zu entfernen, außer löschen und neu scannen ?

[Derrick]

..bevor was rausgeworfen wird, muss die identifizierung verbessert werden. Das ist ein alter hut

 

meine methode: neu scannen mit sat + datum als root und die alte root gnadenlos löschen. Die arbeit der pickerei mache ich mir nicht. Dazu sind liste und editoren auch nicht geeignet.

 

Alter wunsch: favoriten (die ich behalte) besser ausstatten, sodass der gewünschte sender ungeachtet der ausgangsposition in der liste gefunden wird.

[Lars_MQ]

Allerdings habe ich mir - mangels Verfügbarkeit - noch keine Gedanken über IPTV gemacht.

Dort wäre das tatsächlich möglich. Das ist wie SAT und pro transponder nur ein kanal. Eineindeutig und ein traum zu verwalten

[Lars_MQ]

Alter wunsch: favoriten (die ich behalte) besser ausstatten, sodass der gewünschte sender ungeachtet der ausgangsposition in der liste gefunden wird.

Dazu gabs schon (intern) einen entwurf, der aber ignoriert wurde.

[Griga]

Mmhhmmm, deshalb ist auch die DVB-Spezifikation eher nutzlose Fleißarbeit ???

Ein Grundgerüst. Theoretischer Idealfall, der das reale Verhalten von Anbietern und vor allem Anwendern nicht mit einbezieht.

 

Wenn Anwender X einen Sender aus einer im Forum angehängten INI importiert, die auf den manuellen Eingaben von Anwender Y beruht, und Anwender X dann den gleichen Sender durch Scannen findet, kann es bei den Daten allerlei Abweichungen geben, die sich nicht zwangsläufig durch "habe kein Bild und Ton" äußern. Die Service ID kann falsch sein, die Transportstream ID, die PMT-PID, FEC steht in einem Fall auf 4/3, im anderen auf Auto, DiSEqC ist hier None, dort PosA/OptA... was nützen dir dann noch Spezifikationen?

 

Und wie oft wir schon erlebt haben, dass Anbieter mit ihrem Verhalten außerhalb der Spezifikationen lagen. Könnte ich x Beispiele für nennen.Wenn es dann im DVBViewer nicht funktioniert, kommt üblicherweise Derrick und fordert, die Anwendung habe in solchen Fällen fehlertolerant zu sein, d.h. sie solle auch mit Daten außerhalb der Spezifikationen sinnvoll arbeiten. So ist das.

[Derrick]

..statt eine neue runde im hornberger schiessen einzuläuten, eine andere frage bzw. wunsch zu transedit

 

ich sammle meine scan.inis an zentraler stelle im netzwerk. Beim export muss ich mich immer umständlich dahin durchklicken. Standard wird nur das verzeichnis von transedit angeboten. Kann der pfad nicht (ev. über ini) festgelegt werden? Die Pro findet den ordner bei im/export im editor von selbst

[Darwin]

Hier wird ein gedanklicher Konzeptfehler deutlich!

(Das Hornberger-Syndrom )

 

Die DiSEqC-Einstellung ist zum Beispiel eine (userdefinierbare) Eigenschaft der individuellen Empfangseinrichtung.

Frequenzen können auch aufgrund der Empfangseinrichtung um mehrere MHz von Daten anderer User abweichen.

Solche Sachen zum Vergleich heranzuziehen ist sinnlos. Im Gegenteil - wie Derrick ja anscheinend schon richtig anmerkt - kann hier eine (am besten einstellbare) Toleranz durchaus Sinn machen.

Die Gruppen - die vom DVBViewer angeboten werden - gehören auch in diese Kategorie.

 

Aber diese Dinge haben mit der Identifikation eines Services Nichts zu tun. (schon garnicht das reale Verhalten von Anwendern)

 

Da gibt es die Verbreitungsart (S, C, T und weitere wie M, H, I), den Lieferanten (Satposition, (Kabel)netzbetreiber, terr. Sendemast usw.) und danach weitere aus dem DVB-Stream reproduzierbare Identifikationen wie z.B. bei DVB-S die ONID, die TSID und die SID. Für Audiofeed - Zuordnung kann man dann noch die APID anhängen und schon steht die 'Route' zum gewünschten Service. Einzig der 'Lieferant' müsste mit einer eindeutigen ID ausgestattet werden, was zum Beispiel bei Satelliten durch die Position schon gegeben ist. Für die Anderen sollten sich auch Lösungen finden lassen (CRC16 über den Netzbetreiber-Namen, geodätische Koordinaten bei Sendemasten, URLs bei IPTV)

 

Und das völlig unabhängig vom User oder seiner Empfangseinrichtung.

 

Ein Design sollte diese Dinge nicht miteinander vermischen, was DVBViewer zudem auch noch mit maximaler Redundanz zelebriert.

Aus diesem Grund ist die Übernahme von Daten aus einer fremden INI schon im Ansatz ein Glücksspiel. Selbst eine aus eigenen INIs assemblierte Channels.dat ist für eine bestehende Favoriten-XML nicht immer geeignet. Fehlt z.B. ein Service in einer frischen Datei, führt der anscheinend eingebaute Suchalgo zu manchmal unverständlichen Ergebnissen.

 

Trennt erstmal die reproduzierbaren DVB-Daten (Services) von den Eigenschaften der Empfangseinrichtungen (Equipment) und macht dann für die reinen Uservorlieben ein drittes Faß (Settings) auf. Die Formulierung sinnvoller Referenzen zwischen diesen drei Datenhaltungen dürfte kein wirkliches Problem darstellen.

 

Dann klappt es auch mit den 'Wiedererkennen'.

[Flepp]

Hier wird ein gedanklicher Konzeptfehler deutlich!

(Das Hornberger-Syndrom )

 

Die DiSEqC-Einstellung ist zum Beispiel eine (userdefinierbare) Eigenschaft der individuellen Empfangseinrichtung.

Frequenzen können auch aufgrund der Empfangseinrichtung um mehrere MHz von Daten anderer User abweichen.

Solche Sachen zum Vergleich heranzuziehen ist sinnlos. Im Gegenteil - wie Derrick ja anscheinend schon richtig anmerkt - kann hier eine (am besten einstellbare) Toleranz durchaus Sinn machen.

Die Gruppen - die vom DVBViewer angeboten werden - gehören auch in diese Kategorie.

 

Aber diese Dinge haben mit der Identifikation eines Services Nichts zu tun. (schon garnicht das reale Verhalten von Anwendern)

 

Dann klappt es auch mit den 'Wiedererkennen'.

 

Darwin hat hier meine volle Zustimmung.

 

Ich erlaube mir auf ein Programm (DVBsVCR2) hinzuweisen was ich mit meiner alten WINTV-NEXUS betrieben habe.

Dieses Programm hat eine abschaltbare Funktion mit der die PSI Tafeln (also die PAT) einmalig eingelesen wird sobald man ein Program anwählt. Hierbei werden in der Kanalliste alle Program Daten innerhalb des Transponders mit der PAT abgeglichen. Neue Sender wurden automatisch gefunden, neue Sendernamen aktualisiert, alte Sender wurden gelöscht, und das alles im Hintergrund. Hat bestens funktiniert. Einen kompletten Sender Scan war dadurch unnötig und die Kanalliste war permanent aktualisiert.

Nur bei abgeschalteten und neuen Transpondern musste man manuel Scannen. Die PAT ist die Referenz und hat alle nötigen Informationen. Abweichende Frequenzen, FEC, DiseqC brauchen und sollten hier nich berücksichtigt werden.

 

Bei einer Senderwahl eines anderen Transponders würde die PAT dann erneut einmalig eingelesen und die Kanaliste dann abgeglichen. Das Autoupdate braucht dann nicht mehr zu erfolgen solange man sich auf der selben Frequenz bewegt.

 

Diese Funktion existiert schon Teilweise durch das Autoupdate im DVBViewer. Nur es beschränkt sich nur auf einen einzelnen Sender, und es werden keine Sendernamen aktualisiert und keine neuen Sender gefunden oder alte gelöscht.

Die Philosophie kann man mit der des EPG updates vergleichen.

 

Zb auf Astra könnten beim anwählen eines ARD Regional Senders, alle anderen im Hintergrund mit aktualisiert werden.

 

Transedit wäre woll dann nicht dafür geeignet, sondern es wäre eine Aufgabe des DVBViewers.

 

Viele Grüsse

[Flepp]

Hallo

 

Habe mich bei Eutelsat Specs schlau gemacht und hier ist jetzt eine mögliche Lösung!

 

Ein Sender wird mit folgenden 3 ID's identifiziert:

 

NIT ID, STREAM Id, SERVICE Pid. Alle Daten aus der PAT

Also ob der Sender noch vorhanden ist oder nicht braucht man nur die oben 3 genanten Attribute zu prüfen.

 

Dieser Algorythmus ist ein Versuch wert.

PAT lesen, wenn "NIT ID, STREAM Id, SERVICE Pid" eine Änderung -> PMT,SDT lesen -> Neuer Sender

PAT lesen, wenn "NIT ID, STREAM Id, SERVICE Pid" keine Änderung -> PMT,SDT lesen -> Eventuell Sender updaten

PAT lesen, wenn "NIT ID, STREAM Id, SERVICE Pid" ein PID weg -> Sender nicht mehr vorhanden -> löschen (option)

 

Weil man mit mehreren Satelliten und Frequenzen arbeitet sollte man auch Position, Frequenz ,Polarität als Attribut dazunehmen um mit der Kanalliste vergleichen zu können.

 

Alle anderen Daten zum Sender sind variabel und sollten nicht zur Identifizierung eines Senders benutzt werden.

 

PMT ist gebunden an die Service ID und beinhaltet alle Pid's des Senders und können je nach Sendung ändern. (zb. ARD regional WDR,NDR usw.)

Transedit macht da zb. einen Fehler wenn die ARD abends die Pid's umschaltet. Transedit sieht die Sender dann als nicht vorhanden und legt sie neu an.

 

SDT ist auch an die Service ID gebunden und beinhaltet unter anderem: Verschluesselung, Sendername ...usw kann auch je nach Sendung ändern.

 

 

ps: Wäre toll wenn das mit Autoupdate im DVBViewer realisieren könnte.

[Moses]

Das Autoupdate gibt's schon längst im DVBViewer. Das einzige, was es nicht verändert, sind die Namen und das ist auch vollkommen ok so.

[Griga]

Dieses Programm hat eine abschaltbare Funktion mit der die PSI Tafeln (also die PAT) einmalig eingelesen wird

Die SI Tables bestehen aus wesentlich mehr als nur der PAT, wie du im TransEdit Analyzer sehen kannst. Lies mal die Anleitung. Glaubst du wirklich, du könntest Leuten, die sowas wie den Analyzer bauen, etwas vom Pferd erzählen? Den Analyzer solltest du auf jeden Fall genauer erforschen. Der zeigt dir sogar Streams, die nicht in der PAT/PMT stehen, weil der Anbieter nicht will, dass sie ein herkömmlicher Scanner findet. Oder nicht als das, was sie wirklich sind. Beispiel: H.264 Video von ITV HD auf Astra 28° Ost. Versteckt als Private PES. Der Analyzer merkt trotzdem, dass Video drin ist.

 

Neue Sender wurden automatisch gefunden,

...und in die Kanalliste eingefügt? Gott bewahre. Einmal radio top40 eingeschaltet, und schon hat man den ganzen Schrott von Lustkanal TV über Uschis Schwestern bis Manneskraft TV in der Liste (*schüttel*).

 

Einen kompletten Sender Scan war dadurch unnötig

Und wenn Sender wie arte HD auf einem neuen Transponder erscheinen, was dann? Musst du doch wieder scannen... und der Receiver die NIT lesen, sonst weiß er gar nicht, dass es dort etwas zum Scannen gibt.

 

Die PAT ist die Referenz und hat alle nötigen Informationen.

Nö. Die ONID gibt's nicht in der PAT, sondern in der SDT. Leider wurde relativ spät damit begonnen, sie im DVBViewer zu erfassen, und bevor sie kompatibel benutzbar ist, muss man eine entsprechende "Durchseuchung" der Anwender-Kanallisten abwarten (an sowas denken Theoretiker nie). Aber so langsam könnte man mal, anstatt so Krücken wie DiSEqC zur Unterscheidung verschiedener Sat-Positionen zu verwenden.

 

Transedit macht da zb. einen Fehler wenn die ARD abends die Pid's umschaltet.

Nö. Fehler ist nur, wenn das Programm was anderes als vorgesehen macht. Du hast die Intention hinter der Wiedererkennung nicht verstanden. Es sollen nicht Sender nach einem Ja/Nein-Schema identifiziert werden, sondern Abweichungen zwischen den Scanergebnissen und der Kanalliste deutlich werden, auch bei einzelnen Parametern. Das hätte dir bei sorgfältiger Betrachtung der Anzeige im Scannerfenster auffallen müssen. Die Auswirkungen der ARD-Lokal-Umschaltungen sind dabei ein unvermeidlicher Kollateralschaden.

 

Bei jedem DVBViewer GE-Update sind Komplettscans fällig, um die Standard-Sat-Kanalliste auf den aktuellen Stand zu bringen. Dabei sehe ich immer X Sender, bei denen sich die PMT PID oder gar die Service ID geändert hat. Letzteres ist besonders schlecht, weil dann der Kanal Auto-Update im DVBViewer nicht greift, der neben der Netzwerk/Transponder-Zugehörigkeit die SID als Anker verwendet. TransEdit erkennt solche Sender trotzdem wieder und zeigt das Manko an.

 

Ehrlich gesagt hat mir bei diesen Updates auch schon eine Funktion gefehlt, die Karteileichen erkennt. Deshalb denke ich gerade über ein Konzept für eine Realisierung in TransEdit nach. Dabei ist wesentlich mehr zu berücksichtigen, als sich Möchtegern-DVB-Spezialisten vorstellen können... letztendlich soll es unter verschiedensten Umständen in der Praxis funktionieren, nicht nur auf dem Papier.

[Flepp]

@Griga

 

 

Die SI Tables bestehen aus wesentlich mehr als nur der PAT, wie du im TransEdit Analyzer sehen kannst. Lies mal die Anleitung. Glaubst du wirklich, du könntest Leuten, die sowas wie den Analyzer bauen, etwas vom Pferd erzählen? Den Analyzer solltest du auf jeden Fall genauer erforschen. Der zeigt dir sogar Streams, die nicht in der PAT/PMT stehen, weil der Anbieter nicht will, dass sie ein herkömmlicher Scanner findet. Oder nicht als das, was sie wirklich sind. Beispiel: H.264 Video von ITV HD auf Astra 28° Ost. Versteckt als Private PES. Der Analyzer merkt trotzdem, dass Video drin ist.

 

Transedit ist eine wunderbare Entwicklung und bin sowieso total begeistert über dessen Entwicklung und seiner Analyser Funktion. Hut ab. PAT habe ich nur erwähnt weil ich nicht weiss was noch in der Kanalliste zum Vergleich vorhanden ist. Wusste nicht dass ONID auch noch drinnen ist.

 

Und wenn Sender wie arte HD auf einem neuen Transponder erscheinen, was dann? Musst du doch wieder scannen... und der Receiver die NIT lesen, sonst weiß er gar nicht, dass es dort etwas zum Scannen gibt.

 

Weichen wir doch nicht vom Thema ab. Zuschaltbare NIT Ist doch schon wunderbar in Transedit gelöst. Würde nur noch die duch [X] gekennzeichneten Transponders auch in der Kanalliste löschen (option)

 

Nö. Fehler ist nur, wenn das Programm was anderes als vorgesehen macht. Du hast die Intention hinter der Wiedererkennung nicht verstanden. Es sollen nicht Sender nach einem Ja/Nein-Schema identifiziert werden, sondern Abweichungen zwischen den Scanergebnissen und der Kanalliste deutlich werden, auch bei einzelnen Parametern. Das hätte dir bei sorgfältiger Betrachtung der Anzeige im Scannerfenster auffallen müssen. Die Auswirkungen der ARD-Lokal-Umschaltungen sind dabei ein unvermeidlicher Kollateralschaden.

 

Und hier ist genau der Ansatz. Man braucht beides. Karteileichen sollten nach einem Ja/nein Schema identifiziert werden. Am besten durch Auswählbare Pid's. Im Prinzip ist es die Herkunft des Senders bis zu seiner Service ID.Zur Wiedererkennung kann man die Program Pid's mit heranziehen. Die Wiedererkennung funktioniert in Transedit nicht wenn Audio Pid's und Video Pid's ändern egal welche Treshold ich einstelle. Autoupdate macht das wunderbar solange SID ok ist.

 

Letzteres ist besonders schlecht, weil dann der Kanal Auto-Update im DVBViewer nicht greift, der neben der Netzwerk/Transponder-Zugehörigkeit die SID als Anker verwendet.

 

Das ist auch richtig so. Der Sender ist Virtuel Tod auch wenn noch Program Pid's vorhanden sind. In einer Set-top Box würde er wahrscheinlich nicht mehr Funktionieren. Man kann ihn durch Wiedererkennungs Algorythmen neu beleben aber warum nicht löschen und mit der neuen Service ID neu einlesen ?

 

Dabei ist wesentlich mehr zu berücksichtigen, als sich Möchtegern-DVB-Spezialisten vorstellen können... letztendlich soll es unter verschiedensten Umständen in der Praxis funktionieren, nicht nur auf dem Papier.

 

Bin zwar kein DVB-T Spezialist habe jedoch langjährige IT Erfahrung und habe auch schon zu Analog Zeiten einige

Aufschaltungen bei Astra selbst durchgeführt. Habe vor einigen Jahren auch mit Christian mit einigen SQL Beispielen zur Entwickling der importmdb beigetragen. Mein Lebenslauf ist doch hier unwichtig.

Als begeisterter DX-er möchte hier nur eine Brainstorm Session eröffnen um dieses "Karteileichen" Problem zu beseitigen. Bin aber auch gerne bereit mich belehren zu lassen wenn mein Denk Ansatz falsch liegt.

 

 

Viele Grüsse

[Griga]

Die Wiedererkennung funktioniert in Transedit nicht wenn Audio Pid's und Video Pid's ändern egal welche Treshold ich einstelle.

Wie in der Anleitung steht, ist die Audo PID (neben Frequenz/Polarisation und Symbolrate) ein "must match" Parameter, da sonst die Zuordnung von Audiospur-Einträgen zu unsicher würde, die sich nur durch die Audio PID unterscheiden. Auf die Video PID trifft das nicht zu.

 

In Zukunft wird die Audio PID wahrscheinlich nur noch als Pflichtparameter verwendet, wenn das Scanergebnis mehr als eine Audiospur aufweist. Weiterhin wird die ONID (aus der SDT) im Scannerfenster angezeigt und für den Vergleich herangezogen. Dafür fällt die PCR PID aus der Zählung der übereinstimmenden Merkmale heraus. Bei einer ARD-Lokalumschaltung, die zu einer abweichenden Audio-, Video- und PCR-PID führt, gibt es so noch 8 übereinstimmende Merkmale. Mit einem entsprechenden Schwellwert wird der Sender dann als "bereits vorhanden" angesehen, vorausgesetzt, dass nicht ein weiteres in der Wertung verwendetes Merkmal abweicht (z.B. der Name), und der Sender nur eine Audiospur hat.

 

Die Löschfunktion wird nicht vollautomatisch arbeiten, auch nicht optional. Es wird ein Fenster mit einer Liste geben, die *vermutlich* tote Sender aufzählt. Selektion und Löschen müssen darin manuell veranlasst werden. Ebenso wie schon jetzt im Scannerfenster das Hinzufügen/Aktualisieren von Sendern. TransEdit legt nicht von sich aus neue Sender in der Kanalliste an, wie du fälschlich behauptet hast.

[Flepp]

Dafür fällt die PCR PID aus der Zählung der übereinstimmenden Merkmale heraus. Bei einer ARD-Lokalumschaltung, die zu einer abweichenden Audio-, Video- und PCR-PID führt, gibt es so noch 8 übereinstimmende Merkmale. Mit einem entsprechenden Schwellwert wird der Sender dann als "bereits vorhanden" angesehen, vorausgesetzt, dass nicht ein weiteres in der Wertung verwendetes Merkmal abweicht (z.B. der Name), und der Sender nur eine Audiospur hat.

 

Super der Stein kommt ins Rollen.

 

Hier wirklich ein ganz Simpler Denkansatz und es sollte funktionieren.

 

Wenn die Reihenfolge der übereinstimmende Merkmale so definiert wird (oder einstellbar) sollte es Funktionieren.

 

1. Frequenz- H/V (Pflicht)

2. SR (Pflicht)

3. ONID (Pflicht)

4. TID (Pflicht)

5. SID (Pflicht)

6. PMT (Über Treshold Einstellbar)

7. APID (Über Treshold Einstellbar)

8. VPID (Über Treshold Einstellbar)

9. PCR (Über Treshold Einstellbar)

10. SENDERNAME (Über Treshold Einstellbar)

11. TPID (Über Treshold Einstellbar)

 

Persönlich würde ich die Treshold dann auf 6 setzen alle anderen Pid's würden dann als Änderung erkannt werden.

[Griga]

3. ONID (Pflicht)

4. TID (Pflicht)

5. SID (Pflicht)

Habe ich nicht vor, da ich dann im Scannerfenster nicht sehen kann, ob einer dieser Werte bei einem Sender der Kanalliste im Vergleich zu den Scanergebnissen abweicht.

 

Ein Problem ist die Erkennung von Kanallisten-Einträgen, die sich auf abgeschalteten oder sonstwie ergebnislosen Transpondern befanden. Grundsätzlich würde die Erkennung erfordern, dass solche Transponder gescannt werden, auch wenn es erfolglos ist, weil die Mechanismen für den Abgleich mit der Kanalliste im Scanner implementiert sind. Aber auch dann habe ich nur in der Transponderliste verzeichnete Parameter, also Frequenz, Polarisation, Symbolrate, FEC, DiSEqC usw., jedoch keine ONID oder TID, die ja erst ein erfolgreicher Scan liefert. Kurz gesagt eine sehr schwache Basis, um einen Kanallisten-Eintrag einem solchen Transponder zuzuordnen.

 

Die Aufgabe einer Transponderliste beschränkt sich halt darauf, die Parameter zu liefern, die DVB-Geräte brauchen, um Transponder zu tunen. ONID, TID, SID oder irgendwelche PIDs gehören nicht dazu.

[Darwin]

Mir scheint sich die ursprüngliche Frage nach einer kurzfristig zu realisierenen Lösung in eine Diskussion des (sicherlich begrüßenswerten) neuen Konzeptentwurfs weiterzuentwickeln. Ich habe für meine - etwas anders motivierte - Lösung eines quasi selbstpflegenden Bestandes, schonmal an eine Art Bewährungssystem gedacht:

 

Es wird nicht direkt gelöscht, sondern beim Scan ein Bewährungscounter für den ausgewählten Bereich mitgeführt.

Alle Services des zu scannenden Bereichs => Bewährung++

Beim Scan wiedergefunden => Bewährung=0

 

+ Eine Config-Property "automatisch Löschen ab Bewährungsstufe x"

 

+ Ein zusätzliches Selektionskriterium "Bewährung" [stufe|Stufe von..bis|Alle] in der Senderliste und dem Senderlisten Editor.

Im Editor kann ja dann die Löschung der selektierten Gruppe und Einzelservices - und/oder das Rücksetzen des Counters - erfolgen.

 

 

Das setzt - nach dem Vorgesagten - vielleicht die zusätzliche Übergabe des im Scanbereich vorhandenen 'Vergleichs'-Bestandes an den Scanner voraus. (Inklusive der in der Vergleichsmenge vorhanden "Altlasten" bei Transponderabschaltungen)

Aber es geht ja dann um neue Konzepte...

Edited September 28, 2008 by Darwin