Jump to content

manchmal werden Aufnahmen nicht entschlüsselt


MaM

Recommended Posts

Kommt sporadisch vor, ist aber recht lästig.

Gerade eben wieder, 2 Episoden Bull hintereinander aufgenommen, die erste ist ok, die zweite verschlüsselt.

 

Wählt man den Kanal mit dem DVBViewer an, ist alles ok (zumindest ist es mir noch nie gelungen, das Problem damit nachzustellen) (* klar zeigt der auch nur einen schwarzen Bildschirm, wenn er Klient des DMS ist, aber wenn er selber die Tuner und die CIs anspricht gehts immer)

 

Nur der Mediaserver "vergißt" manchmal das CI anzusprechen (man sieht gar keinen Versuch am CI, es wird also nix abgewiesen oder so, es wird gar nicht probiert sagt mir mein LAN Protokoll).
 

Das Verhalten ist recht zufällig, mal geht es tagelang gut, dann gibts mal einzelne Ausfälle, vorgestern ging ein Sender gar nicht mehr (andere aber schon), also alles recht unsortiert und ohne Muster.

Es sind keine Updates eingespielt worden, keine Kanalsuche, gar keine Änderungen an der Hardware oder Konfiguration.

 

Nun weis ich nicht so recht, wo ich im Mediaserver gucken soll, bzw. wo sich eventuell eine aussagekräftige Fehlermeldung versteckt haben könnte ?

 

(Zusatzinfo: es erfolgt auch kein Retuning, der DMS speichert einfach die verschlüsselten Daten so ab, wie sie reinkommen. Das ist also anders, als wenn der Empfang gar nicht möglich ist und pro Minute ne neue Datei angelegt wird. Hier gibts nur eine, scheinbar heile, Datei und erst beim Reingucken merkt man, dass es leider nur ein Haufen Datenmüll ist)

Edited by MaM
Link to comment
vor 1 Stunde schrieb MaM:

der DMS speichert einfach die verschlüsselten Daten so ab, wie sie reinkommen.

 

Lässt vermuten, dass das CAM das Scrambling Flag im TS Header löscht, aber nicht entschlüsselt. Wäre es bei allen empfangenen Video/Audio-Paketen gesetzt, würde der Recorder versuchen, die Aufnahme neu zu starten.

 

Das Aufnahme-Log (falls aktiviert) könnte weitere Aufschlüsse geben. Die Angabe der beteiligten DVB-Hardware ist in solchen Fällen wichtig!

 

Link to comment
vor 1 Stunde schrieb Griga:

Das Aufnahme-Log (falls aktiviert) könnte weitere Aufschlüsse geben. Die Angabe der beteiligten DVB-Hardware ist in solchen Fällen wichtig!

Ja, hatte ich befürchtet ?

 

Die Hardware ist ganz einfach 2*OctopusNet mit jeweils 4 Tunern im eigenen LAN mit dem DMS.

Das Cam ist allerdings auf einem anderen Server und sehr weich. Aber wie gesagt, Messungen zeigen, am CAM kommt gar keine Anforderung vorbei, es schnarcht so vor sich hin.

 

Das Logfile ist "unauffällig", es sieht völlig normal aus. Wenn man "Glück" hat, sind ein paar Tonformatwechsel mit drin, das ist dann schon mal ein guter Hinweis, dass nicht dekodiert wurde. Aber sehr häufig ist es auch ganz harmlos aussehend, man merkt es erst, wenn man die Aufnahme öffnet (oder, wie ich, dem TSDoc zum Schnitte vorwirft, der bricht dann gnadenlos mit "dies Aufnahme ist verschlüsselt, Weiterbearbeitung nicht möglich" ab). Dann ist ma[m|n] natürlich am Fluchen.

 

Habe gerade ein paar Testaufnahmen laufen, im Moment passiert es (natürlich?) nicht ...

 

