Topf startet immer wieder

[brandse]

Den Artikel von "omue" hab ich durchgelesen. Das wäre natürlich auch eine logische Absturz-Ursache, der ich gerne nachgehen möchte.

Aber jetzt die "Gretchenfrage": wie kann ich einfach rausfinden, ob EPG-Kurzbeschreibungen >256 Zeichen vorkommen? Ich habe mal die .eit-Dateien vom Topfield gezogen, kann aber aus dem Dateiinhalt per Texteditor die EPG-Kurzbeschreibung schlecht extrahieren, weil so viele Sonderzeichen enthalten sind. Und ein brauchbares EPG-Analysetool für den Topf oder den PC hab ich gesucht, aber leider nicht gefunden. Hast Du einen Tipp?

Den von Dir vorgeschlagenen Ansatz mit der Lautstärke-Fragezeichen-Taste und dem abgezogenen HDMI-Kabel konnte ich leider (?) noch nicht ausprobieren, weil mein Topf bisher (noch) nicht abgestürzt ist... Ich melde mich aber, wann es wieder soweit ist!

Danke für die Hilfe!
Erik

[omue]

Beim Sat SRP 2401 ist beim Absturz immer der gesamte Transponder betroffen. Egal welches Programm ich aufrufe gibt es nach einiger Zeit einen reboot.
Wenn die Ursache die Gleiche ist sollte beim CRP alle Programme des Kabelkanals zum Reboot führen.
Kann man beim CRP eigentlich auch Kanäle mit manueller PID Suche suchen ?
Wenn ja dann das Programm wo er abstürzt einfach mit Manueller PID Suche ( nur Video und Audio Pid ) nochmal abspeichern. Dann ist auch der EPG weg. Wenn dann der Absturz weg ist ist es der EPG.

Das mit den >256 Zeichen habe ich mit einer PC TV Karte herausgefunden....

Olaf

[brandse]

Der letzte Absturz war bei einer Aufnahme vom Sender ARD-alpha. Der liegt auf Kanal S 35 und neben ARD-alpha gibt es hier noch ATV II, arte, PHOENIX, EinsExtra, Einsfestival und EinsPlus. Das ist unter anderem aus der technischen Programmübersicht des Kabelanbieters ersichtlich.

Eine manuelle PID-Suche nach Programmen kann ich beim Kabelreceiver meines Wissens nicht machen; ich kann aber gezielt nach Kanälen suchen (S 35 liegt z. B. bei 418 MHz, Symbolrate 6.900 Ks/s, 256 QAM).

Somit würden - wenn sich dieser Fehler bei CRP und SRP ähnlich auswirkt - alle Aufnahmen auf den oben genannten Sendern betroffen sein (falls in dieser Zeit eine EPG-Kurzbeschreibung > 256 Zeichen auftaucht).

Aber vermutlich wäre nicht nur das eine EPG dieses einen Senders auf diesen einen Kanal betroffen, sondern vielleicht auch andere Sender auf anderen Kanälen. Das herauszufinden ist wahrscheinlich schwierig und unter dem Strich wird es in der EPG-Programmübersicht künftig sehr finster werden...

Die wahrscheinlich beste Lösung für mich und vielleicht auch für andere wäre eine Behebung des Bugs in der Software - falls wir damit tatsächlich auf der richtigen Fährte sind...

Was es noch zu klären gilt: von welcher Software kommt der Bug eigentlich her? Von der Firmware oder von einem der TAPs? Ich könnte die TAPs erst mal aus Autostart nehmen und ein paar Tage ohne leben. Falls der Fehler immer noch auftritt liegt es vermutlich an der Firmware. Dann gilt es, alle Sender aus einzelnen Kanälen rauszulöschen und wieder abzuwarten. Das fühlt sich schon beim Schreiben grauslich an.

Die HDMI- und Lautstärke-Fragezeichen-Taste hab ich sicherheitshalber immer noch im Hinterkopf...

Grüße
Erik

[omue]

[quote="brandse"]
Was es noch zu klären gilt: von welcher Software kommt der Bug eigentlich her? Von der Firmware oder von einem der TAPs? Ich könnte die TAPs erst mal aus Autostart nehmen und ein paar Tage ohne leben. Falls der Fehler immer noch auftritt liegt es vermutlich an der Firmware. Dann gilt es, alle Sender aus einzelnen Kanälen rauszulöschen und wieder abzuwarten. Das fühlt sich schon beim Schreiben grauslich an.

