Beiträge von UweHeinritz

    Hallo,
    das sind Bilder die vom scraper-plugin des epgd eigentlich hätten gefüllt werden müssen.
    Der Server erzeugt für alle Staffeln/Episoden (also auch die ohne ein Event oder Recording) erst mal Dummy-Einträge in seiner Bilder-Tabelle mit einem leeren Blob-Feld. Sobald dann eine Staffel bzw. Episode verwendet wird, lädt das Plugin dann das eigentliche Bild aus dem Internet und speichert es in das Blob-Feld.


    Das scraper2vdr Plugin versucht nun von allen Staffeln/Episoden welche ein Event oder ein Recording haben die Bilder zu laden. Wenn dabei aber festgestellt wird das ein Bild ein leeres Blob-Feld hat (obwohl es hätte gefüllt sein müssen), kommt genau die Meldung ins Log.
    Ursache ist also das Scraper-Plugin vom epgd-Server, welches die Daten nicht richtig füllt. Das müssen wir uns als nächstes anschauen.


    Da leider beim SQL sofort das ganze Blob-Feld gelesen/übertragen wird sobald man auf ein leeres Blob-Feld prüft, musste ich diese Prüfung aus Performancegründen weg lassen.


    Ich werde das Loglevel für diesen Log-Eintrag mal erhöhen, so dass das Log nicht zu voll wird.


    Tschau, Uwe.

    Hallo,
    ja den Bug habe ich auch gleich mit behoben.
    Ein extra git haben wir genutzt, da ich keinen Zugriff auf das offizielle git habe. Darum hat horchi ein extra git erzeugt und mir dort auch Rechte gegeben.
    Das wandert dann ins offizielle git wenn hier keiner meckert das was nicht geht :]
    In dem Zug wird dann aber das alte Verhalten komplett aus den Sourcen entfernt (ist ja jetzt per Menü noch umschaltbar), damit der Wartungsaufwand nicht zu groß wird.


    Tschau, Uwe.

    Hallo,
    wie Louis bereits angedeutet hat, wurde in letzter Zeit von mir das scraper2vdr Plugin mit einer neuen DB-Parser-Logik (wurde komplett umgearbeitet) versehen.
    Diese sollte das Laden der Daten vom SQL-Server deutlich ressourcenschonender und schneller erledigen.
    Da nun nur noch die Binärdaten der Bilder übertragen werden, wenn diese lokal fehlen oder zu alt sind, ist jetzt auch eine Anbindung an einen SQL-Server über ein langsames WLAN möglich.
    Zusätzlich wurde von horchi (Vielen dank dafür) die DB-API auf den Stand des http-Branches vom epgd-Server gebracht. Da diese API aber voll abwärtskompatibel ist, kann das scraper2vdr Plugin aber weiterhin mit dem master-Branch vom epgd-Server verwendet werden.


    ACHTUNG: das Plugin benötigt in der Datenbank bereits die scrsp-Spalte in der Recordings-Tabelle. Diese muss entweder von Hand angelegt werden, oder das alter-Script des aktuellen epgd-Servers ausgeführt werden (bessere Methode!)
    Weitere Infos dazu gibt es hier und hier


    Eine weitere Neuerung ist das nun die Größe der Thumbnails (z.B. für die kleinen Vorschaubilder in den Aufnahmen) im Plugin-Setup eingestellt werden kann. Diese wird mit 200px initialisiert, was einer ähnlichen Größe (aktuell zwischen 175-200) entspricht wie bisher.
    Der Sinn der einstellbaren Größe besteht darin, das man nun die Thumbnails gleicht so groß erzeugen lassen kann wie diese vom Skin benötigt werden. Theoretisch (war zumindest im alten skinnopacity so) sollte dies dazu führen das beim Zeichnen der Bilder das Skalieren auf die richtige Größe entfällt und so das Browsen in den Aufnahmen flüssiger geht. Schön wäre es wenn die jeweiligen Skinentwickler eventuell eine Debug-Logausgabe in die Skins einbauen welche die richtige Höhe der Thumbnails angibt.
    Nachdem die Größe im Setup geändert wurde, kann durch den Menüpunkt "Alle Daten (Serien, Filme und Bilder) neu laden" das scraper2vdr-Plugin dazu gebracht werden komplett alle Bilddaten vom SQL-Server neu zu laden (unabhängig davon ob sie schon lokal vorhanden sind oder nicht) und damit auch alle Thumbnails in der neuen Größe zu erzeugen.


    Sollte es wieder erwarten mit dem neuen Verhalten Probleme geben, kann im Setup auf den alten DB-Parser zurück gewechselt werden. ACHTUNG: die Spalte scrsp wird dennoch erwartet!
    Es wäre toll wenn ihr das neue scraper2vdr Plugin testen könntet und hier eine Rückmeldung geben würdet ob alles so funktioniert wie es soll.
    Wenn ihr Lust habt könnt ihr auch gern hier posten wie lang das erste Laden der Daten mit neuem und alten Verhalten bei euch dauert (dazu einfach im Setup umschalten, den VDR neu starten und im syslog schauen wie lang es gedauert hat bis das plugin fertig ist).


    Der aktuelle Entwickler-Zweig vom Plugin ist hier zu finden: https://github.com/horchi/scraper2vdr


    Noch abschließend eine Warnung: Es ist und bleibt eine Entwicklerversion welche unter Umständen nicht richtig funktioniert oder Folgefehler verursacht. Ob ihr diese auf einem Produktivsystem einsetzt ist euch überlassen!
    Wir haben aber natürlich nach bestem Wissen und Gewissen programmiert und so gut es ging getestet.


    Tschau, Uwe.

    olebowle:
    Vielen vielen Dank!
    Ich habe gerade einen neuen Kernel ohne jeglichen Media/Lirc-Support erzeugt und installiert. Dann habe ich den CrazyCat-Treiber in einen neuen Ordner entpackt und den Treiber so wie von dir beschrieben erzeugt (habe make -j4 verwendet).
    Alle Module sind dann in dem Update-Ordner vom Kernel gelandet (besser als vorher direkt im Kernel-Ordner) und die Karten inkl. lirc_serial funktionieren.


    Wenn man die richten Befehle kennt ist man in wenigen Minuten mit der Kernel/Treiber-Installation durch :] (so große Probleme hatte ich in den 10 Jahren VDR inkl. verschiedener DVB-Karten bis jetzt noch nicht).


    Tschau, Uwe.

    Ich habe es jetzt hin bekommen :)


    Ich habe den CrazyCat-Treiber entpackt und die .sh gestartet und gleich mit STRG+c abgebrochen. Dadurch wird im Ordner v4l eine .config mit den aktivierten Modulen erzeugt.
    Diese habe ich dann im Editor geöffnet und von Hand das Lirc_Serial Modul aktiviert (CONFIG_LIRC_SERIAL=m".
    Danach habe ich erneut die .sh gestartet und durchlaufen lassen. Dabei wird Glücklicherweise die geänderte .config nicht überschrieben, so dass das Lirc_Serial Modul mit erzeugt wird.
    Leider wird es aber nicht automatisch mit installiert, so dass ich es im Anschluss von Hand nach lib/modules/3.16.1/kernel/Drivers/staging/media/lirc kopiert habe.
    Nach einem Neustart haben dann sowohl die TT 4100, als auch die Fernbedienung (lirc_serial) und eine tevii 470 funktioniert.


    Schön ist das so zwar nicht, aber wenigstens geht jetzt alles.


    Tschau, Uwe.

    Hallo, danke für die Antworten.


    JV16Bar: I tried These Drivers, but they do not build the lirc_serial modules also.
    Because of that, I got incompatible lirc_serial (from kernel) and lirc_dev (from dvb driver) modules.
    How could I enable the lirc_serial module in the DVB Driver package? The sourcecode is included (also in the original package from TT), but not used.
    I tried "Make menuconfig", but the saved .config file was not used at build process.


    Auch im TT-Treiber sind die lirc_serial Quelltexte enthalten. Aber mit "make menuconfig" bekomme ich diese nicht aktiviert. Hat jemand noch eine Idee wie ich diese aktivieren könnte?


    Bye, Uwe.

    Bin ich der einzige mit dem Problem ;(


    Hat niemand in letzter Zeit einen Rechner mit einer TT 4100 und einem aktuelleren Kernel aufgesetzt? Es muss doch eine Kombination aus funktionierend LIRC und saa716x Treiber geben.


    Ist das saa716x_budget Modul eigentlich für die TT 4100? Wenn ich den tt-Treiber zusätzlich zum media_build_experimental installiere wird sofort das ssa716x_tt_budget_drv Modul versucht zu laden (was natürlich nicht zum Rest der media_build passt).


    Tschau, Uwe.

    Hallo,
    ich bin gerade dabei einen neuen VDR zusammen zu bauen. Leider versuche ich erfolglos eine TT S2-4100 in Betrieb zu nehmen.


    Als erstes habe ich versucht den original TT-Treiber zu installieren. Das hat prinzipiell auch geklappt und die Karte wurde gefunden und funktionierte. Leider hat es dadurch aber die LIRC-Module zerschossen (die werden scheinbar vom TT-Treiber nicht richtig gebaut oder installiert), so dass keine FB mehr funktionierte.
    Darum habe ich dann einen Kernel (3.16.4) selbst compiliert und dabei die media/DVB-Komponenten deaktiviert.
    Im Anschluss habe ich den aktuellen media_build_experimanetal Treiber geladen/erzeugt/installiert und neu gebootet.
    Lirc funktioniert zwar damit, aber die DVB-Karte wird nicht gefunden. Sie taucht im im dmesg überhaupt nicht aut.
    Ein Laden des Moduls saa716x_budget (was ja für die Karte ist) bringt leider nichts. Aber zumindest auch keinen Fehler, was ja bedeutet dass das Modul vom Treiber gebaut und installiert wurde.


    Woran könnte es denn lieben das die Karte gar nicht initialisiert und in dmesg auftaucht? Welcher Treiber ist denn für die S2-4100 aktuell zu bevorzugen? Ich habe ja nicht nur die S2-4100 drin und benötige daher auch TT-fremde Kernelmodule.


    Anbei mal die Ausgaben (gekürzt) von dmesg und lspci.
    dmesg:


    lspi:

    Code
    02:00.0 Multimedia controller: Philips Semiconductors SAA7160 (rev 03)
    	Subsystem: Technotrend Systemtechnik GmbH Device 3010
    	Physical Slot: 0
    	Flags: bus master, fast devsel, latency 0, IRQ 10
    	Memory at fe900000 (64-bit, non-prefetchable) [size=1M]
    	Capabilities: [40] MSI: Enable- Count=1/32 Maskable- 64bit+
    	Capabilities: [50] Express Endpoint, MSI 00
    	Capabilities: [74] Power Management version 2
    	Capabilities: [80] Vendor Specific Information: Len=50 <?>


    Tschau, Uwe.

    Hallo,
    das Problem hatte ich Anfangs im XBMC auch. Hier mal meine Einstellungen:


    XBMC:
    Saturation: 1.0999
    Speed: 72
    Value: 0.9


    boblilight.conf:


    Damit sieht es ganz gut aus (ähnlich dem SeduAtmo-Plugin im VDR).


    Tschau, Uwe.

    Hallo,
    auch wenn der Thread nun schon ziemlich alt ist, möchte ich ihn dennoch aus der Versenkung holen.


    Da ich aufgrund mehrere bei mir zu Hause installierter VDRs auch viele verschiedene DVB-Karten im Einsatz hatte, und bei fast allen das Problem mit der falschen High-Band-Frequenz auftraten, habe ich mir nun doch mal einen neuen Multischalter (Spaun SMS 51207NF) gegönnt.
    Der Kauf hat sich sehr gelohnt. Zum einen gehen nun alle bei mir vorhandenen Karten (eine alte TT DVB-S Budget, eine TT S2-1600, TeVii 470, TT S2-4100) wieder richtig mit korrekt eingestellter High-Band Frequenz und zum anderen spare ich damit auch deutlich Strom.
    Der alte Multischalter (Chess CM irgendwas) hat immer gemessene 25-27W benötigt. Der neue braucht im Betrieb 18W und wenn alle VDRs aus sind 1W. Macht im Schnitt so 130kWh / 35€ pro Jahr weniger. Das Geld ist also nach nicht mal 3 Jahren wieder drin.


    Tschau, Uwe.

    Hallo,
    wie gesagt gab es bei mir Probleme wenn man gleichzeitig USB und Vin angeschlossen hatte.


    Ich würde dir folgendes Empfehlen:
    Nimm jetzt den Nano und bau dein Ambilight erstmal auf.
    Wenn das schön ist und du es ohne PC betreiben willst, kaufe dir noch einen Nano (ist ja billiger als deine Erweiterung für den Uno). Den bastelst du in eine Aufputz/Unterputzdose (passt da auch besser rein als der Uno).
    Auf die Dose macht du einen Schalter mit dem du das Datensignal der Stripes von einen Arduino auf den anderen umschaltest.


    An meiner selber gebastelten Lampe hab ich z.B. noch 3 Drehregler mit denen ich Farbe/Modus/Helligkeit regeln kann. Wenn du sowas auch machen willst brauchst du ja ohnehin etwas wo die Regler drauf kommen.


    Tschau, Uwe.

    Hallo,
    nein ich habe 208 LEDs an einem 7A 5V Netzteil. Der Arduino wird über USB mit Strom versorgt, die LEDs vom Netzteil.
    Eigentlich bräuchte ich ein 10A Netzteil (3,5m bei max. 14,4W/m bei 5V). Da ich die LEDs aber ohnehin sowohl im seduatmo als auch im boblight auf ca. 35% max. Helligkeit eingestellt habe, wird auch bei einem komplett weißen Bild nicht mehr als 3-4A benötigt.
    Die 35% Helligkeit reichen aufgrund der großen Anzahl an LEDs vollkommen aus.


    Würde ich das wieder bauen wollen, würde ich eher einen Strip mit 30-45 Pixel pro m nehmen. Aufgrund des großen Abstrahlwinkels sieht man auch da bei ca. 15cm Wandabstand keine einzelnen LEDs.
    Am idealsten wären welche mit 12V und 45led/Pixel pro m, aber die habe ich noch nicht gefunden (die 12V Versionen haben immer 3 LEDs pro Controller/Pixel).


    Was ich damit meinte das der Nano es nicht mag wenn USB und ein externes Netzteil angeschlossen ist:
    Die LEDs der Stripes flackern wenn der Nano am USB hängt und gleichzeitig am +5V Eingang des Nanos ein Netzteil angeschlossen ist. Sobald man die 5V abzieht flackern die LEDs nicht mehr. Dem Duemilanove war das vollkommen egal.
    Wie aber bereits geschrieben wird das beim Verwenden des Arduinos als Ambilight-Controller nicht passieren, da der Arduino ja nicht am LED-Netzteil angeschlossen wird.
    Ich habe das Problem auch nur bemerkt weil ich einen arduino-Nano als Controller in einer mod-Leuchte verwendet (hab mir sowas nachgebaut: http://www.youtube.com/watch?v=T1p6yeHGh6M), bei der der Arduino ja mit am Netzteil angeschlossen werden muss weil die Leuchte ja nicht am USB hängt.
    Immer wenn ich den Arduino am USB anschließe spinnen dann die LEDs rum (solange die 5V am Vin vom Arduino angeschlossen sind).


    Tschau, Uwe.

    Hallo,
    ich habe bei mir einen Arduino Duemilanove wo der tpm2arduino-Sketch drauf läuft (das dürfte der von TheCief sein).


    Man könnte auch einen Arduino Nano nehmen. Die haben auch einen FTDI-RS232-Chip drauf, sind aber billiger und kleiner. Aber die mögen es nicht wenn USB und ein externes Netzteil angeschlossen ist, da die Schaltung zur Spannungsversorgung etwas anders ist.
    Das ist beim Ambilight aber ja ohnehin nicht der Fall (ist ja nur am USB angeschlossen).


    Der Sketch tmp2arduino ist sowohl mit dem SeduAtmo-Plugin als auch mit dem boblight deamon (für XBMC) kompatibel. Wie TheChief bereits geschrieben hat können alles Stripes genutzt werden welche von FastLED unterstützt werden.


    Edit: Das einzige Problem welches ich bei mir noch habe, ist das sich mit boblight der Arduino manchmal "verschluckt". Die LED werden dann nicht mehr aktualisiert. Ein kurzer Klick auf den Reset-Knopf des Arduinos reicht aber aus um das Problem zu beheben.
    Ich habe festgestellt dass das Problem von der Refreshrate vom Boblight (wird in der Config angegeben) abhängig ist. Die steht jetzt glaub ich auf einen Wert der 25FPS entspricht, wenn ich die noch etwas runter drehen würde, wäre das Problem ganz weg (bei etwas mehr FPS tritt es auch schon sehr häufig auf).
    Es kann aber auch an den sehr vielen LEDs von meinem Aufbau liegen. Ich habe 208 LEDs, was ja 624 Kanälen entspricht. Eventuell ist das für die Rate bereits grenzwertig (wobei es im Seduatmo Plugin problemlos geht).


    Tschau, Uwe.

    Hallo,
    masterpete: Achtung bei den LED-Stips dürfte nur aller 3 LED-Chips ein Controller verbaut sein, dadurch leuchten immer 3 LEDs in der gleichen Farbe. Besser sind welche wo jeder LED-Chip einen eigenen Controller hat.


    BooStar: Man kann beim Umschalten vom VDR zum XBMC das setuAtmo-Plugin deaktivieren und den boblight-deamon (der wird vom XBMC verwendet) aktivieren. Beim zurück wechseln dann einfach umgekehrt. Bei mir wird im gleichen Umschaltscript auch Lirc vom VDR deaktiviert damit im XBMC die Fernbedienung genutzt werden kann.


    Tschau, Uwe.

    Hallo Lars,
    ich habe jetzt auch mal geschaut welcher Typ wovon abgeleitet ist.
    Das einfachste wäre wenn man in dem Patch folgendes einbaut:


    Neue Variablen/Parameter:
    -der dvbPlayer erhält eine Variable "ForceRefreshMarks"
    -die Funktion cMarks::Update erhält einen zusätzlichen Parameter "ForceShortUpdateTime"


    Änderungen der Funktionen:
    -Solange ForceRefreshMarks beim dvbPlayer True ist, wird der Parameter "ForceShortUpdateTime" beim Aufruf von cMarks::Update mit True übergeben
    -Wenn cMarks::Update mit True zurück kehrt, wird "ForceRefreshMarks" auf False gesetzt (in dem Fall wurden die aktuellen Marken ja eingelesen)
    -Wenn "ForceShortUpdateTime" True ist, wird geprüft ob nextUpdate mehr als 5s in der Zukunft liegt, wenn ja, wird nextUpdate auf t gesetzt (und somit die eigentliche Funktion von Update forciert)
    Vor der Zeile nextUpdate = t + d, wird wenn "ForceShortUpdateTime" True ist d auf einen Wert kleiner 5s gesetzt.
    Dadurch wird, wenn in dem Durchlauf keine neuen Marken geladen werden, der nächste Durchlauf nicht sofort durchgeführt (nextUpdate liegt dann ja weniger als 5s in der Zukunft). Dennoch ist das Updateintervall so klein das es nur eine geringe Verzögerung gibt sobald die marks-Datei tatsächlich aktualisiert wurde.


    Es sind wirklich nicht viele Änderungen, aber ich habe keine Ahnung vom Programmieren/Compilieren im Linux (man müsste ja erst alle Patche anwenden, dann die Änderungen vornehmen und dann einen neuen Patch daraus generieren lassen).
    Tschau, Uwe.

    Hallo,
    ich habe mich gestern Abend mal noch etwas mit dem Thema befasst.
    An sich funktioniert der JumpPlay-Patch auch mit aktuellen VDR Versionen. Hauptproblem ist aber zurzeit das die aktuellen Schnittmarken vom Wiedergabeteil des VDRs ignoriert werden.
    Nach etwas lesen des Quelltextes habe ich aber gesehen das der Wiedergabeteil vom VDR in welchem auch der Hauptteil vom JumpPlay-Patch sitzt (dvbplayer.c), die Schnittmarken aktualisieren möchte. Dazu ruft er sehr oft (glaube bei jedem Frame bzw. Paket) von der Variable "marks" (Typ cMarks) die Update-Funktion.


    Diese Funktion liest das letzte Aktualisierungsdatum der marks-Datei und vergleicht dieses mit dem letzten bekannten Aktualisierungsdatum. Sollte sich das Datum geändert haben, wird die Datei und somit auch die Schnittmarken neu eingelesen (und würden dann auch dem dvbplayer/jumpplay-patch zur Verfügung stehen.
    Damit das Dateidatum nicht zu oft überprüft wird, mehr sich die Update-Funktion wann sie wieder mal auf eine Änderung der Datei prüfen muss. Dieser Zeitabstand wird abhängig vom Zeitpunkt der letzten Aktualisierung der marks-Datei ermittelt:


    Wie man sieht wird wenn die marks-Datei schon sehr alt ist (älter als 1h) ein sehr langer Aktualisierungsintervall gewählt (Variable d, welche den nächsten Aktualisierungszeitpunkt beeinflusst "nextUpdate = t + d;").
    Wenn nun die marks Datei während des Setzens der Schnittmarken geändert wird, würde die Variable marks vom dvbplayer erst davon etwas mitbekommen wenn der ermittelte Aktualisierungszeitpunkt (unter Umständen mehrere Minuten später) erreicht ist.
    Dieses Verhalten ist aber nicht neu und war auch schon in der 1.7.28 so. Was sich aber in neueren VDR Versionen geändert hat, ist der Zeitpunkt wann die marks-Datei beim Setzen der Schnittmarken geschrieben wird. Früher war es so das bei jeder Änderung der Schnittmarken die Datei sofort geschrieben wurde.
    Aktuell ist es aber so das sich beim Schieben der Marken nur gemerkt wird das sich diese geändert haben. Sobald dann die Wiedergabe/Schnittsteuerung geschlossen wird (der Dialog in dem die Schnittmarken/Wiedergabestatus zu sehen sind) indem man OK klickt oder die Aufnahme verlässt, wird geprüft ob sich die Marken geändert haben.
    Wenn ja, wird die marks-Datei geschrieben.


    Wenn man nun z.B. in einem Film die Schnittmarken ändert, wurde früher die marks-Datei beim ersten Ändern einer Schnittmarke geschrieben. Aktuell ist es aber so das die Datei erst geschrieben wird wenn man OK auf der Fernbedienung geklickt hat.
    Angenommen der Aktualisierungsintervall von cMarks.Update wurde auf 2min gesetzt (also aller 2min wird das Dateidatum geprüft). So war die Wahrscheinlichkeit dass wenn man mit dem Setzen der Schnittmarken fertig war, die Update Funktion diese bereits gelesen hat (bei Änderung, wird der Updateintervall dann auf 1s geändert, so dass weitere Änderungen sofort erkannt werden). Jetzt wird die Datei aber erst viel später geschrieben, so dass man in dem Beispiel eventuell erst nach 2min die aktuellen Schnittmarken im dvbplayer zur Verfügung hat.


    Ich habe mal folgenden Test durchgeführt:
    Test 1:
    -aktuelle marks-Datei in einer Aufnahme erzeugt (einfach irgendeine Schnittmarke ändern und Wiedergabe verlassen)
    -Wiedergabe gestartet, durch sehr aktuelle marks-Datei wird der Aktualisierungsintervall von cMarks.Update beim Öffnen der Aufnahme sehr kurz eingestellt
    -Schnittmarke geändert (ok geklickt um Fenster zu schließen und marks-Datei zu schreiben)
    -ein paar Sekunden vor die Schnittmarke gesprungen und Wiedergabe fortgesetzt
    Die Schnittmarke wurde durch das kurze Aktualisierungsintervall bereits eingelesen und der JumpPlay-Patch hat korrekt an der geänderten Marke funktioniert


    Test 2:
    -Wiedergabe einer ältere Aufnahme gestartet, durch sehr alte marks-Datei wird der Aktualisierungsintervall von cMarks.Update beim Öffnen der Aufnahme sehr lang eingestellt
    -Schnittmarke geändert (ok geklickt um Fenster zu schließen und marks-Datei zu schreiben)
    -ein paar Sekunden vor die Schnittmarke gesprungen und Wiedergabe fortgesetzt
    Die Schnittmarke wurde durch das lange Aktualisierungsintervall noch nicht eingelesen und der JumpPlay-Patch die geänderte Marke ignoriert
    Hätte ich längere Zeit gewartet wäre der nächste Aktualisierungszeitpunkt von cMarks.Update erreicht gewesen und die aktuellen Marken wären eingelesen worden.


    Ich denke wenn man in der cMarks::Update-Funktion den maximalen Intervierungsintervall verkürzt (z.B. auf 10-30s) dürfte die Verzögerte Aktualisierung der Schnittmarken vom dvbplayer bei normalen Nutzungsverhalten nicht mehr auffallen (man hat ja fast immer mehr als 30s bis zur ersten Schnittmarke/Werbung eines Films).
    Da bei nicht so alten marks-Dateien ohnehin ein Intervall von 1-10s verwendet wird ohne das der VDR davon gestört wird, dürfte ein maximales Intervall von 30s vollkommen unkritisch sein.


    Tschau, Uwe.