Theoretisch könnte es natürlich sein, dass einer der Tuner nicht funktioniert. Das ist aber sehr schwer auszuprobieren, da die OctopusNet Dinger die Tuner dynamisch vergeben. Ich muss mal ein paar Kisten mit DVBViewer beglücken und nacheinander immer einen Tuner mehr belegen...

 

Link to comment
vor 1 Stunde schrieb MaM:

Das Logfile ist "unauffällig", es sieht völlig normal aus. Wenn man "Glück" hat, sind ein paar Tonformatwechsel mit drin,

 

Wenn im Aufnahme-Log eine Formaterkennung verzeichnet ist, dann wurde auch (zumindest teilweise) entschlüsselt. Dafür ist nämlich das Lesen der Video/Audio-Header erforderlich, die in verschlüsselten Streams ebenfalls verschlüsselt sind.

 

Link to comment
vor 19 Minuten schrieb Griga:

 

Wenn im Aufnahme-Log eine Formaterkennung verzeichnet ist, dann wurde auch (zumindest teilweise) entschlüsselt. Dafür ist nämlich das Lesen der Video/Audio-Header erforderlich, die in verschlüsselten Streams ebenfalls verschlüsselt sind.

 

Ja, dachte ich mir schon. Aber diese Dinger stören mich weniger (da man sie im Vorfeld erkennen kann und sie meist auch nur bei wirklichen Empfangsstörungen auftreten). Schlimm sind eben die, die unter dem Radar bleiben.

Ich installiere gerade mal 8 PCs mit DVBViewer (na gut, ich installier nur einen und klone ihn ein paarmal ? ) um auszuschliessen, dass die Tuner kapput sind.

 

Link to comment
vor 8 Stunden schrieb MaM:

Gerade eben wieder, 2 Episoden Bull hintereinander aufgenommen, die erste ist ok, die zweite verschlüsselt.

 

Die sollten sich dann ja wegen Vorlauf/Nachlauf überlappen. Wenn die Aufnahme der 2. Episode startet läuft die erste inkl. Entschlüsselung ja noch. Eventuell kann dein System nicht parallel 2 Aufnahmen gleichzeitig entschlüsseln?

Link to comment
vor 15 Minuten schrieb HaraldL:

 

Die sollten sich dann ja wegen Vorlauf/Nachlauf überlappen. Wenn die Aufnahme der 2. Episode startet läuft die erste inkl. Entschlüsselung ja noch. Eventuell kann dein System nicht parallel 2 Aufnahmen gleichzeitig entschlüsseln?

Legitime Vermutung, aber leider nicht zutreffend. Ich habe schon häufiger mal 6 oder gar 10 Aufnahmen gleichzeitig laufen gehabt (bevor jemand nachrechnet und sich an den 8 Tuner stösst, allein die VU+ Box im Wohnzimmer hat noch 16 Tuner mehr...) ?, kein Problem damit.

 

Griga: der Klontest funktioniert leider nicht, die VMs haben Probleme mit der Wiedergabe und brechen den DVBViewer immer nach ein paar Minuten ab. Aber eben liefen 5 Aufnahmen parallel, alle ok (und entschlüsselt). Also muß ich weiterwarten, bis es wieder auftritt...

 

Edited by MaM
Link to comment
vor 8 Stunden schrieb VinoRosso:

Du kannst auch einfach im browser ein paar streams starten und falls du Android Geräte hast auch mit der App ein paar tuner belegen ?

Welch Hexenwerk ?

 

Mit "Apps" hab ichs so gar-nie-nicht ?

 

Aber die Aufnahmen gestern bewiesen ja schon mal, das zumindest die ersten 6 Tuner einwandfrei funktionieren, es hat also wirklich nur was mit der Entschlüsselung zu tun, es kommt mir fast so vor, als wenn der DMS (oder sein unterliegendes Treiberwerk) gar nicht erkennt, dass dieser Sender verschlüsselt ist und ihn als FTA behandelt (aka. NICHTS unternimmt, sondern nur die Daten abspeichert). Alle Aufnahmen heute Nacht waren aber wieder ok, also weiter warten.

 

 

Link to comment

