TSD hängt sich beim Kopieren/Bereinigen auf

[Gundolf]

Hallo,

Ich hab seit 2 Tagen ein Problem das mich fertig macht.

Computer:
Motherboard: Asus Z170-A
Intel Core i7-6700K
Arbeitsspeicher: 32634 MB (DDR4 SDRAM)
Grafikkarte: Intel(R) HD Graphics 530  (1 GB)
Samsung SSD System
usw.
Syno NAS 2x 2TB WD
=============

Windows 7 64bit
TS-Doctor 2.0.80

Die Aufnahmen liegen grundsätzlich auf der 2ten WD-Platte (NAS). Bereingt und geschnitten wird dann auch von da aus über Windows 7 (TSD). Die fertigen Files landen also direkt auf die erste WD-Platte (NAS). Das mach ich schon seit Jahren so und klappte auch immer wunderbar. Aber seit 2 Tagen nicht mehr ... und ich hab keinen Schimmer woran das liegt. Wenn ich also mit TSD von Windows 7 aus auf irgendeine TS-Datei vom NAS (2te Platte) zugreife, die Schnittpunkte festlege, und dann den Speichervorgang auf die erste Platte starte, stoppt die Datenübertragung nach wenigen Sekunden. Der Fortschrittsbalken hängt fest. Das geht soweit das bis TSD aufhängt. Hin und wieder gelingt es mir aber den Vorgang abzubrechen. Und jedes Mal wird mir vom TSD gemeldet die Platte wäre voll. Da sind aber noch knapp 200GB frei.
Nun könnte man ja meinen das Netzwerk hat ne Macke. Aber wenn man von HDD2 (NAS) auf HDD1 (NAS) oder umgekehrt, mit irgendeinen Windows Dateimanager (zB. Total Commander) Dateien kopiert, läuft der Transfer mit 100-120 MB/s. Ob nun mit vielen kleineren Dateien (mit 170 getestet) oder einer 17GB Datei, der Datentransfer funktioniert einwandfrei.
Warum zum Henker schmiert mir aber der TSD ab ?

Wenn man allerdings vom NAS (HDD1 oder 2) mit dem TSD auf die PC-HDD schreibt, klappt´s ohne Probleme. Und andersrum auch (PC -->NAS). Nur NAS-HDD2 -->NAS-HDD1 macht diese Probleme. Und jahrelang ging das bisher gut. Hat hier irgendjemand eine Ahnung was die Ursache für den Fehler sein könnte, oder irgendwelche Tipps für mich ?

Gruß Gundolf

[Cypheros]

Zeigt der Anwendungs-Report unter Hilfe/Anwendungs-Report irgendwelche Fehler?

[Gundolf]

Außer den normalen Statusmeldungen ist da nichts besonderes zu lesen.

Bin gerade dabei die Netzwerkkarte zu tauschen, mal sehen was danach passiert.

[Gundolf]

Weder mit der Onboardnetzwerkeinheit noch mit einer PCI-E Netzwerkkarte ist der Fehler (TSD) behoben. Der Fehler tritt sogar in einer Windows 7 VM unter Linux auf. Ich habe auch mal testweise Videoredo, Machete und Avidemux installiert. Das sind ja auch alles Schnittprogramme/Tools. Und wieder habe ich den gleichen Test gemacht. Unter Windows 7 mit den genannten Programmen jeweils auf HDD2 vom NAS zugegriffen, Schnittpunkte festgelegt, und direkt auf HDD1 gespeichert. Hat 100% funktioniert. Tja, und mit dem TSD funktioniert das nicht. Da wird nach wenigen Sekunden der Datentransfer von HDD2 nach HDD1 gestoppt/blockiert (umgekehrt ebenfalls). Das sehe ich am Netzwerkmonitor. Und deswegen hängt dann der TSD und zeigt irgendwann an "Kein Speicherplatz vorhanden", oder er schmiert ab.

Für mich ist das ein TSD-Fehler. Vielleicht kann das mal jemand hier aus dem Forum nachstellen.

[Mam]

