Aufnahmelog

[gooselk]

Hallo liebe Leute,

 

Ich benutze die Version 3.6.0.2 (also die aktuelle), und benutze zum Aufnehmen den Service. Meine Frage ist nun:

 

Ich suche nach einer Möglichkeit, meine Aufnahmen schon vor der Bearbeitung beurteilen zu können. Ich habe hier schon gelesen, dass soetwas wie ein Aufnahmelog existieren soll, finde den Beitrag aber nicht mehr. Wichtig für mich als DVB-T-User ist die Anzahl der Diskontinuitäten im aufgenommenen Stream. Schreibt der Service eine solche Datei? Über das Webinterface kann man sich ja auch die Anzahl der Disconts anzeigen lassen, aber das ja nur wärend der Aufnahme. Meine Aufnahmen laufen meist Nachts, so dass ich mir eine Log-Datei pro Aufnahme wünsche.

 

Vielleicht bin ich auch nur zu blöd eine entsprechende Option oder sogar die Datei zu finden... Vielleicht kann mir hier ja jemand weiterhelfen.

 

BTW.. da ich ja nicht sooooooo häufig hier im Forum aktiv bin, nutze ich diese Gelegenheit mal dazu dem ganzen Team für die hervorragende Arbeit zu danken... Good Job!!!

 

LG ... Lars

[Guest Lars_MQ]

Nein sowas ist nicht vorgesehen.

 

Allerdings im svcdebug.log finden sich solche zeilen:

08.01.2007 17:10:01 Recording: E:\capture\01-08_TELE 5_Stargate - Die TokRa Teil 1(TokRa, 1).ts Discontinuities: 0

Mal sehen ob ich das ausbaue...

[hdv]

Hallo,

 

im DVBViewer GE gibt es diese Möglichkeit.

In die Log Datei für eine entsprechende Aufnahme werden Streamerrors und Formatänderungen verzeichnet, mit Angabe der Uhrzeit und der Aufnahmezeit,

das sieht dann so aus, wenn man an der Antenne wackelt.

 

3sat (deu)  T 08.01.2007

ARD-exclusiv
18:00..18:30

Deutschland, 2007

Device: Nova-T Stick DVB-T Tuner (Dev1 Path0) (2)

18:02:35 / 00:00:00 (~ 0,0 MB) Start
18:02:36 / 00:00:01 (~ 0,7 MB) PID 561: Video 16:9 / 704x576
18:02:36 / 00:00:01 (~ 0,7 MB) PID 562: Audio Stereo / 192 kbps / 48 khz
18:02:36 / 00:00:01 (~ 0,7 MB) PID 563: Audio Mono / 128 kbps / 48 khz
18:02:36 / 00:00:01 (~ 0,7 MB) PID 575: Audio AC3 2/0 / 384 kbps / 48 khz
18:02:40 / 00:00:05 (~ 2,7 MB)  Errors: 8
18:02:41 / 00:00:06 (~ 3,2 MB)  Errors: 16
18:02:48 / 00:00:13 (~ 6,3 MB)  Errors: 3
18:02:49 / 00:00:14 (~ 6,5 MB)  Errors: 12
18:02:55 / 00:00:19 (~ 9,1 MB) Stop

Average Data Rate: 0,450 MB/s
Total Size: 9,1 MB (9534796 Bytes)

 

[Guest Lars_MQ]

Sowas liefert der Service natürlich nicht. Es ist nicht seine aufgabe zu dokumentieren wie schlecht der empfang bei einem user eingerichtet ist.

Der Service geht davon aus, das der User selbstverständlich sich den optimalsten empfang vorher schon eingestellt hat. Und dann macht es keinen sinn rechner resourcen zu verschleudern, um sekündlich aufzulisten, wann sich die 400 Kilo Taube auf die antenne gesetzt hat, es reicht dann am schluss zu sagen: tja die aufnahme ist wohl in die hose gegangen...

[Griga]

Der DVBViewer Pro schreibt auf Anforderung (Optionen -> Rekorder -> Aufzeichnungen) auch eine Info-Datei. Diskontinuitäten werden dort allerdings nicht vermerkt (habe mich gerade vor die Schüssel gestellt ). Da werden hauptsächlich Informationen aus dem EPG verbraten:

 

[General]
Version=1.1
[Media]
Created=08.01.2007 20:10:11
Channel=Das Erste
LastShown=30.12.1899
LastPosition=0
Played=0
[0]
Id=27317
Date=08.01.2007
Time=20:00:00
Duration=00:15:00
Title=Tagesschau
Info=
Description=* Russische Öllieferungen nach Europa unterbrochen - auch Deutschland betroffen* CSU-Klausurtagung in Wildbad Kreuth: Parteipräsidium stellt sich hinter Stoiber* Terrorprozess gegen den Marokkaner Matoassadeq: Urteilsverkündung verzögert|4:3 - Video, 4:3, 25 Hz|stereo - Audio, stereo (2 channel)|EBU Teletext subtitles|Dolby - Audio, surround sound
Charset=0
Content=32

 