Aaah, da hamwe ihn widda! (dachte schon, es passiert nicht mehr, aber man muss nur abwarten können ? )

 

Etwa 50 Aufnahmen sind problemlos gelaufen, dannn kam diese hier:

Es war die dritte Folge hintereinander, es wurde der erste Tuner benutzt (der nun wirklich einfach zu überprüfen ist, der geht garantiert).

 

Im Log erkenne ich absolut nix Auffälliges, aber vielleicht schaut mal der Scheff drüber und entdeckt ein mir verborgenes Detail darin?

 

 

Unforgettable - Sturmtief.log

Unforgettable - Sturmtief.txt

Link to comment

Das Log zeigt, dass nicht entschlüsselt wurde, weder Video noch Audio, weil keine Formaterkennung stattgefunden hat. Normalerweise steht da sowas wie

 

06:19:50 / 00:00:00 (~ 0,00 MB) Start Recording
06:19:51 / 00:00:01 (~ 0,80 MB) PID 6510: H.264 Video, 16:9, 1280x720, 50 fps
06:19:51 / 00:00:01 (~ 0,80 MB) PID 6520: MPEG Audio Stereo, 48 khz, 256 kbps
06:19:51 / 00:00:01 (~ 0,80 MB) PID 6522: AC3 Audio Stereo, 48 khz, 448 kbps

 

Link to comment

Sehr schön, nun kommen wir zur Kernfrage dieses Threads: WARUM ??? (und wie verhindere ich, dass es passiert?)

 

(allerdings gebe ich zu, die "Beweise" bislang sind dürftig, gibts da noch geheime Debug Logs, die man aktivieren könnte um mehr erkennen zu können?)

 

Oder andesrum: Wenn da kein Format erkannt wird, warum reagiert der DMS nicht und nimmt einfach immer weiter auf, als wenn nix wäre?

 

Edited by MaM
Link to comment

Dein System der Entschlüsselung arbeitet offenbar nicht zuverlässig. Ich wüsste nicht, was man im DVBViewer oder DMS daran machen könnte. Außerdem denke ich, dass ein detaillierter Support für das, was du da machst, hier nicht drin ist.

 

vor 28 Minuten schrieb MaM:

Oder andesrum: Wenn da kein Format erkannt wird, warum reagiert der DMS nicht und nimmt einfach immer weiter auf, als wenn nix wäre?

 

https://www.dvbviewer.tv/forum/topic/62135-manchmal-werden-aufnahmen-nicht-entschlüsselt/?do=findComment&comment=479339

 

Link to comment

Na ja, der DVBViewer erkennt die Situation ja und macht dann ein Retuning. Das geht dann eigentlich immer gut.

Bei den OctopusNet kommt es schon mal vor, dass ein Tunigversuch "daneben" geht und er nicht die richtige Frequenz trifft. Ein zweiter Anlauf hilft da ungemein.

 

Nur der DMS reagiert nicht genauso.

 

Ich bin fast der Meinung, dass Entschlüsseln hier gar nicht so das Hauptproblem ist, sondern das gar kein Signal empfangen wird. Allerdings enthält die Aufnahme laut Hexdump schon verschiedene Bytes (also nicht alles 00 oder FF), da wurde zumindest ETWAS empfangen.

 

Link to comment

Wenn kein Signal empfangen wird, gibt es auch keine Daten. Wo sollen die denn herkommen? Ein Retuning ist davon abhängig, ob überhaupt irgendwelche Daten eintreffen, egal ob verschlüsselt oder was auch immer, und ob Optionen -> Hardware -> Bei fehlendem Stream neu tunen nach... konfiguriert ist.

 

Der Recorder erfasst dagegen, ob die speziell für die Aufnahme benötigten Daten eintreffen (nicht irgendwelche) und zusätzlich, ob das Scrambled Flag im TS Header gesetzt ist. Wenn nur Video/Audio-Pakete mit gesetztem Scrambled Flag eintreffen, behandelt er dies, als kämen keine Daten, d.h.er beendet die Aufnahme und startet sie neu, sofern DMS-Optionen -> Aufnahme-Optionen -> Neustart wenn keine Daten innerhalb 60s eingeschaltet ist. Der Vorgang beinhaltet auch eine Freigabe und Neuinitialisierung der DVB-Hardware einschließlich verbautem CI/CAM, geht also über ein Retuning hinaus.

 