na ja, direkt nachstellen kann ich dieses doch recht extreme Verhalten nicht. Ich muß Dir aber insofern beipflichten, dass der Doc Dateien "anders" öffnet, als andere Programme. Das führt bei mir reproduzierbar dazu, dass er öfters meint, eine Datei wäre leer, obwohl sie doch ein paar Gigs hat und nur der lokale Cache nicht aktualisiert worden ist. Klickt man anschließend dieselbe (leere) Datei mit z.B. VLC an, so kann der Doc sie danach auch problemlos öffnen und meckert nicht mehr rum.

Da sind offensichtlich ein paar Bits bei der "Open()" Funktion abhanden gekommen, aber Scheffe glaubt mir ja nicht... SNIEF 

[Gundolf]

... , dass der Doc Dateien "anders" öffnet, als andere Programme. Das führt bei mir reproduzierbar dazu, dass er öfters meint, eine Datei wäre leer, obwohl sie doch ein paar Gigs hat und nur der lokale Cache nicht aktualisiert worden ist. Klickt man anschließend dieselbe (leere) Datei mit z.B. VLC an, so kann der Doc sie danach auch problemlos öffnen und meckert nicht mehr rum.

Da sind offensichtlich ein paar Bits bei der "Open()" Funktion abhanden gekommen, aber Scheffe glaubt mir ja nicht... SNIEF 

DOCH, das sollte "Scheffe" aber glauben. Denn etwas ähnliches passiert mir manchmal auch !!! TSD zeigt die TS-Datei im Öffnen-Dialog an, man wählt sie aus und nichts passiert, als wenn die Datei nicht da wäre. Dann öffne ich die Datei mit irgendeinem Player, schließe sie wieder, und dann öffnet auch der TSD die Datei ordnungsgemäß.

Also .... da ist doch irgendwo der Wurm im TSD drinne.

[Mam]

Also .... da ist doch irgendwo der Wurm im TSD drinne.

Na ja, "Wurm" wäre mir zu stark. Es gibt halt verschiedene Methoden zum Öffnen von Dateien, die unterschiedliche Nebeneffekte haben. Aus irgendwelchen Gründen benutzt der Doc etwas, was im LAN Betrieb nicht wirklich als "verlässlich" anzusehen ist.
Vielleicht braucht er aus einem anderen Grund diese Methode?
Vielleicht ist das Ganze aber auch nur in einem seiner verwendeten Toolkits vergraben und er selber hat gar keinen Einfluß darauf.
Keine Ahnung.

[Gundolf]

Ich hoffe sehr das "C. " eine Lösung für dieses Problem findet. Ich kann momentan nicht mit dem TSD arbeiten.

[Cypheros]

Das Schreiben läuft über die normale Windows-API-Funktion WriteFile.

In der nächsten Version packe ich noch die Windows-Fehlermeldung mit in den Fehlerdialog und ins Log. Vielleicht bringt das Licht in die Sache.

[Mam]

Das Schreiben läuft über die normale Windows-API-Funktion WriteFile.

Er hat mich (mal wieder) nicht richtig verstanden 

Das Problem entsteht beim Öffnen, nicht erst beim Schreiben.

Also irgendwas mit OpenFile() oder einer seiner hunderten von Überladungen. Du machst irgendwie ein OpenFile() und dann ein StatFile() (oder auch nur FileStat()? keine Ahnung, ist ja Dein Programm).
Auf jeden Fall erhälst Du dabei veralterte Daten (z.B. "Länge = 0") und brichst daraufhin schon ab, bevor es überhaupt ans Eingemachte gehen könnte.
VLC und andere Programme machen einfach ein OpenFile() und DANACH dann ein Stat(). Dann ist die Welt in Ordnung und die gelesenen Daten stimmen mit der Realität überein.
Bei lokalen Dateien fällt das nicht so auf, denn da flusht das OS recht häufig. Bei Dateien im LAN ist Windoof aber knauserig und verfährt nach dem Motto "Update nur wenn nötig".

[Cypheros]

Ich glaube, diesmal bist Du auf dem falschen Dampfer.

Die Fehlermeldung, dass die Platte voll ist, wird vom Schreib-Thread ausgeworfen, wenn es beim Schreiben irgendwelche Probleme gibt (egal welche). Die neue Version gibt nun differenziertere Auskunft.

