MovieCutter

[ramibi]

nö - die neueste hatte ich nicht drauf - es war die zweite oder 3 Version, aber da war der Wunsch für den Butten Vor- und Nachlauf schon länger geäußert

[Twilight]

da es den switch für gerade/ungerade segmente gibt, sollte das nun abgedeckt sein.

ich geb mich geschlagen

twilight

[db1]

Hallo, vielen Dank, ich werde die HoffentlichnachdemSchnittnichtLöschen Versionen natürlich testen ;-)

Eigentlich ist das aber nicht das alleinige Problem deines TAPs. Ich sehe es auch als Problem des TAPs dass funktionierende rec-files einfach löscht

[chris86]

... nee - wenn der Punkt bzw. der Wunsch oder die Bitte nach dieser Erweiterung ich ja nicht alleine damit - ignoriert wird, dann bleibe ich bei der 1.4 von Alex

Es steht jedem frei, jedes beliebige Programm bzw. jede Version zu benutzen, die er will.
Wenn du auf die diversen Neuerungen/Optimierungen verzichten willst, kannst du gern die alte Version weiter nutzen.

Allerdings steht es auch mir frei, selbst zu entscheiden, an welchen Stellen ich meine (naturgemäß begrenzte) Freizeit und Hirnschmalz einsetze, um irgendwas zu implementieren und wo nicht. Penetrantes Generve oder "Erpressungsversuche" sind hier absolut fehl am Platz! Ich muss das nicht machen, und werde dafür nicht bezahlt!

Abgesehen davon:

* neuer ini-Schalter: DirectSegmentsCut=1 erlaubt direktes Löschen der (un)geraden Segmente, bzw. des Vor-/Nachlaufs

Vielleicht erst lesen, dann meckern! Ich habs noch extra für dich fett gedruckt.

[Twilight]

naja...er hat ja auch schon 2 hinweise von anderen bekommen, welchen er nicht nachgegangen ist, aber gut

twilight

[ramibi]

... tja - er liest halt nicht immer zwischen den Zeilen ops:

Dann werde ich mal die neueste Version testen

[chris86]

Hallo, vielen Dank, ich werde die HoffentlichnachdemSchnittnichtLöschen Versionen natürlich testen ;-)

Eigentlich ist das aber nicht das alleinige Problem deines TAPs. Ich sehe es auch als Problem des TAPs dass funktionierende rec-files einfach löscht

Kann mir jemand diesen Post erklären?
Also, ja, es ist das zentrale Problem, dass Aufnahmen gelöscht werden!
Das tut aber nicht der MovieCutter!!
Leider kann bisher niemand genau sagen, welches TAP oder welche Funktion der Firmware für die Löschung verantwortlich ist, inwiefern das mit dem MC-Schnitt zusammenhängt, und ob das Problem neu entstanden ist oder jetzt erst entdeckt wurde.

Die obigen Testversionen nehmen einige der (weniger wichtigen) Änderungen, die ich im Vergleich zu V1.4 eingebaut habe, zurück, um zu testen ob es daran liegt.
Als nächster Schritt bliebe nur noch, komplett auf V1.4 zurückzugehen, und zu testen, ob das Problem dann immernoch auftritt oder nicht.

[Fritzcat]

Bei der Entwicklung von Version 2.0g haben 2 Tester von einem neuen Bug berichtet:

Dieser Bug scheint mal wieder nur auf dem TMS2100 aufzutreten, bei allen anderen getesteten Geräten funktioniert es absolut problemlos! Zwar ist dieser Bug ebenfalls ärgerlich, im Gegensatz zu dem obigen, erfolgt hierbei jedoch kein Verlust oder Beschädigung der behandelten Aufnahme.
(Nach zahlreichen Tests habe ich einen Überlauf in einer Funktion der TAP-API im Verdacht - aber das ist bislang bloß eine Theorie)

Da ich den Fehler selbst nicht reproduzieren kann, bitte ich alle davon Betroffenen (speziell FritzCat und klassikmann), jeweils einen Testschnitt mit JEDER der folgenden Spezialversionen durchzuführen, und mir das entstehende Log zukommen zu lassen. Nur dann habe ich eine Chance, den Fehler zu beheben!