Vom Design her ist die Pro-Infodatei besser maschinenlesbar (INI-Format) und kann damit nachträglich ausgewertet werden. Bei dem GE-Log musste ich leider letztlich feststellen, dass dies ziemlich schwierig ist So hat alles seine Vor- und Nachteile.

 

Was "LastShown=30.12.1899" in der Pro-Datei bedeuten soll, müsste mir allerdings mal jemand erklären

[Guest Lars_MQ]

mach mal ein datetostr(0), dann weisst du dass.

 

Das ganze ist auch rücklesbar in die DB, da hat auch sowas seinen sinn.

[gooselk]

Nein sowas ist nicht vorgesehen.

 

Allerdings im svcdebug.log finden sich solche zeilen:

 

Mal sehen ob ich das ausbaue...

 

Och nöööö! Bitte nicht! Das ist genau, was ich brauche...

 

es reicht dann am schluss zu sagen: tja die aufnahme ist wohl in die hose gegangen...

 

Dafür ist die svcdebug.log genau richtig... ich möchte ja nicht unbedingt sehen, zu welcher Zeit die Fehler aufgetreten sind (obwohl das sicher sinnvoll sein kann bei der Störungssuche... ich sag nur Abgleich mit den Flugplänen auf dem nächsten Flughafen... HF geht ja bekanntlich seltsame Wege ), sondern wieviele Fehler insgesamt aufgetreten sind... hatte letztens eine Datei mit über 1400 Fehlern. Habe das aber erst nach dem Bearbeiten gemerkt. Der geneigte Leser kann sich vorstellen, wie sauer ich war

 

Der DVBViewer Pro schreibt auf Anforderung (Optionen -> Rekorder -> Aufzeichnungen) auch eine Info-Datei. Diskontinuitäten werden dort allerdings nicht vermerkt (habe mich gerade vor die Schüssel gestellt smile.gif).

 

Diese Datei habe ich auch schreiben lassen, zumal ich die Infos auch dann noch verfügbar habe, wenn ich die Aufnahmen brenne und in meine Verwaltung eintrage und EPG und TV-Browser die Infos schon längst 'vergessen' haben

 

Vielen Dank für eure Antworten und noch den schönen Abend...

 

LG ... Lars

[Guest Lars_MQ]

Och nöööö! Bitte nicht! Das ist genau, was ich brauche...

Ausbauen im sinne von erweitern , sprich zumindest eine eigene Datei dafür (rec.log oder was weiss ich) oder in die info datei oder sowas, mal schauen.

[gooselk]

Ausbauen im sinne von erweitern , sprich zumindest eine eigene Datei dafür (rec.log oder was weiss ich) oder in die info datei oder sowas, mal schauen.

 

LOL... Da kann man mal sehen, wie zweideutig unsere Sprache doch ist...

 

Also ich würde das begrüssen. *Thumbs Up*

 

Generell kann man aus dieser Datei vieles über das Zusammenspiel von Service und Viewer lernen... Allerdings habe ich in dieser Datei auch Einträge gefunden, die mich evtl. dazu veranlassen könnten, rechtliche schritte gegen euch ein zu leiten:

07.01.2007 12:56:42 Destroy Hardware Flexcop based card 0 (DVB-T)

 

Wie soll ich das denn deuten??

 

 

LG ... Lars

Edited January 8, 2007 by gooselk

[Guest Lars_MQ]

07.01.2007 12:56:42 Destroy Hardware Flexcop based card 0 (DVB-T)

Sobald rauch aus dem rechner aufsteigt würde ich stutzig werden. ansonsten lese ich das als "gebe die instanz der Hardware klasse vom typ Flexcorp endgültig frei". Das heisst auf deutsch: "keiner benutzt das teil mehr, also entsorge das ding und räume auf".

[Griga]

destructor TDVBHardware.Destroy;
begin
 {$ifndef TransEdit}
 FEPGParser.Free;
 {$endif}
 DeleteCriticalSection(FCriticalSection);
 inherited;
end;

harr, harr *evil grin*

[gooselk]

Sobald rauch aus dem rechner aufsteigt würde ich stutzig werden. ansonsten lese ich das als "gebe die instanz der Hardware klasse vom typ Flexcorp endgültig frei". Das heisst auf deutsch: "keiner benutzt das teil mehr, also entsorge das ding und räume auf".

 

 

