Dateierkennung bei Drag&Drop in TSD-Fenster

[tsduser]

Ein kleines Problem mit dem Doctor aergert mich, seit ich meinen Fernseher ueberredet habe, Aufnahmen unverschluesselt abzuspeichern:

Die erstellten .srf-Dateien (Samsung, F-Modell 2013) werden bei Drag-and-Drop ins TSD-Fenster nicht erkannt und somit nicht geoeffnet. Wenn ich sie nach .ts umbenenne, geht's problemlos.

OK, jetzt koennte ich die Dateien alle vor der Bearbeitung mit dem Doc umbenennen, aber die Problemursache im TSD-Oeffnungsdialog sehe ich darin, dass
a) beim Oeffnen ueber Datei->Öffnen alles super klappt
b) beim D&D von MEHR als einer .srf-Datei auch alles klappt

Auf b) kam ich, weil die chunk.-Dateien eines anderen Receivers beim D&D in den Doc immer sauber bearbeitet wurden.

Deswegen vermute ich, dass da beim Oeffnen irgendwie unterschiedlich gearbeitet wird, ob man nun EINE oder MEHRERE Dateien in den Doc wirft.

Fuer mich persoenlich waer's echt super, wenn man das Verhalten angleichen koennte (natuerlich so, dass die Erkennung auch mit nur EINER Datei funktioniert  ).

Vielen Dank im Voraus, wenn's klappen sollte, aber auch sonst fuer den TSD in seinem jetzigen Zustand.

[peterfido]

a) beim Oeffnen ueber Datei->Öffnen alles super klappt

Hallo,

wo kommt das eine Ö von Öffnen her? 

Ansonsten kann ich leider nicht weiterhelfen. Da es mit mehreren Dateien und unter Datei>Öffnen  geht, braucht es auch keine Tricks, die ich vorschlagen könnte.

[tsduser]

Das "Ö" steht so im Programmdialog. Die anderen Umlaute sind Freitext ;-)

Ansonsten hast Du leider mein Anliegen komplett missverstanden.
Ich benoetige keine "Tricks", da ich selbst bereits verschiedene Umgehungen des Verhaltens beschrieben habe.
Mir ging es darum, darauf hinzuweisen, dass der TSD beim Oeffnen von Dateien per Drag & Drop bei bestimmten (oder auch nur bei unbekannten) Dateinamenserweiterungen nicht wie erwartet funktioniert, bzw. ein inkonsistentes Verhalten zeigt.

PS1:
Beim D&D einer einzelnen .srf-Datei in den "Öffne gesplittet"-Dialog klappt's auch wie erwartet.
PS2:
Ich kann auch (weiter) mit den o.a. Umgehungen leben, und werde ganz sicher nicht alle paar Tage einen Bumper absetzen, wann denn "endlich" eine Loesung implementiert wurde.
PS3:
Beim Oeffnen ueber's Menue (Klicken oder "O") kommt, falls das zuletzt verwendete Verzeichnis nicht mehr existiert, erst fuer ein paar Sekunden eine diesbezuegliche Fehlermeldung.

[peterfido]

Hallo,

alles gut. Ich habe Dein Anliegen schon verstanden. Deswegen benötigst Du ja auch keine "Umgehungstricks". 

zu PS3: Welches Betriebssystem nutzt Du? Kommt die Meldung für ein paar Sekunden oder nach ein paar Sekunden?

PS1: Umlaute kann ich besser / flüssiger lesen als Kreuzworträtsel-Font. Deswegen ist mir auch gleich Dein Ö aufgefallen.

[tsduser]

Kleiner Nachtrag:
OS siehe unten (Win10Pro-x64); die Meldung "scheint" fuer mich sofort zu kommen und *bleibt* ein paar Augenblicke.

Dafuer eine weitere Animositaet beim Oeffnen von Dateien:
Auch bei "Öffne Datei gekürzt" werden "Alle unterstützten Streamformate" angezeigt. Dabei ebenfalls "ALI (*.dvr)". Nur leider funktioniert das gekuerzte Oeffnen so nicht, denn die .dvr-Datei ist ja nur eine kleine Textdatei, die selbstverstaendlich keine PIDs enthaelt, und somit beim verkuerzten Oeffnen auch nicht als Transport Stream erkannt wird.