1.) MovieCutter_20g_debug_MovedInfCP.tap
2.) MovieCutter_20g_debug_MovedCP_ModTAPFread.tap
3.) MovieCutter_20g_debug_NoTAPFread.tap

und zuletzt:
4.) MovieCutter_20g_debug2_NoCP.tap

Die wichtigste Information ist für mich zunächst: Mit welchen Versionen tritt das Problem auf, mit welchen nicht? (inkl. Log!)

Habe jetzt alle 4 Versionen in o.a. Reihenfolge getestet. Leider bei allen das gleiche Ergebnis. Absturz u. Neustart.

Hier die Log, ich hoffe, sie hilft weiter:

2014-01-17 13:15:39 *** MovieCutter V2.0g_debug started! ***
2014-01-17 13:15:39 ====================================
2014-01-17 13:15:39 Receiver Model: SRP-2100 (TMS) (22010)
2014-01-17 13:15:39 Firmware: TF-BCPC 1.15.01 (2013-09-26)
2014-01-17 13:16:08 ========================================

2014-01-17 13:16:08 Attaching to /mnt/hd/DataFiles/Familien im Ernaehrungsstress - 2014-01-17 10-58.rec
2014-01-17 13:16:08 ----------------------------------------
2014-01-17 13:16:08 File size = 713150464 Bytes (79028 blocks)
2014-01-17 13:16:08 Reported total blocks: 79024
2014-01-17 13:16:08 Type of recording: SD
2014-01-17 13:16:08 .nav-file loaded: 2737 different TimeStamps found.
2014-01-17 13:16:08 First Timestamp: Block=2, Time=0:00:01.946
2014-01-17 13:16:09 Playback Duration (from nav): 0:28:00.137
2014-01-17 13:16:09 Playback Duration (from inf): 0:28:00
2014-01-17 13:16:09 CutFileLoad: .cut doesn't exist!
2014-01-17 13:16:19 Importing 2 of 2 bookmarks
2014-01-17 13:16:19 Bookmark 1 @ 8519
2014-01-17 13:16:19 New marker @ block = 8519, time = 0:03:01.256, percent = 10.8%
2014-01-17 13:16:19 Bookmark 2 @ 48057
2014-01-17 13:16:19 New marker @ block = 48057, time = 0:17:02.642, percent = 60.8%
2014-01-17 13:17:29 [Action 'Save segments' started...]
2014-01-17 13:17:29 Seg Block Time Pct Sel Act
2014-01-17 13:17:29 00: 0000000000 0:00:00.000 000 no
2014-01-17 13:17:29 01: 0000008519 0:03:01.256 010 yes *
2014-01-17 13:17:29 02: 0000048057 0:17:02.642 060 no
2014-01-17 13:17:29 03: 0000079024 0:28:00.137 100 no
2014-01-17 13:17:29 CutFileSave()! CurrentDir: /DataFiles, PlaybackName: Familien im Ernaehrungsstress - 2014-01-17 10-58.rec, CutFileName: Familien im Ernaehrungsstress - 2014-01-17 10-58.cut
2014-01-17 13:17:29 CutFileSave()! CurrentDir: /DataFiles, PlaybackName: Familien im Ernaehrungsstress - 2014-01-17 10-58.rec, CutFileName: Familien im Ernaehrungsstress - 2014-01-17 10-58.cut
2014-01-17 13:17:30 Processing segment 1
2014-01-17 13:17:30 ----------------------------------------
2014-01-17 13:17:30 Source = 'Familien im Ernaehrungsstress - 2014-01-17 10-58.rec'
2014-01-17 13:17:30 Cut name = 'Familien im Ernaehrungsstress - 2014-01-17 10-58 (Cut-1).rec'
2014-01-17 13:17:30 File size = 713150464 Bytes (79028 blocks)
2014-01-17 13:17:30 Dir = '/DataFiles'
2014-01-17 13:17:30 PacketSize = 192
2014-01-17 13:17:30 CutStartBlock = 8519, BehindCutBlock = 48057
2014-01-17 13:17:30 CutStartPos = 76875456, BehindCutPos = 433666368
2014-01-17 13:17:30 KeepCut = yes
2014-01-17 13:17:30 ReadCutPointArea()
2014-01-17 13:17:30 ReadCutPointArea()
2014-01-17 13:17:30 PatchRecFile()
2014-01-17 13:17:30 PatchRecFile()
2014-01-17 13:17:30 FileCut()
2014-01-17 13:17:30 Cut file size: 356794368 Bytes (=39538 blocks)
2014-01-17 13:17:30 ReadFirstAndLastCutPacket()
2014-01-17 13:17:30 Cut start offset: -1728 Bytes (=-9 packets and 0 Bytes), Cut end offset: 1728 Bytes (=9 packets and 0 Bytes)
2014-01-17 13:17:30 Real cut positions: Cut Start = 76873728, Behind Cut: 433668096
2014-01-17 13:17:30 --> Real cutting points guessed correctly!
2014-01-17 13:17:30 UnpatchRecFile()
2014-01-17 13:17:30 Patched Bytes: 0, 0, 0, 0, 0, 0, 0, 0
2014-01-17 13:17:30 PatchNavFilesSD()
2014-01-17 13:17:30 PatchInfFiles()
2014-01-17 13:17:30 PatchInfFiles(): 499572 / 132636 Bytes read.
2014-01-17 13:24:22 *** MovieCutter V2.0g_debug started! ***
2014-01-17 13:24:22 ====================================
2014-01-17 13:24:22 Receiver Model: SRP-2100 (TMS) (22010)
2014-01-17 13:24:22 Firmware: TF-BCPC 1.15.01 (2013-09-26)
2014-01-17 13:25:55 ========================================