Auch scheint das Lesen/Öffnen der Quelldatei zu klappen, da ja der Fortschrittsbalken losläuft für ein paar Sekunden. Das Problem liegt also vermutlich beim Schreiben, wenn der Schreibpuffer voll ist und die Daten auf die Platte geschrieben werden sollen.

[Mam]

Ich glaube, diesmal bist Du auf dem falschen Dampfer.

Na gut, dann sind das zwei unterschiedliche Probleme. Bei mir hakts eben beim ÖFFNEN ZUM LESEN (solange die Datei im LAN noch nicht zuende geschrieben ist, man also eine laufende Aufnahme anwählt).

Na ja, so geht Dir wenigstens die Arbeit nicht aus, durch den Urlaub musst Du ja erstmal wieder angelernt werden... 

[Cypheros]

Hab das Erstellen der Zieldatei nochmal überarbeitet, so dass entsprechende Fehlermeldungen angezeigt werden, wenn was bei CreateFile schief läuft.

[Gundolf]

Hier mal ein log.

Code Auswählen Erweitern

----------------------- Last Recording Log ----------------------

Opening file \\DISKSTATION\WD-2000gb_2\test.ts

OS: Windows 7 Build 7601 x64 Service Pack 1
OS language    : DE
Appl. language : German
TSDoctor.exe V 2.0.84 (Build 048320)
Instance     : 0
System memory: 30,93 GB / Free: 28,35 GB
Used memory  : 152,85 MB
Intel(R) HD Graphics 530 (DISPLAY1) nvumdshim.dll 22.21.13.8233
CPU type     : Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
CPU count    : 8
CPU usage    : 3%
Resolution   : 1920 x 1080 (32Bit) 96 DPI
Monitors     : 1
Supported TS source filter found  : TS Doctor FileSource (on)
Supported splitter filter found   : Haali Media Splitter, [LAV Splitter]
Supported audio filter found      : [LAV Audio Decoder], Microsoft DTV-DVD Audio Decoder
Supported Mpeg video filter found : [LAV Video Decoder], Microsoft DTV-DVD Video Decoder
Supported H264 video filter found : [LAV Video Decoder], Microsoft DTV-DVD Video Decoder
Supported video renderer found    : Video Renderer, Haali Video Renderer, Enhanced Video Renderer

Channel database : 6362 channels, 7 satellites [Thor 0.8°W, Astra 19.2°E, Astra 23.5°E, Astra 28.2°E, Astra 4.9°E, Hellas Sat 39°E, Hotbird 13°E]
Teletext database: 270 channels, version 17.4.27

File size: 4556759040
Packets  : 24238080

Scanning for PCR problem packets (start)
Found 1 fill packets at end
Scanning for PCR problem packets (end)
Broadcast standard selected: None
Broadcast standard detected: DVB

543   (021F): 88%  = H264 Video (PES_StreamID E0 = Video_Stream_0) {00000001} [PCR,PTS,DTS]
545   (0221): 6%   = AC3 Audio (PES_StreamID BD = Private_Stream_1) {0B771A40} [PTS][PESLength]
544   (0220): 6%   = AC3 Audio (PES_StreamID BD = Private_Stream_1) {0B773BF2} [PTS][PESLength]
260   (0104): 0%   = PMT
0     (0000): 0%   = PAT



Selecting PMT with PID 260 (0104) at position 00000044
CRC OK!

0.
  stream_type              : 27 = AVC video stream as defined in ITU-T Rec. H.264 | ISO/IEC 14496-10 Video
  elementary_pid           : 543 (021F)
  ES_info_length           : 3

1.
  stream_type              : 6 = ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data (AC3)
  elementary_pid           : 544 (0220)
  ES_info_length           : 16

2.
  stream_type              : 6 = ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data (AC3)
  elementary_pid           : 545 (0221)
  ES_info_length           : 16

PCR PID is 543 (021F)

searching for channel: SID=27114, TID=411, VPID=543
First video PTS is 6628272717 20:27:27.475
Last video PTS  is 7195243917 22:12:27.155

First PCR  is 1988459681700 20:27:26.655
Last PCR  is 2158546481095 22:12:26.166
Duration of video stream is 566955998 01:44:59.511
Video PCR to PTS difference -1178 ms
544   (0220): Delay to video stream = -697ms
545   (0221): Delay to video stream = -562ms