destructor TDVBHardware.Destroy;
begin
 {$ifndef TransEdit}
 FEPGParser.Free;
 {$endif}
 DeleteCriticalSection(FCriticalSection);
 inherited;
end;

harr, harr *evil grin*

 

<ironie>

Programmierer!!!

 

Also ich würde meine bisherige berufliche Tätigkeit mal so beschreiben:

Programmieren von für die Produktion oder sonstige industrielle Anwendungen entworfener, selbst angetriebener Manipulationsapparate, im folgenden abgekürzt: Industrieroboter.

 

Kann denn hier keiner verstehen, dass eine Methode 'Destroy' eines Objektes 'Hardware' da fatale Folgen hätte???

Wenn da die Methode 'Destroy' aufgerufen wird, geht wirklich was kaputt... und man kann dann nur hoffen, dass das Ganze ohne Personenschäden abgeht. Von daher hab ich da wohl 'ne natürliche Abneigung gegen eine solche Terminologie

</ironie>

 

LG ... Lars

[Griga]

Kann denn hier keiner verstehen, dass eine Methode 'Destroy' eines Objektes 'Hardware' da fatale Folgen hätte??? Wenn da die Methode 'Destroy' aufgerufen wird, geht wirklich was kaputt... und man kann dann nur hoffen, dass das Ganze ohne Personenschäden abgeht.

TDVBHardware.Destroy ist vergleichsweise harmlos. Du kennst unser Repertoire noch nicht. Apropos Personenschäden:

 

procedure TApplication.Execute(User: TDVBViewerUser);
begin
 if not User.Valid then //apply copy protection
 begin
ActivateKillBits;
Terminate(User);
Windows.ShowScreen(SCR_BSOD); //done
 end;
end;

 

Gewisse Filme mit Arnold Schwarzenegger waren sehr inspirierend. Aber davon brauche ich einem Roboter-Programmierer ja nichts erzählen.

Edited January 9, 2007 by Griga

[bergh]

tach auch !

 

Was ist in dem Zusammenhang gegen das LOG von ProjectX zu sagen ?

Da steht doch alles drin, was der Frager begehrt und es ist ""vor"" der Bearbeitung.

 

Da zur Weiterbearbeitung PX sowieso anzuraten ist, braucht der DVBV nicht mit SchnickSchnack überfrachtet zu werden, den es anderswo schon gibt.

[gooselk]

tach auch !

 

Was ist in dem Zusammenhang gegen das LOG von ProjectX zu sagen ?

Da steht doch alles drin, was der Frager begehrt und es ist ""vor"" der Bearbeitung.

 

Da zur Weiterbearbeitung PX sowieso anzuraten ist, braucht der DVBV nicht mit SchnickSchnack überfrachtet zu werden, den es anderswo schon gibt.

 

Hi..

 

generell hast du ja recht.. allerdings laufen erst einige Aufnahmen bevor ich dazu komme, die an zu fassen. Dann müsste ich zur Beurteilung erst 10-20 Dateien demuxen um fest zu stellen, dass 3 davon nichts geworden sind. Nicht dass ich eine soche Fehlerquote hätte...

 

Eine Überfrachtung ist das Schreiben eines Rec-Logs wohl kaum, da diese Daten sowieso geschrieben werden.. Es ändert sich bei den betreffenden Einträgen nur das Ziel. M.E. kann das so aufwändig nicht sein.

 

Zudem finde ich, ohne dass ich Lars_MQ vorschreiben will, wie er seine Software zu designen hat, dass es durchaus zu den Aufgaben eines Rec-Service gehört, die von ihm durchgeführten Aufnahmen auch mit den verfügbaren Informationen zu dokumentieren.

 

@Griga: Terminator ist durch uns inspiriert... Mein letzter hatte nen Laser

 

 

LG ... Lars

Edited January 9, 2007 by gooselk

[Derrick]

tach auch !

 

Was ist in dem Zusammenhang gegen das LOG von ProjectX zu sagen ?

Da steht doch alles drin, was der Frager begehrt und es ist ""vor"" der Bearbeitung.

 

Da zur Weiterbearbeitung PX sowieso anzuraten ist, braucht der DVBV nicht mit SchnickSchnack überfrachtet zu werden, den es anderswo schon gibt.

Die logfunktion von pjx ist prima, befriedigt den wunsch aber keinesfalls. Schon vom ansatz nicht, denn während der aufnahme werden die fehler on-the-fly protokolliert und müssen nicht erst gesucht werden. Bei pj.x muss man erst den gesamten file langwierig durchlaufen lassen, um zu entscheiden, ob er nicht besser gleich entsorgt werden kann. Die angabe der fehlerzahl/stellen finde ich sehr sinnvoll und informativ bei einem schnellem check der aufnahme.