2014-01-17 13:25:55 Attaching to /mnt/hd/DataFiles/Familien im Ernaehrungsstress - 2014-01-17 10-58.rec
2014-01-17 13:25:55 ----------------------------------------
2014-01-17 13:25:55 File size = 356356096 Bytes (39489 blocks)
2014-01-17 13:25:55 Reported total blocks: 39486
2014-01-17 13:25:55 Type of recording: SD
2014-01-17 13:25:55 .nav-file loaded: 1360 different TimeStamps found.
2014-01-17 13:25:55 First Timestamp: Block=2, Time=0:00:01.946
2014-01-17 13:25:55 Playback Duration (from nav): 0:13:58.751
2014-01-17 13:25:55 Playback Duration (from inf): 0:28:00
2014-01-17 13:25:55 .nav file length not matching duration!
2014-01-17 13:25:55 Checking source nav file (possibly older version with incorrect Times)...
2014-01-17 13:25:55 CutFileLoad: .cut file size mismatch!
2014-01-17 13:25:55 CutFileLoad: Importing timestamps only, recalculating block numbers...
2014-01-17 13:25:55 2.) oldTimeStamp=0:03:01.256 oldBlock=8519 --> newBlock=8496 newTimeStamp=0:03:01.256
2014-01-17 13:25:55 3.) oldTimeStamp=0:17:02.642 oldBlock=48057 --> newBlock=39451 newTimeStamp=0:13:58.751
2014-01-17 13:25:55 CutFileLoad: Letzter Segment-Marker 4294967295 ist ungleich TotalBlock 39486!
2014-01-17 13:26:15 TAP_EventHandler(): State=ST_ActiveOSD, !isPlaybackRunning --> Aufruf von CutFileSave()
2014-01-17 13:26:15 CutFileSave()! CurrentDir: /DataFiles, PlaybackName: Familien im Ernaehrungsstress - 2014-01-17 10-58.rec, CutFileName: Familien im Ernaehrungsstress - 2014-01-17 10-58.cut
2014-01-17 13:26:34 ========================================

