RecStripper - TAP zum Schrumpfen der Aufnahmen

[Homer]

Bis ans Ende der Welt ZDF HD:
Packets: 167488590, FillerNALUs: 1130841 (0%), ZeroByteStuffing: 0 (0%), NullPackets: 0 (0%), EPG: 11090745 (6%), Dropped (all): 12221586 (7%)

Die Päpstin Das Erste HD (nicht mit TFtool beschnitten):
Packets: 87468095, FillerNALUs: 0 (0%), ZeroByteStuffing: 34346425 (39%), NullPackets: 0 (0%), EPG: 7461333 (8%), Dropped (all): 41807758 (47%)

Die gemeldeten Artefakte treten nicht mehr auf. Weitere Tests erst nächste Woche.

Viele Grüße
Homer

[chris86]

bei mir ga es, ich glau beim 5ten file einen reboot, siehe logs.

Das ist jetzt aber nicht dein Ernst, oder!?

Also, dann wieder dasselbe Spiel von vorne:
- Ist das Problem reproduzierbar? Mit derselben Aufnahme (auch wenn sie nicht die 5. ist), oder am besten mit einem kurzen Teilstück?
- Kannst du diese Aufnahme (oder ein kurzes Teilstück, mit dem sich der Fehler reproduzieren lässt) irgendwie bereitstellen?

[Twilight]

also hab noch etwas nachgeforscht:

der reboot erfolget ja an ganz anderer stelle soweit ich das erkenne.
alle datein (auch die "reboot datei") haben eine korrekte inf sind also komplett abgearbeitet
timestamps renewed funktioniert nicht, die sortierung nach der zeit bringt im SmartFiler unterschiedliche sortierung für die neuen files.

ich starte das ding jetzt noch mit der datei die den letzten reboot verursacht hat, denke aber nicht das es an der datei selbst liegt, so wie es sich im moment darstellt.

die "alte" reboot datei ist ohne probleme durchgelaufen

twilight

[Twilight]

noch ein hinweis: zur zeit des reboots lief eine aufnahme welche um 22:02 beendet wurde, danach gab es keine einträge mehr in SmartEPG

Code: Alles auswählen

2016-01-29 22:02:20 Recording is from scrambled channel
2016-01-29 22:02:20 Recording is marked as: Descrambled
2016-01-29 22:02:20 Change ScanFlag for RbN QuickMode to "descrambled"
2016-01-29 22:02:20 End of a recording detected
2016-01-29 22:06:22 ===================================================
2016-01-29 22:06:22 SmartEPG_TMS  rev2067
2016-01-29 22:06:22 SysID=22121(SRP-2410), Firmware=TF-BCPCE 1.10.00 (Nov  5 2013) (0x0110), Rec=.rec
2016-01-29 22:06:22 TimeZone = 60 min 
2016-01-29 22:06:22 System type: TMS DVBs
2016-01-29 22:06:22 RemoteType: 2100
2016-01-29 22:06:23 Reboot detected

twilight

[Twilight]

ok, reboot reproduzierbar lade dir die datei wie letztes mal hoch, daten hast du ja noch!

Code: Alles auswählen

2016-01-29 21:51:54 Processing file 'Schlawiner - Schnaps ist Schnaps.rec' (3208172928 bytes)... 
2016-01-29 22:05:50 RecStrip finished.
2016-01-29 22:05:50 RecStrip.out exists.
2016-01-30 07:35:59 ***  RecStripper V0.2 started! (FBLib 2013-02-24+) ***
2016-01-30 07:35:59 =======================================================
2016-01-30 07:35:59 Receiver Model: SRP-2410 (22121), System Type: TMS-S (5)
2016-01-30 07:35:59 Firmware: TF-BCPCE 1.10.00
2016-01-30 07:35:59 RecStripDir: /mnt/hd/DataFiles/RecStrip, OutDir: /mnt/hd/DataFiles/RecStrip_out
2016-01-30 07:35:59 Nr of files in folder: 1
2016-01-30 07:36:02 Processing file 'Schlawiner - Schnaps ist Schnaps.rec' (3208172928 bytes)... 
2016-01-30 07:50:31 RecStrip finished.
2016-01-30 07:50:31 RecStrip.out exists.

twilight

[Sirius]

Mit der V0.2 aus #97 hatte ich, wie AS, keine Reboots auf dem 2100.

Mit der V0.3 heute immer mit 2 Dateien im RecStrip Ordner getestet:
8x Reboots, 1x Freeze, 2x Erfolgreich beendet.


Der Freeze (Bilder aus Südtirol):
Zeit vergangen: 158s, Zeit verbleibend: 15s

Einer der Reboots:
... , Zeit verbleibend: 15s
.

[Alter Sack]

8x Reboots, 1x Freeze, 2x Erfolgreich beendet.

Sieht bei mir ähnlich aus, der 2100er ist eben eine alte Zicke

1 Reboot
2 Freeze, Ton läuft weiter (0 of 1 files successfully processed, RecStripper Exit fehlt im Log)
3 Reboot
4 OK (0 of 1 files successfully processed)
5 Reboot
6 Reboot
7 Freeze, Ton läuft weiter (0 of 1 files successfully processed, RecStripper Exit fehlt im Log)

[Alter Sack]

Die gleiche Aufnahme auf dem 2401:

1 OK (1 of 1 files successfully processed)
2 OK (1 of 1 files successfully processed)
3 OK (1 of 1 files successfully processed)
4 OK (1 of 1 files successfully processed)
5 OK (1 of 1 files successfully processed)
6 OK (1 of 1 files successfully processed)
7 OK (1 of 1 files successfully processed)

[Alter Sack]