Wenn bei dir massenweise verschlüsselte Daten auf Platte geschrieben werden, ohne dass es zu einem Neustart kommt, heißt das also, dass Video/Audio-Pakete mit zurückgesetztem Scrambled Flag eingetroffen sind, die *angeblich* entschlüsselt wurden. Ob das tatsächlich passiert ist, ist eine andere Frage...

 

Link to comment
vor 2 Minuten schrieb Griga:

Wenn bei dir massenweise verschlüsselte Daten auf Platte geschrieben werden, ohne dass es zu einem Neustart kommt, heißt das also, dass Video/Audio-Pakete mit zurückgesetztem Scrambled Flag eingetroffen sind, die *angeblich* entschlüsselt wurden. Ob das tatsächlich passiert ist, ist eine andere Frage... 

 

"massenweise" ist reichlich übertrieben.  (oder reden wir hier von der Masse einer einzelnen Aufnahme?)

 

Es sind weniger als 5-10% der Aufnahmen betroffen, deshalb habe ich lange Zeit gar nix gesagt. Aber, da es immer wieder mal vorkommt, dachte ich, es wäre doch mal erwähnenswert, bzw, es lohnte sich mal tiefer zu suchen.

 

Also gibts keine zusätzlichen Logfiles, wo man noch reingucken könnte?

 

Link to comment

"Massenhaft" Video/Audio Pakete einer Aufnahme. Zurückgesetzt "scrambled flags", obwohl gar nicht entschlüsselt wurde, sind ein nicht ganz unbekanntes Problem bei Grauzonen - CAM. Genauer analysieren könnte man z.B. die fehlerhafte Aufnahme, d.h. was steckt da wirklich drin?

Link to comment
vor 2 Minuten schrieb nuts:

"Massenhaft" Video/Audio Pakete einer Aufnahme. Zurückgesetzt "scrambled flags", obwohl gar nicht entschlüsselt wurde, sind ein nicht ganz unbekanntes Problem bei Grauzonen- bzw. [removed, violating forum rule §13]. Genauer analysieren könnte man z.B. die fehlerhafte Aufnahme, d.h. was steckt da wirklich drin?

wo willst Du sie hinhaben? Sind nur 2,2Gb, ist also in ein paar Minuten gegessen

Link to comment

Du kannst die Datei mit dem TS Doctor (müsste es eine kostenlose Testversion geben) selbst überprüfen. Mehr könnte ich auch nicht beitragen. ;)

 

 

Link to comment
vor 14 Minuten schrieb nuts:

Du kannst die Datei mit dem TS Doctor (müsste es eine kostenlose Testversion geben) selbst überprüfen. Mehr könnte ich auch nicht beitragen. ;)

 

 

Der ist gut!!!

Muss man natürlich nicht wissen, MaM ist DER Experte für TSDoctor.

Gruß

Edited by iks-jott
Link to comment
vor 2 Stunden schrieb MaM:

Also gibts keine zusätzlichen Logfiles, wo man noch reingucken könnte?

 

Nein. Ich würde mir die Datei mit dem TransEdit Analyzer und dem Hex Viewer anschauen, wenn ich sie hätte...

 

Link to comment
vor 19 Minuten schrieb iks-jott:

Der ist gut!!!

Muss man natürlich nicht wissen, MaM ist DER Experte für TSDoctor.

Gruß

Lol, danke für die Blumen, ich würde es eher "unter den Blinden ist der Einäugige König" formulieren  ?

 

vor 7 Minuten schrieb Griga:

 

Nein. Ich würde mir die Datei mit dem TransEdit Analyzer und dem Hex Viewer anschauen, wenn ich sie hätte...

 