2014-01-17 13:26:34 Attaching to /mnt/hd/DataFiles/Magazin: Service und Lifestyle - Folge 3.3 - 2014-01-17 10-29.rec
2014-01-17 13:26:34 ----------------------------------------
2014-01-17 13:26:34 File size = 711802880 Bytes (78878 blocks)
2014-01-17 13:26:34 Reported total blocks: 78855
2014-01-17 13:26:34 Type of recording: SD
2014-01-17 13:26:34 .nav-file loaded: 2966 different TimeStamps found.
2014-01-17 13:26:34 First Timestamp: Block=20, Time=0:00:01.977
2014-01-17 13:26:34 Playback Duration (from nav): 0:27:57.424
2014-01-17 13:26:34 Playback Duration (from inf): 0:27:57
2014-01-17 13:26:34 CutFileLoad: .cut doesn't exist!
2014-01-17 13:26:41 Importing 2 of 2 bookmarks
2014-01-17 13:26:41 Bookmark 1 @ 8365
2014-01-17 13:26:41 New marker @ block = 8365, time = 0:02:58.991, percent = 10.6%
2014-01-17 13:26:41 Bookmark 2 @ 60201
2014-01-17 13:26:41 New marker @ block = 60201, time = 0:21:22.058, percent = 76.3%
2014-01-17 13:27:30 [Action 'Delete segments' started...]
2014-01-17 13:27:30 Seg Block Time Pct Sel Act
2014-01-17 13:27:30 00: 0000000000 0:00:00.000 000 yes
2014-01-17 13:27:30 01: 0000008741 0:03:06.589 011 no *
2014-01-17 13:27:30 02: 0000060201 0:21:22.058 076 yes
2014-01-17 13:27:30 03: 0000078855 0:27:57.423 100 no
2014-01-17 13:27:30 CutFileSave()! CurrentDir: /DataFiles, PlaybackName: Magazin: Service und Lifestyle - Folge 3.3 - 2014-01-17 10-29.rec, CutFileName: Magazin: Service und Lifestyle - Folge 3.3 - 2014-01-17 10-29.cut
2014-01-17 13:27:31 CutFileSave()! CurrentDir: /DataFiles, PlaybackName: Magazin: Service und Lifestyle - Folge 3.3 - 2014-01-17 10-29.rec, CutFileName: Magazin: Service und Lifestyle - Folge 3.3 - 2014-01-17 10-29.cut
2014-01-17 13:27:31 Processing segment 2
2014-01-17 13:27:31 (* special mode for cut ending *)
2014-01-17 13:27:31 ----------------------------------------
2014-01-17 13:27:31 Source = 'Magazin: Service und Lifestyle - Folge 3.3 - 2014-01-17 10-29.rec'
2014-01-17 13:27:31 Cut name = 'Magazin: Service und Lifestyle - Folge 3.3 - 2014-01-17 10-29_temp.rec'
2014-01-17 13:27:31 File size = 711802880 Bytes (78878 blocks)
2014-01-17 13:27:31 Dir = '/DataFiles'
2014-01-17 13:27:31 PacketSize = 192
2014-01-17 13:27:31 CutStartBlock = 0, BehindCutBlock = 60201
2014-01-17 13:27:31 CutStartPos = 0, BehindCutPos = 543253824
2014-01-17 13:27:31 KeepCut = yes
2014-01-17 13:27:31 ReadCutPointArea()
2014-01-17 13:27:31 ReadCutPointArea()
2014-01-17 13:27:31 PatchRecFile()
2014-01-17 13:27:31 PatchRecFile()
2014-01-17 13:27:31 FileCut()
2014-01-17 13:27:31 Cut file size: 543252480 Bytes (=60200 blocks)
2014-01-17 13:27:31 ReadFirstAndLastCutPacket()
2014-01-17 13:27:31 Cut start offset: 0 Bytes (=0 packets and 0 Bytes), Cut end offset: -1344 Bytes (=-7 packets and 0 Bytes)
2014-01-17 13:27:31 Real cut positions: Cut Start = 0, Behind Cut: 543252480
2014-01-17 13:27:31 --> Real cutting points guessed correctly!
2014-01-17 13:27:31 UnpatchRecFile()
2014-01-17 13:27:31 Patched Bytes: 0, 0, 0, 0, 0, 0, 0, 0
2014-01-17 13:27:31 PatchNavFilesSD()
2014-01-17 13:27:32 PatchInfFiles()
2014-01-17 13:27:32 PatchInfFiles(): 1 / 132636 Bytes read.
2014-01-17 13:30:26 *** MovieCutter V2.0g_debug started! ***
2014-01-17 13:30:26 ====================================
2014-01-17 13:30:26 Receiver Model: SRP-2100 (TMS) (22010)
2014-01-17 13:30:26 Firmware: TF-BCPC 1.15.01 (2013-09-26)
2014-01-17 13:31:00 ========================================