Grüße
Erik[/quote]

Beim SRP ist es die Firmware ( die letzten 3 Versionen ), da der Reboot auch ohne TAP´s passiert.
Man kann es auch leicht testen, da es wenn die Texte kommen innerhalb einer Minute zum Reboot kommt.
Falls es beim CRP anders ist, ist der Fehler auch ein anderer....


Olaf

[Homer]

[quote="brandse"]Der letzte Absturz war bei einer Aufnahme vom Sender ARD-alpha.[/quote]Wenn du diese Teil-Aufnahme noch hast, kannst du mit TFTool die .rec oder .rec.inf auswählen. Dann findest du die Kurzbeschreibung nach dem Event-Namen und vor der Dauer. Möglicherweise stürzt der Topf ab, bevor er die Kurzbschreibung in die Aufnahme geschrieben hat. Dann könnte es helfen, wenn du sofort nach einem Absturz versuchst, die gleiche Sendung im Hintergrund aufzunehmen - also im Vordergrund einen anderen Transponder schaust.
Mit einer Debug-Version von SE könnte man beim EPG-Scan zu lange Kurzbeschreibungen ins Log eintragen.

Viele Grüße
Homer

[brandse]

Vielen Dank für die Hinweise!

Zum Thema Firmware von "omue": auf der Topfield-Seite für Firmware-Downloads hab ich nur die alte Version CRP2401_CONAX_v1.02.00_2013.12.18.tfd und die neue Version CRP2401_CONAX_04042014.tfd zur Auswahl. Für eine noch ältere hab ich leider keine andere Quelle gefunden (falls es für diesen Typ überhaupt eine ältere gibt). Beide hab ich ausprobiert, bei beiden tritt der Bug auf.

Zum Thema Aufnahme von "Homer": ich bin davon ausgegangen, der Topf nur dann abstürzt, falls irgendwo im EPG eine EPG-Kurzbeschreibung > 256 Zeichen vorkommt. Da lag ich wohl falsch.
Falls das tatsächlich so ist, dass der Absturz nur bei der aktuellen Aufnahme mit einer EPG-Kurzbeschreibung > 256 Zeichen passiert, dann kann ich das viel einfacher nachvollziehen: der Topf schreibt mir brav auch .rec und .rec.inf-Dateien für die kurzen Aufnahmedauern nach einem Reboot auf die Festplatte. Ich hab sie mir allerdings noch nicht genauer angesehen - bis jetzt. Das werde ich natürlich nachholen, sobald es wieder so weit ist und hier berichten.

Falls man mit einer Debug-Version von SE mehr rauslesen kann würde ich auch das gerne versuchen. Gibt es hierzu einen Eintrag, den ich z. B. in "SmartEPG_TMS.ini" setzten kann? Wird das dann in die "SmartEPG_TMS.log" reingeschrieben?

Bis jetzt hält mein Topf immer noch ohne Reboots durch - typisch...

Schöne Grüße
Erik

[Homer]

Zum Thema Aufnahme von "Homer": ich bin davon ausgegangen, der Topf nur dann abstürzt, falls irgendwo im EPG eine EPG-Kurzbeschreibung > 256 Zeichen vorkommt. Da lag ich wohl falsch.

Du kannst durchaus richtig liegen und ich falsch.
Ich habe knapp 500 alte 3PG.dat-Sicherungen nach EPG-Kurzbeschreibungen ? 256 Zeichen durchsucht und keine gefunden.
SE müsste wohl erst um die Logging-Funktionalität erweitert werden.

Viele Grüße
Homer

[brandse]

Heute ist's wieder passiert: ich bin beim Einschalten vom Topf in einer Reboot-Schleife gelandet. Zu diesem Zeitpunkt war allerdings keine Aufnahme aktiv!

Als erstes habe ich die "günstige" Situation genutzt und den Tipp von Homer vom 13.11. ausprobiert:

Hilft es, wenn du eine andere Tonspur wählst? (Analog <-> Dolby Digital)