Des Weiteren habe ich bei etlichen Dateien in letzter Zeit das Problem, dass offenbar das Stream-Ende nicht korrekt ver- bzw be-arbeitet wird. Erst laufen alle Scans sauber durch; auch die "Programmübersicht (EPG)" wird kurz angezeigt sowie die "Aufnahme-Details" gefuellt, aber statt der Stream-Anzeige dreht "Windows am Rad" fuer ein paar Sekunden. Offenbar dauert es so seine Zeit, bis das Log-Schreiben endlich abbricht, während vom Datei-Ende her ein Packet nach dem anderen mit "Resync"-Fehlermeldung abgeklappert wird.

Soweit ICH (und der TS Packet Viewer) das erkennen kann, ist das letzte Packet tatsaechlich nicht komplett in der Datei:

Code Auswählen Erweitern

[...]
EB63DF30 21 38 CB BC │ FE 07 F0 1C │ F7 E4 F5 C9 │ EB 7B C6 10  !8˼þ•ð∟÷äõÉë{Æ►
EB63DF40 41 88 0C CC │ AB 55 E7 BF │ CA AA CB BC │ F9 08 22 56  Aˆ♀Ì«Uç¿ÊªË¼ù◘"V
EB63DF50 BC F9 F5 79 │ E0 E9 3F 46 │*47*01 98 3B │ 49 00 FF FF  ¼ùõyàé?FG☺˜;I.ÿÿ
EB63DF60 FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
EB63DF70 FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
EB63DF80 FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
EB63DF90 FF FF FF FF │ FF FF FF FF │ FF FF FF FF │ FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
EB63DFA0 FF FF FF FF │ FF FF A9 A6 │ B3 2A 38 D4 │ 58 74 6A 0F  ÿÿÿÿÿÿ©¦³*8ÔXtj☼
EB63DFB0 41 FD 29 F0 │ 80 D8 D6 D9 │ B5 B4 19 56 │ C1 ED AB 54  Aý)ð€ØÖÙµ´↓VÁí«T
EB63DFC0 75 F1 11 CE │ 6E D9 E4 BE │ BB DF 6B 34 │ 52 CD 2B 9D  uñ◄ÎnÙä¾»ßk4RÍ+
EB63DFD0 2A F1 9A B1 │ C2 0C 76 B3 │ 2B 86 AC FD │ AE 2B 59 95  *ñš±Â♀v³+†¬ý®+Y•
EB63DFE0 65 8E 8B 14 │ 40 E5 53 2B │ 6C B2 4C 9A │ 85 0B 9B 22  eŽ‹¶@åS+l²Lš...♂›"
EB63DFF0 2B 19 5E 15 │ A4 57 3C 5C │ 7A DB 37 5D │ C3 25 BA 0D  +↓^§¤W<\zÛ7]Ã%º♪

und im Abstand von 0x45 (=029d2400-029D23BB) Packets vom Dateiende finden sich wirklich 20 "ueberfluessige" Bytes, aber ansonsten ist der Stream (auch fuer den Packet Viewer) voellig sauber...

Liesse sich dieses "Problem" moeglicherweise im Doc behandeln, auch wenn offenbar eher der Receiver beim letzten geschriebenen Block seine Daten falsch schreibt?
Selbstverstaendlich sollte eigentlich ja der Receiver eben keinen Mist schreiben, aber fuer den eine Firmware-Korrektur zu erhalten, sehe ich als aussichtsloses Wunschdenken an, da ja auch die Dateiwiedergabe in keine sichtbaren Schwierigkeiten laeuft.
Dafuer ist das fruchtlose Suchen (und das Vollschreiben des Logs) schon eher ein Problem im Doc...

(Im Logausschnitt habe ich nur jeweils "identische" Bloecke gekuerzt. Die verbleibenden Reste sollten zeigen, welche Werte sich dazwischen veraendern.)

Code Auswählen Erweitern

Ali file format 3.0 detected
File [0] packets: 0 - 22846720
File [1] packets: 22846720 - 43852800
Ali file format 3.0 detected