2014-01-17 13:31:00 Attaching to /mnt/hd/DataFiles/Nachrichten - 2014-01-17 10-27.rec
2014-01-17 13:31:00 ----------------------------------------
2014-01-17 13:31:00 File size = 817655808 Bytes (90609 blocks)
2014-01-17 13:31:00 Reported total blocks: 90604
2014-01-17 13:31:00 Type of recording: SD
2014-01-17 13:31:00 .nav-file loaded: 2527 different TimeStamps found.
2014-01-17 13:31:00 First Timestamp: Block=27, Time=0:00:02.125
2014-01-17 13:31:00 Playback Duration (from nav): 0:23:59.868
2014-01-17 13:31:00 Playback Duration (from inf): 0:24:00
2014-01-17 13:31:00 CutFileLoad: .cut doesn't exist!
2014-01-17 13:31:06 Importing 2 of 2 bookmarks
2014-01-17 13:31:06 Bookmark 1 @ 11543
2014-01-17 13:31:06 New marker @ block = 11543, time = 0:02:51.388, percent = 12.7%
2014-01-17 13:31:06 Bookmark 2 @ 49202
2014-01-17 13:31:07 New marker @ block = 49202, time = 0:12:59.649, percent = 54.3%
2014-01-17 13:32:03 [Action 'Delete segments' started...]
2014-01-17 13:32:03 Seg Block Time Pct Sel Act
2014-01-17 13:32:03 00: 0000000000 0:00:00.000 000 yes
2014-01-17 13:32:03 01: 0000014631 0:03:34.828 016 no
2014-01-17 13:32:03 02: 0000054987 0:14:31.464 060 yes *
2014-01-17 13:32:03 03: 0000090604 0:23:59.868 100 no
2014-01-17 13:32:03 CutFileSave()! CurrentDir: /DataFiles, PlaybackName: Nachrichten - 2014-01-17 10-27.rec, CutFileName: Nachrichten - 2014-01-17 10-27.cut
2014-01-17 13:32:04 Processing segment 2
2014-01-17 13:32:04 (* special mode for cut ending *)
2014-01-17 13:32:04 ----------------------------------------
2014-01-17 13:32:04 Source = 'Nachrichten - 2014-01-17 10-27.rec'
2014-01-17 13:32:04 Cut name = 'Nachrichten - 2014-01-17 10-27_temp.rec'
2014-01-17 13:32:04 File size = 817655808 Bytes (90609 blocks)
2014-01-17 13:32:04 Dir = '/DataFiles'
2014-01-17 13:32:04 PacketSize = 192
2014-01-17 13:32:04 CutStartBlock = 0, BehindCutBlock = 54987
2014-01-17 13:32:04 CutStartPos = 0, BehindCutPos = 496202688
2014-01-17 13:32:04 KeepCut = yes
2014-01-17 13:32:04 ReadCutPointArea()
2014-01-17 13:32:04 ReadCutPointArea()
2014-01-17 13:32:04 Write handle for rec-file successfully obtained!
2014-01-17 13:32:04 PatchRecFile()
2014-01-17 13:32:04 PatchRecFile()
2014-01-17 13:32:04 FileCut()
2014-01-17 13:32:04 Cut file size: 496201728 Bytes (=54986 blocks)
2014-01-17 13:32:04 ReadFirstAndLastCutPacket()
2014-01-17 13:32:04 Cut start offset: 0 Bytes (=0 packets and 0 Bytes), Cut end offset: -960 Bytes (=-5 packets and 0 Bytes)
2014-01-17 13:32:04 Real cut positions: Cut Start = 0, Behind Cut: 496201728
2014-01-17 13:32:04 --> Real cutting points guessed correctly!
2014-01-17 13:32:04 UnpatchRecFile()
2014-01-17 13:32:04 Patched Bytes: 0, 0, 0, 0, 0, 0, 0, 0
2014-01-17 13:32:04 PatchNavFilesSD()
2014-01-17 13:32:04 PatchInfFiles()
2014-01-17 13:32:05 Playtimes: Cut = 0:14:29
2014-01-17 13:32:05 PatchInfFiles(): 712 / 132636 Bytes read.
2014-01-17 13:34:03 *** MovieCutter V2.0g_debug started! ***
2014-01-17 13:34:03 ====================================
2014-01-17 13:34:03 Receiver Model: SRP-2100 (TMS) (22010)
2014-01-17 13:34:03 Firmware: TF-BCPC 1.15.01 (2013-09-26)
2014-01-17 13:34:20 ========================================