Ich hab meinen spendablen Tag, Du kannst sie haben, sag mir wo ich sie hinladen soll, oder ich schick Dir n Downloadlink von meinem Server wenn gewünscht.

 

Um wieder zurück zum Ausgang zu finden: Spekulationen über irgendwelche Foren§13 Dinger sind sinnlos, meine Netzwerkprotokolle (ich könnte ein paar Gb WireShark Traces anbieten) zeigen eindeutig, dass der DMS zum besagten Zeitpunkt gar nicht auf die Idee kommt, ein CAM anzusprechen. Und wer nicht fragt, wird auch keine Antwort erhalten!

 

Deshalb bin ich überhaupt hier gelandet, nur ihr könnt eventuell wissen, warum er das nicht tut, wo er es doch 1000mal sonst macht.

 

Link to comment

Der DMS spricht dein "CAM" überhaupt nicht an ... insoweit bist du da schon mal auf dem Holzweg.

Wenn du dich mit dem TSDoctor auskennst, was meint die Software denn zu deiner Aufnahme?

Link to comment
vor 2 Minuten schrieb nuts:

Der DMS spricht dein "CAM" überhaupt nicht an ... insoweit bist du da schon mal auf dem Holzweg.

Wenn du dich mit dem TSDoctor auskennst, was meint die Software denn zu deiner Aufnahme?

"Holzweg" würde ich nicht sagen, ich weis halt nicht, wie die internen Abläufe sind, deshalb frage ich ja hier Leute, die sich damit auskennen könnten ?

 

Der TSDoc meint (wie ich schon gaaanz am Anfang beschrieben hatte) "Datei verschlüsselt - eine Weiterbearbeitung ist nicht möglich" und bricht schon beim PID Scan ab.

 

(VLC & Co zeigen auch nur ein schwarzes Bild, das "verschlüsselt" wird wohl stimmen)

 

Link to comment

Die internen Abläufe sind schon sehr §13 lastig.

Einziger Ansatz Punkt für einen Fehler im DMS wäre, dass er aufgrund besonderer Umstände in besonderen Fällen die "Plugin Struktur" nicht richtig "bedient" (erst dann kommt dein Netzwerk Zeugs).

Natürlich nicht unmöglich, aber dafür spricht die Fehlerbeschreibung jetzt nicht unbedingt, da die "scrambled flags" schließlich entfernt werden(kann das der TSDcotor nicht feststellen?). Für genauere Inforamtionen braucht es dann einen Profi wie Griga der die Aufnahme mit einem Editor auseinandernehmen kann. ;)

Link to comment
vor 1 Minute schrieb nuts:

Einziger Ansatz Punkt für einen Fehler im DMS wäre, dass er aufgrund besonderer Umstände in besonderen Fällen die "Plugin Struktur" nicht richtig "bedient" (erst dann kommt dein Netzwerk Zeugs).

Natürlich nicht unmöglich, aber dafür spricht die Fehlerbeschreibung jetzt nicht unbedingt, da die "scrambled flags" schließlich entfernt werden(kann das der TSDcotor nicht feststellen?). Für genauere Inforamtionen braucht es dann einen Profi wie Griga der die Aufnahme mit einem Editor auseinandernehmen kann. ;)

Bislang ist das mit den scrambled Flags nur eine bislnag unbewiesene Behauptung von Griga. Wir wollen doch hier nicht mit alternativen Fakten arbeiten, oder ? ?

 

Ja, das "Netzwerk Zeugs" deutet darauf hin, dass es in der Pluginecke klemmt. Leider ist das Logfile des Plugins völlig unübersichtlich, da sich ja bis zu 8 Tuner gleichzeitig tummeln kann ich nicht auseinanderhalten, was wozu gehört (bzw. ob da überhaupt was kommt, da man das nicht vorhersehen/reproduzieren kann, kann ich mich schlecht live auf die Lauer legen)

 

 

Link to comment

hmm, ich hab mal diesen "Transedit Scan" benutzt, auch wenn mir die angezeigten Werte nix sagen.

 

