Verlust von Root-Ordnern: Zufall oder Bug?

[Darwin]

Ein seltsames Verhalten in der Service-Verwaltung bringt mir ab und zu Mehrarbeit.

 

Nachdem es mir in dem halben Jahr Nutzung nun zum vierten oder fünften Mal passiert ist, wollte ich mal nach anderen User mit ähnlichen Problemen suchen.

Da solche sporadisch auftretenden Mucken schlecht reproduziert werden können - zumal dann wenn sie erst bei einem späteren Neustart des Programm konkret auftreten - will ich da erstmal kein 'Problem' draus machen. (Daher auch noch kein 'Korrektes Posten' )

 

Folgende Situation:

TT S2 3200, DVBV - Pro, WindowsXP

Je einen Rootordner für verschiedene Satelliten. Im Moment nur per USALS angesteuert, frühere 'Ereignisse' dieser Art waren aber auch bei meinen normalen "Einstellung": Astra/Hotbird per MS (Gruppe A) der Rest über OptB per USALS (Gruppe B ).

Zusätzlich zu Beginn einen Rootordner "Stamm" in dem ich satellitenübergreifend Service-Kopien mit 'meinen' Programm Nummern verwalte. (zum Beispiel Services zum schnellen Satellitenwechsel über dort einzeln anpassbare DiSEqC-Kommandosequenzen und sonstige Tests wie man Redundanzen ausnutzt. )

 

Dazu müsste ich noch erwähnern, daß die aktuelle Beta in einem anderen Directory ist, allerdings auf das gleiche Konfigurationsverzeichnis gesetzt ist, also mit den gleichen Settings arbeitet. Ich schalte auch ziemlich wahlfrei zwischen den beiden Versionen hin und her, je nachdem welches Icon gerade im Maus-Weg liegt. Das o.g. Verhalten ist auch aufgetaucht wenn keinelei Betasachen installiert waren.

 

Jetzt habe ich das erste Mal einen möglichen Ansatzpunkt:

Im Rootordner von Eurobird 9 waren die Services von MelodyZen zweifach - auf verschiedenen Transpondern - vorhanden.

Die Favoriten-Datei wurde nach der Neuaufschaltung mit dem zweiten Eintrag (höhere Frequenz 11804) erzeugt.

Vorgestern habe ich einen Suchlauf auf Eutelsat W1 10.0E durchgeführt und im integrierten Editor den Rootordner vor Eurobird 9 geschoben, weil ich eine Anordnung von links (E) nach rechts (W) bevorzuge. Danach war noch Alles wie immer. Auch nach mehreren Neustarts null Probleme.

Gestern dann einen Suchlauf auf Sirius (mit zwischenzeitlicher Aktualisierung/Überarbeitung der .ini durch TransEdit).

Nach dem Suchlauf war gestern normaler Betrieb.

 

Heute jedoch, nach dem ersten Start von DVBViewer, war ab Eutelsat W1 (inklusive) die Kanalliste in Richtung Westen (EBird9, Sirius, Thor... Hispasat) komplett abgeschnitten.

Bei einem neuerlichen Suchlauf auf 9.0 E stelle ich fest, daß die 'alten' MelodyZen-Services nicht mehr auftauchen, also auf der alten Fequenz abgeschaltet wurden.

Von Hotbird waren allerdings - im weiterhin vorhandenen RootOrdner 'Hotbird' - auch nur noch 366 Services zu sehen.

 