2014-01-17 13:34:20 Attaching to /mnt/hd/DataFiles/Nachrichten - 2014-01-17 10-57.rec
2014-01-17 13:34:20 ----------------------------------------
2014-01-17 13:34:20 File size = 786178048 Bytes (87120 blocks)
2014-01-17 13:34:20 Reported total blocks: 87095
2014-01-17 13:34:20 Type of recording: SD
2014-01-17 13:34:21 .nav-file loaded: 2201 different TimeStamps found.
2014-01-17 13:34:21 First Timestamp: Block=23, Time=0:00:01.410
2014-01-17 13:34:21 Playback Duration (from nav): 0:22:59.867
2014-01-17 13:34:21 Playback Duration (from inf): 0:23:00
2014-01-17 13:34:21 CutFileLoad: .cut doesn't exist!
2014-01-17 13:34:27 Importing 2 of 2 bookmarks
2014-01-17 13:34:27 Bookmark 1 @ 11330
2014-01-17 13:34:27 New marker @ block = 11330, time = 0:03:05.612, percent = 13.0%
2014-01-17 13:34:27 Bookmark 2 @ 49208
2014-01-17 13:34:27 New marker @ block = 49208, time = 0:12:53.719, percent = 56.5%
2014-01-17 13:35:02 [Action 'Delete segments' started...]
2014-01-17 13:35:02 Seg Block Time Pct Sel Act
2014-01-17 13:35:02 00: 0000000000 0:00:00.000 000 yes
2014-01-17 13:35:02 01: 0000010798 0:02:58.264 012 no
2014-01-17 13:35:02 02: 0000049208 0:12:53.719 056 yes *
2014-01-17 13:35:02 03: 0000087095 0:22:59.867 100 no
2014-01-17 13:35:02 CutFileSave()! CurrentDir: /DataFiles, PlaybackName: Nachrichten - 2014-01-17 10-57.rec, CutFileName: Nachrichten - 2014-01-17 10-57.cut
2014-01-17 13:35:02 CutFileSave()! CurrentDir: /DataFiles, PlaybackName: Nachrichten - 2014-01-17 10-57.rec, CutFileName: Nachrichten - 2014-01-17 10-57.cut
2014-01-17 13:35:03 Processing segment 2
2014-01-17 13:35:03 (* special mode for cut ending *)
2014-01-17 13:35:03 ----------------------------------------
2014-01-17 13:35:03 Source = 'Nachrichten - 2014-01-17 10-57.rec'
2014-01-17 13:35:03 Cut name = 'Nachrichten - 2014-01-17 10-57_temp.rec'
2014-01-17 13:35:03 File size = 786178048 Bytes (87120 blocks)
2014-01-17 13:35:03 Dir = '/DataFiles'
2014-01-17 13:35:03 PacketSize = 192
2014-01-17 13:35:03 KeepCut = yes
2014-01-17 13:35:03 CutStartBlock = 0, BehindCutBlock = 49208
2014-01-17 13:35:03 CutStartPos = 0, BehindCutPos = 444052992
2014-01-17 13:35:03 ReadCutPointArea()
2014-01-17 13:35:03 ReadCutPointArea()
2014-01-17 13:35:03 PatchRecFile()
2014-01-17 13:35:03 PatchRecFile()
2014-01-17 13:35:03 FileCut()
2014-01-17 13:35:03 Cut file size: 444051456 Bytes (=49207 blocks)
2014-01-17 13:35:03 ReadFirstAndLastCutPacket()
2014-01-17 13:35:03 Cut start offset: 0 Bytes (=0 packets and 0 Bytes), Cut end offset: -1536 Bytes (=-8 packets and 0 Bytes)
2014-01-17 13:35:03 Real cut positions: Cut Start = 0, Behind Cut: 444051456
2014-01-17 13:35:03 --> Real cutting points guessed correctly!
2014-01-17 13:35:03 UnpatchRecFile()
2014-01-17 13:35:03 Patched Bytes: 0, 0, 0, 0, 0, 0, 0, 0
2014-01-17 13:35:03 PatchNavFilesSD()
2014-01-17 13:35:03 PatchInfFiles()

Wer noch ein bisschen mehr helfen möchte, kann (in denjenigen Fällen, wo es schiefgeht) zusätzlich folgendes machen:

• das TAP 'TMSTelnet' auf dem Receiver installieren und starten
• mit einem Computer, der eine LAN-Verbindung zum Topf hat, die Eingabeaufforderung öffnen und 'telnet 192.168.xx.yy' <Adresse vom Topf> eingeben
• als Benutzername 'root' nehmen, Passwort wird nicht benötigt
• Nun die zu testende MC-Version starten, und einen Testschnitt durchführen. Auf der Konsole erscheinen währenddessen permanent ausfühliche Debugging-Informationen.
• Sobald nun der Absturz auftritt, endet die Ausgabe. Die letzten ca. 5-10 Zeilen, die dann auf dem Bildschirm stehen, können weiter dabei helfen, einzugrenzen an welcher Stelle das Problem liegt.

Ich freue mich auf eure Tests bzw. eure Rückmeldungen...

Der Start von Telnet gelingt mir am Laptop nicht,

Muss ich zuerst in ein bestimmtes Verzeichnis wechseln? Der Befehl wird nicht gefunden

[FireBird]

Telnet gibt es zwar als Windows-Komponente, wird aber standardmäßig nicht installiert. Du kannst aber auch putty verwenden.

[super-mentor]

Nein. Der Schnittvorgang erfolgt auf Dateisystem-Ebene. Das ist mit NTFS nicht möglich.

Schneiden ohne NAV geht aber theoretisch schon. Mit dem MC jedoch nicht, da dieser für seine Oberfläche (Anzeige der Spielzeit und der Schnittmarker) die NAV verwendet.
Die interne Schnittfunktion des Receivers kann das aber.
Und theoretisch sollte es das TAP StPbTools ebenfalls können. Probiere das gern mal aus, und berichte hier, was dabei herausgekommen ist (am besten mit Log).

Danke für diesen Tipp. StPbTools werde ich noch testen, sowie Zeit dafür.

@Wolfman: Danke für den Tipp für das Tool TSDoctor. Das ist ein tolles Programm und es zeigt die gewünschten Ergebnisse, wenn es auch durch die Automatiken viel Zeit benötigt.

Ich werde weiter berichten.

[chris86]

Danke Fritzcat, das reicht schon als Info.
Es ist äußerst interessant, wie unterschiedlich die Anzahl der aus der inf gelesenen Bytes in der Log ist:

Mal sind es optimistische 499572 von 132636 Bytes, mal nur 712 von 132636 Bytes. Da muss irgendwo der Fehler liegen...

(Bei mir steht da immer 132632 von 132632 Bytes)

Und für alle, die Ahnung von C haben. DAS ist der Code:

Code: Alles auswählen

  byte                  Buffer[INFSIZE];

  //Clear the buffer
  memset(Buffer, 0, INFSIZE);

  //Read the source .inf
  HDD_TAP_GetCurrentDir(CurrentDir);
  TAP_SPrint(AbsSourceInfName, "%s%s/%s.inf", TAPFSROOT, CurrentDir, SourceFileName);
  f = fopen(AbsSourceInfName, "rb");

  fseek(f, 0, SEEK_END);
  fs = ftell(f);
  rewind(f);
  ret = fread(Buffer, 1, INFSIZE, f);
  fclose(f);
  TAP_SPrint(LogString, "PatchInfFiles(): %u / %u Bytes read.", ret, fs);

Wie kann es sein, dass da so verquere Werte rauskommen???

[FilmFan]

Wie ist INFSIZE definiert?

[chris86]

Wie ist INFSIZE definiert?

Dürfte eigentlich noch nichtmal eine Rolle spielen - aber wenn du schon fragst: INFSIZE=499572

[FilmFan]

Dürfte eigentlich noch nichtmal eine Rolle spielen - aber wenn du schon fragst: INFSIZE=499572

Das spielt sehr wohl eine Rolle, weil Du den Wert als maximale Größe bei fread angibst, und das sagt auch das LOG an einer Stelle: "PatchInfFiles(): 499572 / 132636 Bytes read.".

Allerdings bleibt natürlich die Frage, warum ftell einen anderen Wert liefert. Zum Testen würde ich aber mal den Wert von INFSIZE und den Rückgabewert von ferror(f) nach fread ausgeben. Außerdem würde ich die ersten Bytes der eingelesenen Daten auf "TFrc" testen.