Ich vermute, das ominöse "Scrambled Egg" äääh "Flag" ist wirklich zurückgesetzt. da die Datei unter FTA Filter gelistet wird?

 

Kann das auch ein Fehler des Tuners sein (sprich: löscht der Tuner vielleicht schon das Flag, so dass später niemand auf die Idee kommt, es wäre erforderlich noch ein paar Maßnahmen zu ergreifen) ?

 

 

FTA.jpg

Link to comment

Erinnert an dieses Thema: https://www.dvbviewer.tv/forum/topic/58708-errors-und-klötzchenbildung-bei-sd-sendern-in-dvb-s2/

 

Was folgende Änderung zur Folge hatte:
 

Zitat

 


Change: Recorder: Video/Audio data packets with set scrambled flag are not discarded anymore if unscrambled data has been received before (fixes issues caused by CAMs that do not reset the scrambled flags in certain packets).

 

 

Ob das hier eine Rolle spielt?

Schuldig im Sinne der Anklage ist weiterhin das Entschlüsselungssystem, da es nicht entschlüsselte Paket als entschlüsselt kennzeichnet.

Link to comment
vor 4 Stunden schrieb MaM:

hmm, ich hab mal diesen "Transedit Scan" benutzt, auch wenn mir die angezeigten Werte nix sagen.

 

Der Scanner sacht nix. Man muss den Analyzer nehmen.

 

Wenn im Analyzer die Video/Audio-Streams rot angezeigt werden, ist das Scrambling Flag in den Paketen gesetzt. Ansonsten erscheinen sie schwarz. Guckst du hier.

 

Der Scanner schaut sich die Video/Audio-Streams gar nicht an. Er ermittelt nur, ob die Streams in der PMT (Program Map Table) als verschlüsselt gekennzeichnet sind. Sind sie aber bei einer DMS-Aufnahme nicht, weil der Recorder diese Info aus der PMT rauswirft, da er davon ausgeht, dass entschlüsselt wird.

 

Link to comment

Also dieser Analyzer sagt mir wenig, und nix Rotes, wenn ich die Datei reinlade.

Aber, was will mir das eingekreiste Bit sagen???

 

 

Hu.jpg

Link to comment
vor 12 Minuten schrieb MaM:

Aber, was will mir das eingekreiste Bit sagen???

 

Du hast EPG-Daten mit aufgenommen (EIT = Event Information Table). Da steht drin, dass die Sendung verschlüsselt gesendet wird. Hat nichts zu bedeuten.

 

Relevant sind PAT und PMT. Sie stellen eine Art Inhaltsverzeichnis dar und geben an, welche Services und welche Video/Audio/Teletext/Untertitel-Streams usw. im TS enthalten sind - mehr dazu hier. Der Recorder reduziert die original gesendete PAT und PMT auf den Inhalt der Aufnahme, damit Player nicht darin Elemente suchen, die es gar nicht gibt.

 

H.264 Video ist eindeutig mit gelöschtem Scrambled Flag aufgenommen worden. Merkwürdig ist das Fehlen von Audio.

 

Link to comment

also hier mal zum Vergleich eine FUNKTIONIERENDE Aufnahme (läuft gerade)

 

Hier sind ja eindeutig Audio Kanäle vorhanden und es steht NOT ENCRYPTED in dem Feld...

(und es ist auch ordnungsgemäss entschlüsselt)

 

 

Gut.jpg

Link to comment
vor einer Stunde schrieb MaM:

und es steht NOT ENCRYPTED in dem Feld...

 

Steht da bei Aufnahmen mit EPG immer. Das ist nicht die original gesendete SDT (Service Description Table). Sie wird vom DMS als Ergänzung zur EIT erzeugt und beschreibt den aufgenommenen Service. Schau mal, wer im Service Descriptor als Provider angegeben ist :) Die EIT besteht dagegen aus den originalen Present/Following Sections für den aufgenommenen Service.

 