[quote="Alter Sack"]Die gleiche Aufnahme auf dem 2401:[/quote]
Jetzt im 10er Pack:

1 OK (9 of 10 files successfully processed)
2 OK (10 of 10 files successfully processed)
3 OK (10 of 10 files successfully processed)
4 Reboot bei 8/10

Also ein Reboot beim 38sten Versuch.

[chris86]

Danke euch für die gesammelten Fehlerberichte!!!
Damit ist wohl unzweifelhaft bewiesen, dass mit dem Programm noch irgendetwas im Argen liegt
Auch wenn ich leider aktuell keine Ahnung habe, was es sein könnte...

Ich habe dieses Wochenende fleißig den armen Topf gequält und einige Aufnahmen gestrippt. Mit dem TAP konnte ich ein paar Crashes reproduzieren - über Telnet ist es mir jedoch nicht gelungen.

Hatte irgendjemand von euch auch beim Strippen mit RecStrip über Telnet einen Absturz zu verzeichnen?
(Das ist relevant zu wissen, um herauszufinden, ob ich den Fehler im TAP oder im RecStrip-Tool suchen muss...)

[Twilight]

ist es anhand meiner fehlerbeschreibung und der logs nicht bewiesen das meine reboots nicht vom script gekommen sind? ohne tap habe ich nicht getestet.
konntest du dir das file runter laden und dmait testen?

twilight

[Alter Sack]

[quote="chris86"]Hatte irgendjemand von euch auch beim Strippen mit RecStrip über Telnet einen Absturz zu verzeichnen?[/quote]
Nein, müsste sich ja beim 2100er relativ schnell zeigen.

BTW: Das TAP meldet sich mit 0.2. RecStrip selbst mit 0.3, aber das wirds ja nicht sein.

[chris86]

ist es anhand meiner fehlerbeschreibung und der logs nicht bewiesen das meine reboots nicht vom script gekommen sind? ohne tap habe ich nicht getestet.
konntest du dir das file runter laden und dmait testen?

Ich fürchte nein. Wenn RecStrip irgendeinen bösen Puffer-Überlauf verursacht, dann kann das zu einem beliebigen späteren Zeitpunkt zu einem Crash führen. Deshalb ist das ja so schwer zu debuggen.
(Natürlich habe ich auch das TAP untersucht - aber dessen Code ist ziemlich simpel, da es im Prinzip nichts anderes macht, als RecStrip aufzurufen. Und darin habe ich leider keinen Fehler entdeckt...)

Und ja, ich habe am WE dreimal (fehlerfrei) deine Riesen-Datei gestrippt...

[Alter Sack]

Und ja, ich habe am WE dreimal (fehlerfrei) deine Riesen-Datei gestrippt...

Die Dateigröße machts aber nicht, ich nehme immer den Schnipsel, den ich Dir geschickt habe.

Du brauchst einen 2100er

[Twilight]

ich kann ihm gern einen schicken

twilight

[Alter Sack]

Ich habe mal den Startvorgang und den Reboot des 2100ers mitgeloggt, vielleicht sagt das
ja irgendwas aus

Code: Alles auswählen

Booting ...
...
...
--> RecStripper Start
rm: cannot remove '/tmp/RecStrip.*': No such file or directory
--> Hier hat er angefangen zu Strippen, dann der Reboot:
/root/rc.user: line 11:    54 Segmentation fault      sh run pvr
The system is going down NOW!
Sending SIGTERM to all processes
Sending SIGKILL to all processes
Requesting system reboot
Synchronizing SCSI cache for disk sda:
Restarting system.
.

Booting...

[chris86]

So, ich habe nochmal einen Mini-Bug gefixt.
Zwar bezweifle ich, dass das wirklich die Ursache für die Abstürze war (dann hätten diese nämlich ebenso in MovieCutter* erfolgen müssen ) - aber die Hoffnung stirbt zuletzt...

Wäre klasse, wenn die Absturz-Produzierer die neue Version (TAP + RecStrip müssen ersetzt werden) nochmal auf ihre problematischen Filme (und am besten auf den 2100er) loslassen könnten!

Download wieder hier: RecStripper 0.3

PS: Gebt euch nicht zu viel Mühe - sobald der erste den Crash wieder reproduziert hat, weiß ich, dass er immernoch vorhanden ist, und ich weitersuchen muss...
(Nur falls kein Crash mehr auftritt, lohnt es sich, mit vielen Aufnahmen zu testen, um zu prüfen, ob er wirklich wirklich weg ist)


Edit:
(*) Dieser "Bug" wurde von Microsoft Visual Studio gemeldet. Nach genauer Betrachtung der C-Spezifikation stellte sich heraus, dass es sich um ein "false positive" handelt. Simulation unter Laborbedingungen bestätigt, dass die Funktion sscanf (bis auf eine Stelle) korrekt und standardkonform eingesetzt wurde.
Nur bei einem grob fehlformatierten textbasierten .cut-File besteht evtl. die Möglichkeit eines 1-byte-Pufferüberlaufs. Dies wird in der nächsten MC-Version gefixt, tritt aber in der realen Welt vermutlich niemals auf.

[Sirius]

Danke für die neue Version und deinen Einsatz.
Kann aber erst am WE wieder testen, bin unterwegs.

[Alter Sack]

Kann aber erst am WE wieder testen, bin unterwegs.

Faule Ausrede, ich bin auch 20km vom Topf weg und fange gerade an zu Strippen,
... wie sich das anhört, angezogen bin ich natürlich noch

Geht aber nur beim 2401, der 2100er ist gerade abgeklemmt.

[Anthea]

fange gerade an zu Strippen,
... wie sich das anhört, angezogen bin ich natürlich noch

Liegt die Betonung hier auf dem "noch"?