Und siehe da, die Reboots haben sofort aufgehört, nachdem ich - im kurzen Zeitfenster, als der Topf nach dem Reboot "ansprechbar" war - von "Automatisch" auf eine andere Tonspur wechselte! Zur Auswahl hatte ich, wenn ich mich recht erinnere: "Automatisch", "deu", "deu[Dolby Digital]" und "mis". Ich habe bisher allerdings keine Einstellung mehr erwischt, in der die Reboot-Schleife wieder angefangen hätte, auch nicht auf einem anderen Sender mit anderer Tonspur-Auswahl.

Weiters hab ich mir sicherheitshalber mit dem TFtool die EPG-Kurzbeschreibung der letzten Aufnahme angesehen. Diese war wesentlich kürzer als 256 Zeichen:

Kopfball-12.rec (DVB-C)
--------------------
TV
EinPlus HD
19.11.2014 09:40
Kopfball
Wissensreporter im Einsatz
Dauer : 50 Min.
Pid 5421: Video 1280x720 16:9 Mpeg4 AVC
Pid 5422: Audio MP2 192 kb/s; 48,0 kHz stereo (deu)
Pid 5423: Audio MP2 192 kb/s; 48,0 kHz stereo (mis)
Pid 5426: AC3 2/0 at 448 kb/s; 48,0 kHz (deu)
Avg. Rate: 14,64 Mbits/sec
Geplante Themen:
...

Ob jetzt zu diesem Zeitpunkt tatsächlich die Tonspur die Fehlerursache war, traue ich mir noch nicht mit Sicherheit zu sagen. Das muss sich beim nächsten Absturz nochmal zeigen. Falls es aber so wäre: was wäre denn eine mögliche Lösung dafür?

Danke!
Erik

[Homer]

Es gibt verschiedene Datenströme in einem Transponder. Vermutlich wird beim Dekodieren eines Datenstroms ein Datenpaket fehlerhaft verarbeitet, so dass z. B. ein Pufferüberlauf den Topf zum Absturz bringt. Dieses Datenpaket kann vom Sender, vom Kabelnetzbetreiber oder durch Empfangsstörungen in einer solchen Form vorliegen, wie sie der Topf nicht erwartet. Wegen immer möglicher Empfangsstörungen sollte der Topf trotzdem nicht abstürzen.

Der Fehler könnte in einem Datenstrom sein, der nur live dekodiert wird, wie z. B. die EPG-Daten. Dann dürfte das bei der Wiedergabe einer Aufzeichnung nicht mehr zum Absturz führen.
Das Datenpaket liegt im Falle einer Aufzeichnung in den vom Vordergrund- oder Hintergrundtuner empfangenen Daten zur Bildung des Dateinamens/der EPG-Infos des Mitschnitts.
Beim Live-Fernsehen (mit dem Vordergrundtuner) werden die EPG-Daten aller Programme dieses Transponders - nur die, für die es einen Programmplatz gibt (hoffe ich) - dekodiert und intern gespeichert. Fehlervermeidung durch Wechsel des Transponders. Der Fehler sollte zeitnah beim Empfang eines anderen Senders desselben Transponders wieder auftreten.

Der Fehler könnte in einem Datenstrom sein, der sowohl beim Live-Fernsehen als auch bei der Wiedergabe einer Aufzeichnung dekodiert wird. Fehlervermeidung live durch Wechsel des Senders. Danach den problematischen Sender mit dem Hintergrundtuner aufzeichnen. Der Fehler sollte beim Abspielen reproduzierbar wieder auftreten. Fehlereingrenzung/-vermeidung durch Abwahl der Wiedergabe einzelner Datenströme, z. B. DVB-Untertitel, VT-Untertitel, Tonspur "Automatisch" bzw. "deu" abwählen durch die Auswahl von "deu[Dolby Digital]" oder "mis".

Viele Grüße
Homer

[brandse]

Tja, schwierig zu sagen, was jetzt die tatsächliche Ursache ist.

Seit etwa einer Woche mache ich mir jetzt die Mühe, um alle Aufnahmen in einer Tabelle zusammenzufassen. Damit möchte ich herausfinden, ob der Absturz an einer zu langen EPG-Kurzbeschreibung, an einem fehlerhaften PID des Senders und / oder an einer Störung des Transponders liegen kann.