Im Grunde ist es Platzverschwendung, eine SDT und EIT in die Aufnahme zu schreiben - warum hast du "Zusätzlich aufnehmen - EPG-Daten" aktiviert? Damit kann kein mir bekannter Player etwas anfangen. Irgendwann vor vielen Jahren war das mal eine Feature Request von wem auch immer für welchen Zweck auch immer, und Lars ist dem nachgekommen. Um herauszufinden, ob es noch jemand braucht, müsste ich es entfernen und schauen, ob sich jemand beschwert...

 

Nur PAT und PMT sind als SI-Daten in Aufnahmen wirklich relevant. Statt dem EIT/SDT-Firlefanz wäre eine aufgeklappte PMT der misslungenen Aufnahme wesentlich informativer.

 

Leider sehe ich hier nur partielle Informationen, gefiltert von jemand, der nicht  weiß, was für das Problem von Bedeutung ist und was nicht...

 

Link to comment
vor 6 Stunden schrieb Griga:

Leider sehe ich hier nur partielle Informationen, gefiltert von jemand, der nicht  weiß, was für das Problem von Bedeutung ist und was nicht...

 

Woran Du ja ursächlich mitschuldig bist.

 

Wie oft soll ich noch fragen, wie und wohin Du die Datei haben willst, damit Du selber gucken kannst ? ? ?

 

Also beschwer Dich nicht über meine Unkenntnis, sondern überwinde Deine Massenträgheit.

 

"warum hast du "Zusätzlich aufnehmen - EPG-Daten" aktiviert? Damit kann kein mir bekannter Player etwas anfangen. Irgendwann vor vielen Jahren war das mal eine Feature Request von wem auch immer für welchen Zweck auch immer, und Lars ist dem nachgekommen. Um herauszufinden, ob es noch jemand braucht, müsste ich es entfernen und schauen, ob sich jemand beschwert..."

 

Weil bei mir kein Player jemals die Datei vors Gesicht bekommt, sondern nur der TSDoc. Und der kann sehr wohl was mit den Info anfangen und braucht sie für den automatischen Schnitt. Du hast also gerade herausgefunden, dass sie bitte schön da bleiben, wo sie sind.

Edited by MaM
Link to comment
vor 57 Minuten schrieb MaM:

Wie oft soll ich noch fragen, wie und wohin Du die Datei haben willst, damit Du selber gucken kannst ? ? ?

 

Ich habe keinen Web Space für Uploads. Außerdem habe ich keine Lust, 2 GB mit meinem 10 MBit/s Internet herunterzuladen. 100 MB vom Anfang sollten reichen. Insgesamt ist dein privates Problemchen auch nicht von besonderer allgemeiner Relevanz, aber immerhin eine Gelegenheit, die beteiligten Recorder-Mechanismen einer Überprüfung zu unterziehen. Nur deshalb befasse ich mich damit. Zu einer Lösung wird das wahrscheinlich nicht führen.

 

vor 57 Minuten schrieb MaM:

Weil bei mir kein Player jemals die Datei vors Gesicht bekommt, sondern nur der TSDoc. Und der kann sehr wohl was mit den Info anfangen und braucht sie für den automatischen Schnitt.

 

Der schon wieder... ich habe auch noch was zu dem Thema gefunden:

 

https://www.dvbviewer.tv/forum/topic/61344-how-to-record-shows-epg-title-in-ts-file-visible-in-vlc-player/

 

Jetzt weiß ich auch, wo die SDT herkommt, über die ich mich gestern erst mal gewundert habe. Ich habe sie selbst im April letzten Jahres ergänzt. :) Die Sachen, die ich vor ein paar Monaten implementiert habe, sind schon sowas von weg...

 

Link to comment
vor einer Stunde schrieb Griga:

Ich habe keinen Web Space für Uploads. Außerdem habe ich keine Lust, 2 GB mit meinem 10 MBit/s Internet herunterzuladen. 100 MB vom Anfang sollten reichen. Insgesamt ist dein privates Problemchen auch nicht von besonderer allgemeiner Relevanz, aber immerhin eine Gelegenheit, die beteiligten Recorder-Mechanismen einer Überprüfung zu unterziehen. Nur deshalb befasse ich mich damit. Zu einer Lösung wird das wahrscheinlich nicht führen.

 