[chris86]

Da die Datei aber nur 132 kB groß ist, darf er auch nicht mehr lesen. So ist zumindest das fread von C definiert.
TAP_HDD_Fread() zeigt hier falsches Verhalten: Der Rückgabewert ist immer so groß wie die maximale Lesemenge. (Ich weiß jedoch nicht, ob nur der Wert falsch ist, oder tatsächlich zu viel gelesen wird).
Deshalb bin ich also auf das normale fread() gewechselt. Und dieses liest nun nur 712 B - was wiederum auch verkehrt ist!

[FireBird]

Rund ein halbes MB am Stack reservieren, ich glaube, da gab es was.... Versuche Buffer einmal dynamisch zu allokieren.

[chris86]

Rund ein halbes MB am Stack reservieren, ich glaube, da gab es was.... Versuche Buffer einmal dynamisch zu allokieren.

Uff, damit hat er ein Problem!!??
Da wäre ich ja nie im Leben drauf gekommen!
Aber es würde alles erklären

Das ist jetzt aber wichtig:
1.) Bis wie viel darf man denn? Doch wohl nicht nur die 712 Byte, oder!?
2.) Gilt die Grenze denn pro Array, oder für alle Stackvariablen gemeinsam?
(-> für die Australier muss ich nämlich zusätzlich noch 2 Arrays mit je 198528 Byte reservieren. Und hab die bisher auch auf den Stack gepackt. Dort drüben scheint es bisher aber zu funktionieren...)
3.) In diesem konkreten Fall brauche ich ja gar nicht unbedingt so viel Speicher. Es reicht die Menge, die dein DecodeInfHeader() maximal auswertet. - Die Vorschaubilder werden da ja vermutlich nicht dekodiert.
Weißt du zufällig, wie viel Speicher so ein InfHeader maximal haben kann?
Oder wie ich das rausfinde? (die unterschiedlichen Geräte haben da ja geringfügige Unterschiede...

Oh, und
4.) Gibt es für jedes TAP einen eigenen Stack, oder teilen die sich den auch noch!?
(Dann wäre das sogar wieder eine neue Erklärung für das V!deotext-Problem. Vllt. verbraucht dieses TAP einfach viel Speicher^^)

[Wolfman]

Danke für Deine Mühe, sobald mal wieder ein paar Aufnahmen eh zum Löschen anstehen , teste ich wieder.

[Wolfman]

@Wolfman: Danke für den Tipp für das Tool TSDoctor. Das ist ein tolles Programm und es zeigt die gewünschten Ergebnisse, wenn es auch durch die Automatiken viel Zeit benötigt.

.

Bitte gerne - auf meiner (etwas über dem Aldiniveau ausgestatteten ) Kiste rennt es wie Sau
Die Automatiken können übrigens ja auch einzeln aus bzw. eingeschaltet werden.

[FireBird]

Aber es würde alles erklären

Ist nur eine Idee und deshalb schicke Fritzcat eine Testversion, bevor Du die Sektkorken knallen lässt.

1.) Bis wie viel darf man denn? Doch wohl nicht nur die 712 Byte, oder!?

Ich kenne keinen fixen Wert und der wird auch von der Art der Nutzung des Topfes abhängen.

2.) Gilt die Grenze denn pro Array, oder für alle Stackvariablen gemeinsam?

Wenn es wirklich ein Stack-Problem ist, dann für die Summe aller lokalen Variablen einer Funktion.

3.) In diesem konkreten Fall brauche ich ja gar nicht unbedingt so viel Speicher.

Wenn die Funktion nicht Tausend Mal pro Sekunden aufgerufen wird, stört ein TAP_MemAlloc()/Free() auch nicht.

Weißt du zufällig, wie viel Speicher so ein InfHeader maximal haben kann?
Oder wie ich das rausfinde? (die unterschiedlichen Geräte haben da ja geringfügige Unterschiede...

Bisher habe ich nur Unterschiede in der Transponder-Info der unterschiedlichen Tuner-Typen gesehen (S, C, T) und die liegen im Byte-Bereich (4 oder 8 oder so). Zur Grösse, siehe hier.

/Edit 4: Für jeden Thread gibt es einen Stack und alle TAPs laufen im selben Thread.