Bisherige Erkenntnisse: seit 15.11. machte ich 22 Aufnahmen, und 2x kam es zum Absturz:

• 19.11.2014 23:55 / Super RTL Austria / Dharma & Greg / Transponder S 38
• 20.11.2014 22:55 / VOX Austria / Matrix Reloaded / Transponder S 38

Die EPG-Daten habe ich hierfür leider nicht, denn diese wurden in die (fehlerhaften) Aufnahme nicht übertragen und sind somit aus dem TFtool auch nicht auslesbar.

Am selben Transponder S 38 hatte ich in dieser Zeit 8 Aufnahmen, die allerdings funktionierten. Und bei den restlichen 12 Aufnahmen auf anderen Transponder gab es auch keine Probleme.

Für mich als bisheriges Fazit: am Transponder S 38 liegt es nicht (immer), aber er ist etwas anfälliger als anderen. Die damalig fehlerhafte Aufnahme von ARD-alpha liegt übrigens auf Transponder S 35.

Die Signalqualität von S 38 liegt bei S:100%, Q:95%, die von S 35 bei S:87%, Q:77%. Ich habe allerdings bei Transpondern mit ähnlich "schlechter" Qualität einwandfreie Aufnahmen.

Meine nächsten Ansatzpunkte sind:

• Tabelle weiterhin führen, um herauszufinden, ob es eine Häufung von fehlerhaften Aufnahmen auf bestimmten Sendern gibt
• eventuell beim Kabelnetzbetreiber anrufen und die Signalqualität überprüfen lassen (derzeit für mich die wahrscheinlichste Ursache)
• versuchen, die EPG-Info bei abgestürzten Aufnahmen rauszubekommen (> 256 Zeichen)
• versuchen, eine Reboot-Schleife während einer laufenden Aufnahme zu "erwischen", um den "Gedanken zu Fehlern" von Homer nachgehen zu können.

Vielen Dank für Eure bisherigen Infos
Erik

[Homer]

[quote="brandse"]Die EPG-Daten habe ich hierfür leider nicht, denn diese wurden in die (fehlerhaften) Aufnahme nicht übertragen und sind somit aus dem TFtool auch nicht auslesbar.[/quote]EPG-Daten werden möglicherweise erst am Ende einer Aufnahme in den Header oder in die .inf geschrieben. Versuche einmal mit TFtool bei der .rec einer fehlerhaften Aufnahme mittels "umbenennen + Header" -> "Event rekonstruieren um ->" und dann mit verschiedenen Zeiten Untertitel und Beschreibung liefern zu lassen. Vielleicht gibt es doch noch etwas Auffälliges.
Teste auch einmal, ob der Topf beim Kopieren einer fehlerhaften Aufnahme abstürzt - falls überhaupt eine Wiedergabe möglich ist.

Viele Grüße
Homer

[brandse]

Heute ist schon wieder etwas passiert...

Seit meiner letzten Nachricht vom 23.11. hatte ich insgesamt 25 Aufnahmen. Davon sind 2 gestern und heute mit Reboot-Schleifen danebengegangen. Hier die letzten 5 Aufnahmen:

OK: 26.11.2014 19:25 / ARD-alpha / Kopfball
Reboots: 26.11.2014 23:55 / Super RTL Austria / Dharma & Greg
OK: 27.11.2014 12:40 / EinPlus HD / Kopfball
OK: 27.11.2014 14:10 / Super RTL Austria / Weihnachtsmann & Co. KG
Reboots: 27.11.2014 15:55 / ARD-alpha / Kopfball

Zu den fehlerhaften Aufnahmen:

"Dharma & Greg" hat in den letzten Tagen zwei Mal hintereinander nicht funktioniert (war aber auch schon mal fehlerfrei).

TFtool zeigt an:
Dharma & Greg.rec (DVB-C)
--------------------
TV
Super RTL Austria
26.11.2014 23:55