Ich hab auch keinen Webspace für Uploads, deshalb hier vom eigenen Server https://autodiscover.werries.de/xxx/Unforgettable-Sturmtief_cutted.ts

Exakt 100Mb, sag BESCHEID, wenn die Datei wieder wegkann.

 

Link to comment

Ergebnis der Analyse im Hex Viewer:

 

Video und Audio sind verschlüsselt eingetroffen. Deshalb hat der DMS die ersten ca. 160 kB nur SI Daten geschrieben (PAT, PMT, SDT, EIT), die immer unverschlüsselt sind, während er bei den Video- und Audiostreams gewartet hat, bis ein TS Paket mit gesetztem Payload Unit Start Indicator auftaucht, das einen zum Streamtyp passenden PES Header enthält. Das ist i.a. auch ein Punkt, wo Player sinnvoll mit der Wiedergabe einsetzen können.

 

Bei den beiden aufzunehmenden AC3-Audiospuren, die aus der PMT ersichtlich sind, ist dieser Punkt nie gekommen, weil aufgrund der Verschlüsselung kein PES Header bzw. die typische Bytefolge eines PES Startcodes zu erkennen war. Deshalb wurde kein Audio geschrieben. Bei Video hat sich jedoch ungefähr an Dateiposition 161120 zufällig eine Bytefolge ergeben, die für den Recorder wie ein Video PES Header aussah. Deshalb hat er dort begonnen, Video zu schreiben.

 

In den Video TS Paketen ist wie vermutet das Scrambling Flag zurückgesetzt. Die Daten müssen irgendeine Instanz durchlaufen haben, die sich bemüßigt fühlte, das zu tun - also höchstwahrscheinlich das CAM (außer das Flag fehlte bereits senderseits, was eher unwahrscheinlich ist). Das fehlende Flag hat den DMS daran gehindert, die Aufnahme nach einer Minute wegen ausbleibender verwertbarer Daten neu zu starten.

 

Zu vermuten ist, dass das CAM das Scrambling Flag kategorisch zurücksetzt, egal ob ihm die Entschlüsselung gelingt oder nicht.

 

Link to comment

na ja, erstmal Danke für die Analyse.

Bringt mich zwar nicht wirklich weiter, aber was solls.

 

Beim TSDoc gibts sonne Einstellung "ignoriere Scrambling Flag", die ist eigentlich immer gesetzt (wofür sie gut ist, entzieht sich allerdings meiner Kenntnis). Trotzdem schafft er es sauber die verschlüsselten von den unverschlüsselten zu trennen (man hat ja mal ab und zu ne Aufnahme, wo mittendrin das CAM mal für ein paar Minuten die Krise hat). Vielleicht tauscht Ihr euch mal aus um die bessere Erkennung zu übernehmen?

 

 

Link to comment

Also bei mir ist noch nie ne Aufnahme verschlüsselt gewesen, allerdings nehm ich auch nicht so unzuverlässige CAM dinger sondern eben nen raspberry pi mit der enstprechenden Software.

Kann ich nur jedem empfehlen das läuft stabil und ohne ein einziges Probleme seit Jahren. Keine Probleme weil nach nem reboot irgendwie das CAM nicht funktioniert usw...

 

Fragen dazu beantworte ich hier aber nicht ? 

Jedenfalls ist ziemlich sicher das CAM bei dir ein Problem.

Link to comment
vor 1 Minute schrieb VinoRosso:

nicht so unzuverlässige CAM dinger sondern eben nen raspberry pi mit der enstprechenden Software.

Lol, ich werde Deine Einschätzung bzgl. der Zuverlässigkeit der Hardware an HP weiterleiten.

Dieser Proliant Server mit 2 Xeon Prozessoren und 192Gb Ram kann mit dem Raspi natürlich nicht mithalten.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...