PID allocation
V :543   (021F)#####################################################################################################
A :545   (0221)####################################################################################################.
A :544   (0220)####################################################################################################.
  :260   (0104)#.##..####..#########....##.#.###.###.##....#.##.#.####.#.#.##.#..#..##...#######..#.###.##.#####.##.
  :0     (0000).#...#....##...###....###.##.#...#...#..#..##..##...#..##.....#.##.#...#.###....#..###..##.....#.#...

Video format: H264 1920x1088i/AR=16:9/25 fps/High@4.0
Colorimetry : ColourPrimaries=BT.709, TransferCharacteristics=BT.709, MatrixCoefficients=BT.709
Video format: Component
First I-Frame PTS at 20:27:28.315 [00:00:00.840]
First GOP = 15 frames : I424 B420 B422 P430 B426 B428 P436 B432 B434 P442 B438 B440 P448 B444 B446

AC3 6 channels: 18 times
Audio stream 1: AC3 5.1 48000Hz (DEU)
AC3 2 channels: 18 times
Audio stream 2: AC3 2.0 48000Hz (ENG)
Commercial search options: VA

No cutting


Cut in  at PCR: 00:00:00.000 (20:27:26.655)
Cut out at PCR: 01:44:59.511 (22:12:26.166)
First packet  : 0000013C
Last packet   : 0171D7FF
Using current PCR as start PCR

Starting at packet 0000013C PCR: 00:00:00.037 (20:27:26.692)
Error: Could not write all data to disk for file \\DISKSTATION\WD-2000gb\test_fixed.ts
       Write error at position 388529448 , wanted to write 12533208 bytes, but only 0 are.
       Free disk space on destination drive: 597669937152
       Error message: Der Vorgang wurde erfolgreich beendet

File sizes:
            \\DISKSTATION\WD-2000gb\test_fixed.ts 379.424 KB [CRC=E5BC0240]

---------- ABORTED ----------


---------  NAL Unit Type Statistics  ---------
Slices                 : 15398
    I-Slices           : 938
    P-Slices           : 4302
    B-Slices           : 10158
    SP-Slices          : 0
    SI-Slices          : 0
Data Partition A       : 0
Data Partition B       : 0
Data Partition A       : 0
IDR Picture            : 0
SEI                    : 30796
Sequence Parameter Set : 938
Picture Parameter Set  : 1199
AUD                    : 15398
End of Sequence        : 0
End of Stream          : 0
Filler                 : 961
Slices                 : 0
Seq. Param. Set Ext.   : 0

H264 filler data: 2,5% [netto]

Cutted packets at the beginning: 315
Cutted packets at the end: 0
Discarded packets (filler data): 57993 = 2,5% [brutto]
Discarded packets (not needed): 2593
Discarded invalid packets : 1

PID stream sizes
$021F:     357.207 KB
$0220:      29.668 KB
$0221:      29.668 KB

PID stream average bitrates
$021F: 0 bps
$0220: 0 bps
$0221: 0 bps

ERRORS : 1
WARNINGS : 0

Speed: 0,1 MBytes/sec
Duration: 02:01:55

-----------------------------------------------------------------



[Mam]

Code Auswählen Erweitern

Starting at packet 0000013C PCR: 00:00:00.037 (20:27:26.692)
Error: Could not write all data to disk for file \\DISKSTATION\WD-2000gb\test_fixed.ts
       Write error at position 388529448 , wanted to write 12533208 bytes, but only 0 are.
       Free disk space on destination drive: 597669937152
       Error message: Der Vorgang wurde erfolgreich beendet


Hmm, das erinnert mich stark an Probleme, die auftreten, wenn "Flow Control" nur einseitig aktiviert ist, auf Netzwerkkarte / Switch / NAS. Dann schreit der eine um Hilfe ("Stooooop! meine Puffer laufen voll!!!"), der andere ignoriert es bzw. bekommt die Nachricht gar nicht und plappert munter weiter.
Überprüf mal die Einstellungen auf allen beteiligten Geräten, ob an oder aus ist egal, Hauptsache ÜBERALL GLEICH.
(Flow Control kann nicht zusammen mit Jumbo Packets aktiviert werden!, da haben sich schon manche ein Ei mit ins Nest gelegt)