Dauer : 45 Min.
Pid 501: Video 720x576 16:9 4:2:0 MP@ML Mpeg2
Pid 502: Audio MP2 192 kb/s; 48,0 kHz joint_stereo (ger)
Avg. Rate: 4,96 Mbits/sec
Es wurde im Gegensatz zu den anderen Aufnahmen hier keine EPG-Infos abgespeichert! Nach der Analyse mit "umbenennen + Header" -> "Event rekonstruieren um ->" zeigt sich folgendes:
Titel: Dharma & Greg
Untertitel: <keiner>
Beschreibung:
Folge 109: 'Warten auf den Sohn'
In der Schweiz startet an dieser Stelle interaktives Nachtprogramm.. Ed hat plötzlich einen Herzinfarkt, kommt jedoch nochmal mit dem Schrecken davon. Jetzt will er seinen Lebenswandel radikal ändern, stellt jedoch schon bald fest, dass er dadurch nicht gerade glücklicher wird. Als Ed dann auch noch denkt, er habe als Schuhverkäufer seinen neuen Traumjob gefunden, schrillen bei Kitty, Dharma und Greg die Alarmglocken...
Anzeige am OSD nach drücken der "i"-Taste (Datum, Wochentag und Uhrzeit passen nicht):
Super RTL Austria
116/112 (???) 01:00 - 01:00
Keine weiteren Informationen
Was fällt noch auf:
Die ersten Sekunden wurden aufgenommen (entspricht aber NICHT der 5 Min. Aufnahme-Vorlaufzeit, 3,4 GB .rec-Datei), danach kam es jede Minute zum Reboot. Die Reboot-Schleifen erzeugten 25 einzelne .rec-Dateien und endeten ca. 15 Minuten vor dem Ende der Sendung (entspricht der Aufnahme-Nachlaufzeit).


"Kopfball": hier haben in den letzten Tagen von 11 Aufnahmen nur 1 nicht funktioniert.

TFtool zeigt an:
Kopfball-19.rec (DVB-C)
--------------------
TV
ARD-alpha
27.11.2014 15:55

Dauer : 50 Min.
Pid 1401: Video 720x576 16:9 4:2:0 MP@ML Mpeg2
Pid 1402: Audio MP2 192 kb/s; 48,0 kHz stereo (deu)
Pid 1403: Audio MP2 192 kb/s; 48,0 kHz stereo (mis)
Pid 1406: AC3 2/0 at 448 kb/s; 48,0 kHz (deu)
Avg. Rate: 5,38 Mbits/sec
Es wurde auch hier im Gegensatz zu den anderen Aufnahmen keine EPG-Infos abgespeichert! Nach der Analyse mit "umbenennen + Header" -> "Event rekonstruieren um ->" zeigt sich folgendes:
Titel: Kopfball
Untertitel: Wissensreporter im Einsatz
Beschreibung:
Fünf junge Wissensreporter sind für Kopfball im Einsatz. Mit spannenden Experimenten, wissenschaftlichem Sachverstand und mit viel Neugier und Spaß gehen sie Zuschauerfragen auf den Grund. Heute mit diesen Themen:
* Kann man mit Magneten an Füßen und Händen eine Hauswand hochklettern?
* Wie lange dauert eine Schrecksekunde?
* Was hält den Sand in einer Sandburg zusammen?
Anzeige am OSD nach drücken der "i"-Taste (Datum, Wochentag und Uhrzeit passen nicht):
ARD-alpha
166/112 (???) 01:00 - 01:00
Keine weiteren Informationen
Was fällt noch auf:
Die ersten 5 Minuten wurden aufgenommen (entspricht SCHON der 5 Min. Aufnahme-Vorlaufzeit, erzeugte eine 202 MB .rec-Datei), danach kam es jede Minute zum Reboot. Teilweise hatten dann die Dateien sogar nur 0 Bytes. Die Reboot-Schleifen erzeugten 48 einzelne .rec-Dateien und endeten ebenfalls ca. 15 Minuten vor dem Ende der Sendung (entspricht der Aufnahme-Nachlaufzeit).


Die Aufnahmen (auch die kurzen Segmente) kann ich aufrufen und abspielen, es kommt dabei zu keinem Absturz des Topfs nach Ende der Wiedergabe.

Ich hab jetzt auch meine Excel-Datei bzgl. den letzen Aufnahmen mit ein paar Interpretationsversuchen dazugegeben.

Kann sich jemand daraus einen Reim machen?

Danke schön
Erik