Da ich nun nicht weiß, wie bei einem Suchlauf die Aktualisierung der bestehenden Services programmiert ist und auch die Anzahl der Services hier bei mir nicht gerade im Bereich unter 2000 liegt, würde ich da - bei der Löschung abgeschalteter Services ? - eventuell einen Knackpunkt vermuten. Sowas ist häufig ein Grund für unbehandelte NirwanaZeiger oder unbeabsichtigte EndOfStructure-Bedingungen beim erneuten Einlesen zum nächsten Programmstart. (In frühen Beta-Versionen der TripleDragon-Firm gab's sowas auch mal)

 

Eine andere Möglichkeit könnte auch durch die angesprochene Verschiebung - und den später anschließenden Sirius Suchlauf - im internen Editor passiert sein. Wenn ich mich recht entsinne, hatte ich dieses Verhalten ganz zu Anfang auch schon einmal nach einer Verschiebung der Ordner im externen Editor. (den ich seitdem auch nicht mehr benutze)

 

Falls das also noch Niemand beobachtet hat und auch die Leute mit Sourcen-Zugriff da keinen direkten Einfall haben, werde ich das einfach weiter im 'Auge' behalten.

 

Da die Favoriten ja nicht mitaktualisiert werden , hält sich die Arbeit dann dank Importfunktion doch in Grenzen...

Edited July 17, 2008 by Darwin

[Lars_MQ]

bei der Löschung abgeschalteter Services ?

Es wird niemals bei scannen gelöscht. Wenn was nicht sendet, gammelt es in der senderliste vor sich hin, bis der nutzer sich erbarmt und den kram löscht

Ansonsten, sollte es fehler beim verschieben von ordnern geben, treten sie sofort beim nächsten start zutage und nicht erst "2 wochen" später

 

Sollte es zu einem unerlaubten speicherzugriff kommen, wird ene entsprechende exception ausgelöst und in der DVBViewer.log (im konfigurationsordner) protokolliert. Sollte dort etwas stehen, was zeitlich zu Deinem Problem passt, hätten wir einen ersten ansatzpunkt.

[Darwin]

15.07.2008 08:54:15 EAccessViolation raised by instance frmMain of class TfrmMain at 0040A081:Zugriffsverletzung bei Adresse 0040A081 in Modul 'DVBViewer.exe'. Schreiben von Adresse 00000000

Das wäre der einzige Eintrag vom vorgestrigen Tag.

Der letzte Sirius Scan war nach dem Timestamp der INI um 11:42

 

Gestern und Heute kein weiterer Eintrag!

 

Davor dieser:

12.07.2008 13:25:39 EAccessViolation raised by instance frmMain of class TfrmMain at 006B9F79:Zugriffsverletzung bei Adresse 006B9F79 in Modul 'DVBViewer.exe'. Lesen von Adresse 0000003A

 

Das könnte mit dem Scan von Eutelsat W1 zusammentreffen. Die aktuelle Ini-Datei 0100.ini datiert auf 12.07.2008 13:47

Dieser letzte Suchlauf auf W1 könnte allerdings auch erst nach der Verschiebeoperation vor Eurobird 9 stattgefunden haben.

 

Aber wie gesagt,

[Darwin]

Ich habe eben mal begonnen, die channels.dat in eine mir genehme XML-Struktur zu transferrieren.

Dabei ist mir aufgefallen, daß intern die Services weder nach dem Rootbegriff noch nach der Gruppe sortiert werden, sondern - so wie es aussieht - bei einem neuerlichen Scan einfach hinten an den Bestand angehängt werden.

 

Abgesehen von evtl. zu erwartenden Performance-Verlusten beim Zappen könnte da auch leicht ein Knoten in möglicherweise zu bildende Indexdateien geraten. Was auch den oben angesprochenen Teilverlust von Hotbird-Services erklären könnte. Die lagen halt durch einen späteren AktualisierungsScan hinter der 'Bruchstelle'

[Lars_MQ]

die kanäle werden in genau der reihenfolge abgelegt, wie sie in der Kanalliste stehen. Unterkanäle (audiospuren) werden auch als kanal abgelegt. Die daten sind damit automatisch nach root und nach category gespeichert.

 

Es gibt keine indexdateien und auch keine Performance verluste.

[Darwin]

MMmmmhhmmm, angewandt auf die aktuelle channels.dat

per sequenziellem Lesen

	  
  DataSet dsFile = new DataSet("DVBV");
  DataTable dtDS = dsFile.Tables.Add("DS");
  .....
  while (fs.Position < fs.Length) {
	aTunerBuffer = rTChannels.ReadBytes(0x0034);
	aServiceBuffer = rTChannels.ReadBytes(0x050);
	DataRow drRead = dtDS.NewRow();
	 ....
	drRead["usrRoot"]=rName;
	drRead["sName"]=sName;
	drRead["sCatName"]=pName;
	...
	dtDS.Rows.Add(drRead);
  }
  fs.Close();
  dsFile.WriteXml(tmpDataPath + "dvbvSDB.xml");

 

ergibt das XML aus dem Anhang.

(Die im Zusammenhang eher unwichtigen Daten habe ich mal weggelassen)

 

im hinteren Teil =>

Hotbird Rest Services (von vor dem Cut) Gruppe A und Root Hotbird

Dann Scan Thor und EBird 9 (nach dem Cut) Gruppe B und Root Thor & EBird 9

Danach Ergänzungsscan Hotbird (nach dem Cut und nach Eurobird 9) Gruppe A Root Hotbird.

 

Daß nur ein einziger Hotbird-Eintrag in der zusammgeklappten Senderliste ist, glaubst Du mir hoffentlich ohne einen Screenshot!

 

 

Puuhhh, ich habe mal wieder die Ausnahme...

dvbvSDB.zip

Edited July 18, 2008 by Darwin

[Lars_MQ]

Ich sehe da keinen fehler. Das wird auch die reihenfolge sein, wie die kanäle in der kanalliste stehen. Im senderlisten fenster mag das anders aussehen, aber das sind generierte ansichten, die nicht zwangsläufig die darunterliegende kanalliste widerspiegeln.

 

mach das senderlisten fenster auf, deaktiviere alle filter und sortierungen und lass sie anzeigen nach sat/kategorie. Dann blende die Sendernummern ein, da siehst du die reihenfolge.

[Darwin]

Die daten sind damit automatisch nach root und nach category gespeichert

Das können wir ja dann ad acta legen.

 

das sind generierte ansichten

Damit wären wir dann doch irgendwie bei - teilweise mehrstufiger - Indizierungen unsortierter Datenbestände.

 

Ohne auf Performance-Verluste beim Aufbau der Ansichten weiter eingehen zu wollen, stellt sich dann die Frage, nach welchen Kriterien die Anwendung die channels.dat bei der Beendigung des Viewers wegschreibt.

Da bei eingeschaltetem Sender-AutoUpdate nicht nur bestehende Sätze aktualisiert sondern auch z.B. durch zusätzliche 'AudioFeed-Clone' Änderungen in der Menge stattfinden müssten, ist dieses Wegschreiben ja auch erforderlich. Im Arbeitsspeicher der Anwendung existiert eine per Indizierung geordnete oder sonstwie sortierte Senderliste (mit den Satznummern der channels.dat als Referenz in die Datei), auf der Platte liegt diese nach Bedarf immer weiter 'verlängerte' Liste.

Wird ein neu ermittelter Audio-Subfeed nun als tChannel ans Ende der Liste gehängt, oder wird er direkt hinter seinem "Stammservice" geclont und dort einsortiert, was dann eine Neunummerierung der nachfolgenden tChannel-Sätze bedeuten würde? Wird nach der Satz-Nummerierung weggeschrieben oder nach der Reihenfolge der gewählten Ansicht?

 

Wie auch immer: Hier liegt erfahrungsgemäß viel Fehlerpotential. Zudem noch nichtmal ein normalisierter Datenbestand zugrunde liegt.

 

 

Da ich aber anscheinend der einzige Betroffene bin, sollte man die Priorität hier klein halten und eventuell freie Energie besser in eine zeitgemäße Settingsverwaltung stecken...

 

 

Wie gesagt, ich werde das Problem mal locker im Auge behalten und entweder reproduzierbar oder erklärbar machen.

[Lars_MQ]

Audio subchannel werden dem hauptchannel direkt untergeordnet, sie müssen in der dat zwingend direkt hinter dem hauptchannel liegen. Die nummerierung ist dadurch nicht betroffen, da audiochannel immer dem hauptchannel untergeordnet sind. Das ganze ist intern etwas komplizierter, da wir immer noch auf einer datenstruktur aus den anfangstagen des viewer rumjuckeln (gelobet sei die kompatibilität).

 

Und tatsächlich treten starke performance verluste auf. Aber ich bezweifle, das Du sie jemals erreichen wirst. Wir kriegen Probleme bei kanallisten mit 100.000+ hauptkanälen, zumindest auf meinem athlon xp 2000+, da braucht er mehr als 250ms für die sortierung der Liste im senderlistenfenster. ärgerlich aber das nehme ich billigend in kauf...

 

Ich denke, die performance lässt Du besser meine sorge sein, solange Du nicht genau weiss, was da hinter den kulissen passiert.

[Darwin]

lässt Du besser meine sorge sein

Solange Ihr nicht auf Delphi.NET und 'Sprachunabhängigkeit' umsteigt, werde ich die mit Sicherheit nicht teilen wollen.

 

Ansonsten ist die S2-3200 mit DVBViewer und vor allem TransEdit !! für mich eher ein Werkzeug (und Spielzeug).

Für familientaugliche ExtremZap-Anwendungen habe ich ausreichend andere DVB-Hardware. (mit unterschiedlichster Performance )

 

 

Ich werde jetzt erstmal den oben begonnen Parser auf das nach meiner Meinung wesentliche Datenmaterial beschränken und per Batch einbinden.

So werde ich beim nächsten Cut zumindestens die 'Bruch'-Stelle schnell ermitteln können.

 

 

 

p.s.

gelobet sei die kompatibilität

Solange Niemand aus dem Kompatibilitäts-Pool (unerlaubterweise) direkt auf die Struturen der channels.dat zugreift, würde ich in diesem Zusammenhang einfach zwei 'Interfaces'-Versionen implementieren um die tatsächliche Datenstruktur vom Aufruf zu entkoppeln. Ich denke, das sollte in einer überarbeiteten, neuen Version machbar sein. (Delphi wird es wohl können !?!)

[Derrick]

Das ganze ist intern etwas komplizierter, da wir immer noch auf einer datenstruktur aus den anfangstagen des viewer rumjuckeln (gelobet sei die kompatibilität).

Was sollen das für kompatibilitätsprobleme sein? Wer probleme postet, wird doch zunächst aufgefordert, die letzte version zu installieren und alte gibt es offiziell gar nicht zum download.

 

..solange Du nicht genau weiss, was da hinter den kulissen passiert.

..steht im widerspruch zum ersten zitat, da dort zugegeben wird, dass veraltetes zeuchs unter der haube steckt

[Lars_MQ]

a. dvbservice, GE, sämtliche plugns die irgendwie auf dietuner struktur zurückgreifen, das COM interface etc.

 

b. Alt heisst nicht, das dort keine hochoptimierten und komplexen vorgänge vorhanden sind. Nur weil Du etwas nicht verstehst, ist es noch lange kein widerspruch.

 

Das fällt insgesamt unter de Kategorie: Solche vor unkenntnis strotzenden kommentare sollten definitiv nicht von einem Moderator kommen...

[Derrick]

b. Alt heisst nicht, das dort keine hochoptimierten und komplexen vorgänge vorhanden sind.

..die aber anscheinend die grundlegende schwäche nicht kompensieren können. Das thema ist doch schon sooo alt. Meine kritik ist seit jahren dieselbe. Ansonsten meine ich, schon einiges in sachen dvb bewegt zu haben. An settings und verwandtem (diseqc z.b.) beisst man sich hier aber die zähne aus

[Darwin]

Ich für meinen Teil kann mir ja vielleicht doch vorstellen, was da 'hinter den Kulissen' abläuft (oder besser: Auf Grund der während der Zeit erforderlichen 'unvorhergesehenen' Nachbesserungen ablaufen dürfte).

Was ich auf keinen Fall möchte, ist eine mE nutzlose Grundsatzdiskussion zu bestehendem und übereinstimmend als unzureichend erkanntem Bestand.

 

Nach der Erwähnung einer neuen DVBViewer-Generation wäre es mir aber Anliegen, diesen Komplex für diese 'Zukunfts-Ausgabe' dann etwas anders gestaltet, sprich aus heutigen Erkenntnissen und Möglichkeiten völlig neu konzipiert zu sehen.

 

Damit sollten wir irgendwie wieder zu dem ursprünglichen Problem mit den 'abgeschnittenen Senderlisten" zurückkehren...

[Darwin]

Inzwischen habe ich bei der täglichen - noch manuellen - 'Kontrolle' zwei 'fremdangelegte' Root-Ordner gefunden.

Mein Rootordner für Hotbird heißt 'Hotbird'

 

Es gab wie von Zauberhand einen Ordner "Hotb_rd" und einen Ordner "Hotbir_" (Der Unterstrich soll ein dünn gerahmtes Quadrat darstellen).

In beiden Ordner waren offensichtlich einzelne automatisch 'aktualisierte' Services. Nach dem letzten Suchlauf waren sie jedenfalls noch nicht da.

 

Leider habe ich die vor der Analyse (s.u.) im internen Editor gelöscht um die Wirkung davon zu ermitteln. So kann ich nix zum charcode dieses Zeichens sagen. Und der 'erwartete' Cut fand leider auch nicht statt. Im Log waren auch keine neuen Einträge.

Werde das beim nächsten Auftreten dann genauer analysieren.

 

Inzwischen bin ich mit der Umsetzung Channels.dat -> XML in einer Plain-Version durch.

Ich will als nächstes versuchen, die Terme verschiedenen Systembereichen (DVB, Equipment, User ...) logisch zuzuordnen.

Da hätte ich ein paar Unklarheiten bezgl. der angegebenen Struktur ( http://www.DVBViewer.info/forum/index.php?...mp;#entry191642 ) und deren Verwendung in der Anwendung.

 

Die Terme:

 

Volume : Byte

Audiochannel : Byte

NetworkNr : Byte

Favourite : Byte

 

lassen vom Namen her ahnen wofür sie sind, sind aber hier nach der Wandlung durchgängig gleich Null

 

Gibt es da eine weitergehende Erläuterung zu, die ich noch nicht gefunden habe?

Sind das hardwareabhängige Sachen die hier (TT S2 3200) nicht genutzt werden oder für andere "Anwendungen" (z.B. GE) oder für andere Systeme (C, T) oder sind die für vorerst noch geplante Features gedacht und derzeit noch unbenutzt?

 

In der (älteren) Strukturbeschreibung "ChannelFormat.txt" aus dem DL sind die nicht enthalten.

Edited July 24, 2008 by Darwin

[Darwin]

Leider habe ich die vor der Analyse (s.u.) im internen Editor gelöscht um die Wirkung davon zu ermitteln. So kann ich nix zum charcode dieses Zeichens sagen. Und der 'erwartete' Cut fand leider auch nicht statt. Im Log waren auch keine neuen Einträge.

Werde das beim nächsten Auftreten dann genauer analysieren.

 

Da ist es wieder passiert:

48 6F 00 62 69 72 64 "Ho.bird"

Es ist ein Nullbyte.

Daraus wird der neue Rootordner (mit dem Kästchen als Nullbyte-Übersetzung von WinXP) generiert.

 

 

Es ist nicht von einem Hotbird-Suchlauf, sondern aus dem vorher 'sauberen' und sortierten Bestand. (da steht definitiv ein 0x74)

<DS DSType="S" eqGroup="A" tFreq="12379" tSR="27500" eqLOF="10600" sPMT="0BC7" ... tNWID="013E" sSID="0BBD" sPCR="0BD1" usrRoot="Hotbird" sName="ALBAGHDADIA" sCatName="GlobeCast" />
<DS DSType="S" eqGroup="A" tFreq="12379" tSR="27500" eqLOF="10600" sPMT="0BC9" ... tNWID="013E" sSID="0BBF" sPCR="0BD3" usrRoot="Hobird" sName="Telepace" sCatName="GlobeCast" />
<DS DSType="S" eqGroup="A" tFreq="12379" tSR="27500" eqLOF="10600" sPMT="0BC9" ... tNWID="013E" sSID="0BBF" sPCR="0BD3" usrRoot="Hobird" sName="Telepace (1)" sCatName="GlobeCast" />
<DS DSType="S" eqGroup="A" tFreq="12379" tSR="27500" eqLOF="10600" sPMT="0C26" ... tNWID="013E" sSID="0BC2" sPCR="0C30" usrRoot="Hotbird" sName="Saudi arabia TV2" sCatName="GlobeCast" />

 

 

Gleichzeitig ergibt sich auch noch eine Frage bzgl. der Gruppe.

Ich denke, das ist ein selektiver Schalter.

Ich verwende ihn z.B. um zwei Empfangseinrichtungen anzusteuern (Multischalterschüssel und Motorschüssel).

Von Anderen habe ich in der Mehrzahl gelesen, daß sie die Gruppe verwenden um verschiedene 'Receiver' zu gruppieren.

Da das 'unterschiedliche Seiten' eines solchen Schalters (Empfangseinrichtung aus der Signalrichtung davor und 'Receiver/DVB-Karte' dahinter) anspricht, wäre mir wichtig, wie der Algo das sieht...

[Darwin]

Nachdem ich mit dem internen Settingseditor einige Services aktualisiert habe, war mal wieder Schicht!

 

Bruchstelle: Der erste Hotbird-RootOrdner mit dem Nullbyte! (Ist jetzt noch vorhanden)

Ab dem zweiten verhuddelten Root-Ordner war wieder alles weg: diesmal Eurobird 9 und Thor.

 

Wer ist für die Nullbytes verantwortlich und wer für den nachfolgenden Cut ?

[Darwin]

Nach zwei weiteren Zwangsverkleinerungen habe ich die automatische Senderaktualisierung mal ausgeschaltet!

 

Gestern war Alles okay!

 

Heute - Rechner war aus in der Nacht - folgende völlig neue, vorher nie gesehen Senderlisten - Einträge!

(man beachte auch die Frequenzen )

[Griga]

Gleichzeitig ergibt sich auch noch eine Frage bzgl. der Gruppe.

Die Gruppe ist einfach eine Eigenschaft des Senders, wie die Frequenz und andere Daten auch (ein Byte in der Struktur mit Senderdaten). Nur wird sie allein manuell durch den Anwender gesetzt, also nicht durch automatische Vorgänge. Zur Auswirkung kommt sie nur, wenn ein Sender eingeschaltet wird, weil der DVBViewer dann die Gruppe des Senders mit den einem Gerät zugeordneten Gruppen (in Delphi: set of TChannelGroup) vergleicht, um herauszufinden, welches Gerät diesen Sender kann:

 

if Channel.Group in Device.Groups then //Gerät passt

 

Sonst ist da nichts dran.

 

Was bei dir offensichtlich ist: Irgendwas schreibt unqualifiziert in deinen Kanaldaten herum. Das kann, muss aber nicht DVBViewer-Code sein. Jede DLL und jeder DirectShow-Filter innerhalb des DVBViewer-Prozesses kann das mit einem verunglückten Pointer bewerkstelligen, ohne dass es zu einer Zugriffsverletzung kommt, da es sich ja um Speicher handelt, der dem DVBViewer zugewiesen ist. Die Ursache solcher Probleme ist sehr schwer zu ermitteln.

 

Derrick hat sowas schon mal erlebt - da fand der TSPlayer sporadisch das IGraphBuilder-Interface nicht mehr. Eine grundlegende Sache bei DirectShow, die nicht so einfach verschwindet. Einzige mögliche Erklärung: Irgendwas hat die im TSPlayer als typisierte Konstante gespeicherte ClassID (CLSID bzw. GUID) des Interfaces kaputtgeschrieben, so dass das Programm eine Schrott-CLSID verwendete, die keinem Interface entsprach. Eine typisierte Konstante ist eine verkappte globale Variable, bei der der Compiler meckert, wenn man Schreibzugriffe versucht. Zur Laufzeit interessiert das jedoch niemand, weil kein Compiler mehr da ist, der aufpasst. Als vermutlich Schuldiger erwies sich ein InterVideo Decoder. Nach Einstellen eines anderen Decoders war Ruhe.

 

Solche Fehler sind äußerst tückisch, da eine amoklaufende Komponente je nach Situation im Speicher etwas kaputtschreiben kann, was sofort auffällt, oder etwas anderes, das man nie benutzt. Das verhindert eine Reproduzierbarkeit, der man irgendwas entnehmen könnte.

[Derrick]

..aliens in der nacht?

 

2 kanäle wurden doch gefunden, mit welchen parametern?

[Darwin]

Jede DLL und jeder DirectShow-Filter innerhalb des DVBViewer-Prozesses kann das mit einem verunglückten Pointer bewerkstelligen

Klingt plausibel. Da ich in der Anfangszeit auch eine ganze Reihe von Sachen - mehr ohne wirklichen Plan von DirectX - ausprobiert habe, könnte das schon recht wahrscheinlich sein. Zumal jetzt auch zum ersten Mal wirklicher Müll drinsteht!

 

Dann werde ich bei nächster Gelegenheit mal das System komplett neu aufsetzen. (hatte ich eh bald vor)

 

mit welchen parametern

Habe ich nicht nachgeschaut.

Hatte Angst, ich könnte einen hochfrequenten Angriffsbefehl an die Invasionflotte hinter dem Mond absetzen

[Griga]

Wirklich in Frage kommen nur DirectShow Filter, die zum Zeitpunkt des Geschehens unter Ansicht -> Filter verzeichnet sind. Könnte aber wie gesagt auch was anderes sein, das der DVBViewer verwendet - ein anderer Prozess (sprich ein anderes laufendes Programm) kommt dagegen nicht in Frage.

 

Aufräumen ist jedenfalls nicht die schlechteste Idee. Dass es sich um einen Bug direkt in der Verwaltung der Senderliste handelt, glaube ich nicht. Dann wäre er schon mehrfach auf ähnliche Weise aufgefallen und besser reproduzierbar, also kurz gesagt ein "ordentlicher" Fehler (wenn wir schon Fehler machen, dann machen wir sie ordentlich ). Die Symptome sind jedoch typisch für Sabotage um drei Ecken rum, die von mehr oder weniger zufälligen Bedingungen abhängt.