Opening file Z:\8750_PB\[TS]2016-08-15.01.10.08-kabeleins-InSachenHenry-97\info3.dvr
Multiple files: Merging virtually
File 1 : Z:\8750_PB\[TS]2016-08-15.01.10.08-kabeleins-InSachenHenry-97\000.ts
File 2 : Z:\8750_PB\[TS]2016-08-15.01.10.08-kabeleins-InSachenHenry-97\001.ts

OS: Windows 10 Build 10586 x64
TSDoctor.exe V 2.0.61 (Build 04227F)
Instance     : 0
System memory: 7,91 GB / Free: 5,75 GB
Used memory  : 166,14 MB
Intel(R) HD Graphics (DISPLAY1) igdumd32.dll 9.17.10.4229
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]
Supported Mpeg video filter found : [LAV 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 : 6189 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: 250 channels, version 16.11.22

File size: 8244326400
Packets  : 43852800

TS  ERROR  : Packet 029D23FD with 168 missing bytes

Resync found for packet 029D23FE with Offset: -168
Found 2 fill packets at end
TS  ERROR  : For PID 0000, invalid packet 029D23BA! Error: sync_byte_error

Resync found for next packet 029D23BB with Offset: 20
Broadcast standard selected: None
Broadcast standard detected: DVB
PES WARNING: PID 023E DataAlignmentIndicator = 0
TS  ERROR  : For PID 0000, invalid packet 029D23BA! Error: sync_byte_error

Resync found for next packet 029D23BB with Offset: 20
TS  ERROR  : For PID 0000, invalid packet 029D23BA! Error: sync_byte_error

Resync found for next packet 029D23BB with Offset: 20
TS  ERROR  : For PID 0000, invalid packet 029D23BA! Error: sync_byte_error

Resync found for next packet 029D23BB with Offset: 20
TS  ERROR  : For PID 0000, invalid packet 029D23BA! Error: sync_byte_error

Resync found for next packet 029D23BB with Offset: 20
TS  ERROR  : For PID 0000, invalid packet 029D23BA! Error: sync_byte_error

Resync found for next packet 029D23BB with Offset: 20
TS  ERROR  : For PID 0000, invalid packet 029D23BA! Error: sync_byte_error

Resync found for next packet 029D23BB with Offset: 20

17    (0011): 1%   = SDT,BAT,ST
573   (023D): 68%  = MPEG2 Video (PES_StreamID E0 = Video_Stream_0) {00000100} [PCR,PTS,DTS]
578   (0242): 6%   = Teletext (PES_StreamID BD = Private_Stream_1) {10022CE7} [PTS][PESLength]
18    (0012): 19%  = EIT,ST
574   (023E): 4%   = MPEG1 Audio (PES_StreamID C0 = Audio_Stream_0) {FFFDA400} [PTS][PESLength]
16    (0010): 2%   = NIT,ST
0     (0000): 0%   = PAT
263   (0107): 0%   = PMT
401   (0191): 0%   = Private Stream [PCR]
402   (0192): 0%   =
403   (0193): 0%   =
407   (0197): 0%   =
404   (0194): 0%   =
408   (0198): 0%   =



Selecting PMT with PID 263 (0107) at position 000003BC
CRC OK!
Deleting PMT entry: PID 1711  (06AF) type 5 = ITU-T Rec. H.222.0 | ISO/IEC 13818-1 private sections

0.
  stream_type              : 2 = ITU-T Rec. H.262 | ISO/IEC 13818-2 Video | ISO/IEC 11172-2 constr. parameter video stream
  elementary_pid           : 573 (023D)
  ES_info_length           : 3

1.
  stream_type              : 3 = ISO/IEC 11172 Audio
  elementary_pid           : 574 (023E)
  ES_info_length           : 9

2.
  stream_type              : 6 = ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data (Teletext)
  elementary_pid           : 578 (0242)
  ES_info_length           : 15

TS  ERROR  : For PID 0000, invalid packet 029D23BA! Error: sync_byte_error

Resync found for next packet 029D23BB with Offset: 20
TS  ERROR  : For PID 0000, invalid packet 029D23FE! Error: sync_byte_error
TS  ERROR  : Packet 029D23FD with 188 missing bytes

Resync found for packet 029D23FE with Offset: -168
TS  ERROR  : For PID 0000, invalid packet 029D23BA! Error: sync_byte_error

Resync found for next packet 029D23BB with Offset: 20
TS  ERROR  : For PID 0000, invalid packet 029D23B9! Error: sync_byte_error

Resync found for next packet 029D23BA with Offset: 208
TS  ERROR  : For PID 0000, invalid packet 029D23B8! Error: sync_byte_error

Resync found for next packet 029D23B9 with Offset: 396
TS  ERROR  : For PID 0000, invalid packet 029D23B7! Error: sync_byte_error

Resync found for next packet 029D23B8 with Offset: 584
TS  ERROR  : For PID 0000, invalid packet 029D23B6! Error: sync_byte_error

[...]

Resync found for next packet 029D22FF with Offset: 35364
TS  ERROR  : For PID 0000, invalid packet 029D22FD! Error: sync_byte_error

Resync found for next packet 029D22FE with Offset: 35552
TS  ERROR  : For PID 0000, invalid packet 029D22FC! Error: sync_byte_error

Resync found for next packet 029D22FD with Offset: 35740
TS  ERROR  : Too many entries. Ignore further invalid packet messages.

Resync found for next packet 029D22FC with Offset: 35928

Resync found for next packet 029D22FB with Offset: 36116

[...]

Resync found for next packet 029CAF1B with Offset: 5612948

Resync found for next packet 029CAF1A with Offset: 5613136

Resync found for next packet 029CAF19 with Offset: 5613324
Log too long, aborted.


Vielen Dank schon mal im Voraus, falls es implementier-/korrigierbar sein sollte, ansonsten bleibt der Dank fuer den Doc an sich weiter bestehen!

[Cypheros]

Kannst Du mir eine Beispieldatei zur Verfügung stellen? Dann könnte ich versuchen das nachzuvollziehen und zu fixen.

[tsduser]

Hallo,

klar doch!

Schickst Du mir ftp-Zugangsdaten per PN oder Mail, bitte?

Die Datei aus dem o.a. Beispiel habe ich zwar nicht mehr, dafuer aber einen ca. 128MB-Stream, der das Endproblem aufweist, und an dem sich der Doc (zumindest bei mir reproduzierbar) ver-log-t.

Hier wird Packet #745309 offenbar ohne Sync-Byte 0x47 gemeldet, ist dafuer aber augenscheinlich die Fortfuehrung von Packet #745308. Ich tippe mal, dass das Ende von #745308 ueberschrieben wurde, denn Details zu "Naruto Shippuden" haben in einer Aufnahme vom NDR eigentlich nix zu suchen...

Ob der "Anfang" von Packet #745308 "passt" vermag ich nicht zu sagen. Was genau der Receiver da falsch macht (und evtl. schon "frueher" im Stream), weiss ich leider auch nicht, da mir die Kenntnisse/Werkzeuge zur schluessigen ES-Analyse fehlen.

Wenn ich aber die Ausgabe des Packet Viewers zu interpretieren versuche, kann ich mich der Vermutung nicht entziehen, dass das "Stream-Ende" zu einem ganz anderen Sender gehoert...
Ab der Nahtstelle kommen keine Packets mehr zu den vorher verwendeten Stream-IDs 0xA29-0xA2C (A/V), sondern ploetzlich stattdessen 0x21F-0x224.

Noch ein Hinweis, dass die Ermöglichung der Verwendung von "Öffne verkürzt" auch für ALi-Streams echt hilfreich waere. 

[Cypheros]

FTP ist gut, hab Dir ne PM geschickt. Sag kurz Bescheid, wenn der Upload fertig ist. Schau ich mir dann an.

[tsduser]

*Daumen hoch*!
Die neue 2.0.62 verhaelt sich WESENTLICH toleranter bei so endfehlerbehafteten Streams wie bei meinem Receiver.
Das Riesen-Log-Problem ist damit fuer mich behoben.

Vielen Dank!

[Cypheros]

Ja, Deine Aufnahme hatte ein paar Besonderheit, die mir einiges Kopfzerbrechen bereitet haben. Am Ende sind zwei Pakete unvollständig. Eins besteht aus 84 Bytes, eins aus 104 Bytes und ergibt damit genau die Größe eines Pakets. Kurzum, wenn der TS-Doctor die Pakete von hinten nach vorne durchsucht hat, um zum Beispiel den letzten PCR zu finden, ging das in die Hose. Sollte nun keinen Ärger mehr machen.