Posts by shofmann

    Ich nutze das Info-File ebenfalls, um begleitende Informationen als Teil des Subtitle (Tag "S") abzulegen. Insofern stört es schon, wenn die Änderungen nicht per 'touch .update' sichtbar gemacht werden können. Der beigefügte Patch sollte aber Abhilfe schaffen, indem er bei bereits bekannten Aufnahmen nur die Info-Datei erneut einliest, die Liste der Aufnahmen an sich aber unverändert belässt. Der einzige Wermutstropfen ist, dass man die List der bereits bekannten Aufnahmen immer durchsuchen muss. Was umso unangenehmer ist, da diese Liste linear durchsucht wird. Aber obwohl die Liste bei mir ziemlich umfangreich ist, wirkt sich dies glücklicherweise nicht merklich auf die Performance aus... :)


    @Klaus, wäre dies eventuell eine Lösung für v2.2.1?


    Viele Grüße
    Stefan



    PS: Der erste Patch sprang leider zu kurz, da ReadInfo() die Stream-Komponenten nicht (wie gedacht) mit den Daten aus der Info-Datei aktualisiert, sondern die Daten bei jedem Aufruf an die bereits bestehende Komponenten-Liste anfügt. Damit erhöht sich bei jedem Update die Zahl der Video- und Audio-Streams in der Info-Anzeige – und bei einem eventuellen Update der Info-Datei auch dort... Der revidierte Patch #3 löscht die Stream-Komponenten beim (Wieder-)Einlesen der Info-Datei.

    Danke auch für den Hinweis mit dem Makefile – die Info hatte ich noch nicht. Nach der Umstellung der Makefiles für mein „Ökosystem“ möchte ich für mich diese Baustelle derzeit nicht wieder aufmachen. Zudem benötigt der Test dieses Makefiles in meinem Ökosystem samt Anpassung von Patch 3 doch etwas mehr Zeit, und die fehlt mir heute. Da Patch 3 von Patch 1 abhängt, vorerst kein Update des OSD-Patches...


    Vereinfachungen gegenüber bin ich ja durchaus aufgeschlossen. Und weil ich heute Zeit und Lust dazu hatte, habe ich CReimers Makefile bei mir doch noch integriert. Scheint soweit alles zu passen, sodass ich die geänderten Patches nochmals in den ersten Beitrag des Threads hochgeladen habe.


    Bitte um Feedback, wenn es noch irgendwo knirschen sollte.


    Viele Grüße
    Stefan

    Ein paar Dinge sind mir aufgefallen. Das "Festtackern" des Headers funktioniert leider nur bei eingeschalteter Statusbox. Meinereiner hat das noch nie benutzt, weil es Platz verschwendet und wenig informativen Nutzen bringt. Prima wäre, wenn man nur die Menüleiste festtackern könnte.


    Für die Experimentalfraktion (vdr 2.1.6) müssen zusätzlich einige Files (pages/recordings.ecpp, tools.cpp, recman.cpp) gepatched werden. Außerdem passt das Makefile so noch nicht ganz. Gerade wenn man aus dem Directory heraus compiliert und installiert. Schau dir mal das Repo von CREIMER an. Sein Makefile funzt mit deinen Patches wunderbar.

    Erst einmal danke für die Rückmeldung. Patch 2 hat den HTML-Code zum „Festtackern“ an der falschen Stelle eingefügt. Ich habe es korrigiert und den Patch ersetzt.


    Danke auch für den Hinweis mit dem Makefile – die Info hatte ich noch nicht. Nach der Umstellung der Makefiles für mein „Ökosystem“ möchte ich für mich diese Baustelle derzeit nicht wieder aufmachen. Zudem benötigt der Test dieses Makefiles in meinem Ökosystem samt Anpassung von Patch 3 doch etwas mehr Zeit, und die fehlt mir heute. Da Patch 3 von Patch 1 abhängt, vorerst kein Update des OSD-Patches...


    Viele Grüße
    Stefan

    Hallo zusammen,


    vor einiger Zeit hatte ich mir – unter anderem – gewünscht , dass die Live-Navigationsleiste beim Scrollen am oberen Seitenrand fixiert bleibt. Ich habe hierzu einen Patch erstellt, der zumindest bei mir mit Firefox, Chrome, Safari und IE das gewünschte leistet. Hier als Beispiel die Programmübersichtsseite zum Vergleich:



    Die Navigationsleiste passt sich bei Änderung der Fensterbreite entsprechend an (im Beispiel ist sie bereits zweizeilig). Um den Aufwand durch den Zeilenumbruch langer Sendungstitel in der Infobox zu begrenzen und nicht in deren Ajax-Routinen eingreifen zu müssen, hebt der Patch die feste Breite der Infobox auf und lässt sie bei Bedarf wachsen (sodass der Titel weiterhin einzeilig bleibt).


    Insgesamt habe ich für mich mehrere Patches in Live eingefügt, die ich nachfolgend zum Download bereitgestellt habe:

    • live-makefiles+channels+recsort.diff
      Ersetzt die alten Makefiles durch CReimers konsolidiertes Makefile und dessen README; begrenzt die Programmauswahl auf die im Setup eingestellte Anzahl von Kanälen (Einzelpatch hier); sortiert die Aufnahmen ohne führende "Grafikzeichen" (@, % usw.), also so, wie im OSD.


    • live-fixnavigation.diff
      Fixiert, wie oben geschildert, die Live-Navigationsleiste am oberen Seitenrand; sollte auch isoliert (also isoliert ohne den oben stehenden Patch) funktionieren.


    • live-osd-after-fixnav.diff
      Weil sich der FixNav-Patch mit dem OSD-Patch überlagert, hier als Ergänzung der OSD-Patch, der die aufgrund des FixNav-Patches geänderten Anker berücksichtigt.

    Ich würde mich freuen, wenn die nächste Version des Live-Plugins diese Patches integrieren würde.


    Viel Spaß mit dem gepatchten Live-Plugin
    Stefan

    Hallo zusammen,


    ich habe vor einem guten Jahr angefangen, mich nach endlos langer Zeit, in der ich den c't VDR 1.4 genutzt habe, wieder mit der aktuellen VDR-Entwicklung zu beschäftigen. Ohne die Informationsquellen im VDR-Wiki – insbesondere die Installationsanleitungen zum Bauen des VDR 1.7.x sowie der DVB-Treiber – wäre ich nie auf einen grünen Zweig gekommen. Oder hätte zumindest Monate damit verbracht, das alles aus irgendwelchen Blogs oder Threads zusammenzutragen bzw. mir per Versuch und Irrtum selbst zu erarbeiten. Auch die Übersicht der Plugins mit weiterführenden Lins sowie das Browsen in der (leider nicht ganz aktuellen) Doxygen-Dokumentation sind meines Erachtens wertvolle Hilfen.


    Insofern fände ich es extrem schade, wenn das Wiki als Informationsquelle, die vor allem für Neu- bzw. Wiedereinsteiger von großer Hilfe sein dürfte, versiegen würde. Die Informationen anderweitig bereitzustellen wäre natürlich eine valide Alternative – auch wenn ich dafür keinen heißen Tipp habe, wie dies am besten und mit geringstem Aufwand möglich sein könnte.


    Mein Plädoyer wäre also, das VDR-Wiki in einer geeigneten Form weiterzuführen.


    Allen, die sich bei der Entwicklung des VDR, hier im Forum und auch beim VDR-Wiki engagieren, möchte ich doch an dieser Stelle einmal ein herlichen "Dankeschön!" sagen.


    VG Stefan

    Doch, das reicht mir aber. Wer schreibt schon Beispiele in seine Signatur, die er so nicht einsetzt.
    Ihr werdet das schon noch aufklären ;-).


    Klar kann ich das aufklären: Wenn der VDR zum Fernsehen benutzt wird, läuft die Wiedergabe natürlich über die FF-Karte. Wenn ich mal von meinem normalen Rechner schnell in eine Sendung reinschauen möchte, kommt StreamDev mit dem VLC-Media-Player zum Einsatz.


    XineLibOutput benötige ich dann, wenn ich am VDR selbst bzw. einem Plugin bastele oder mit dem Ubuntu-Desktop arbeiten und den VDR mitlaufen lassen möchte. In diesem Fall hole ich mir das Videobild per vdr-sxfe auf den Desktop (wofür ich dann auch mal ALSA brauche). Dies führt übrigens dazu, dass die Ausgabe über die FF-Karte abgeschaltet wird, weil der VDR offensichtlich nur auf ein Device gleichzeitig ausgibt.


    Soviel dazu. Die beschriebenen Effekte sind aber immer dann aufgetreten, wenn ich den VDR "nur" zum Fernsehen benutzt habe. Also ohne irgendwelche Wechsel von Ausgabegeräten.


    Stefan

    Ich kann mich meinen Vorrednern nur anschließen: VDR ohne Live ist irgendwie undenkbar. Deshalb allerherzlichsten Dank an alle, die Live ins Leben gerufen haben und sich bei seiner Maintenance engagieren!


    Eines hat mich allerdings vor längerer Zeit schon gestört, nämlich, dass ich zwar angeben kann, bis zu welchen Programmplatz ich die Programmübersicht haben möchte, die Auswahlliste aber immer alle Programme (bei mir somit eine vierstellige Zahl von Programmen) umfasst. Dies löst der kleine beigefügte Patch, den man gegebenenfalls in den Quellcode übernehmen könnte.


    Noch ein Punkt für die Wunschliste: Genial wäre eine grafische Anordnung von Timern auf einem Zeitstrahl, wie vdr-admin sie darstellt, kombiniert mit der Information, welche Aufzeichnungen über welche Karte laufen werden (vielleicht also sortiert nach Empfangskarten). In dieser Darstellung wäre die Identifikation und Auflösung von Timerkonflikten (bei welchem muss ich z.B. ein wenig am Nachlauf abzwicken, bei welcher vielleicht zusätzlich am Vorlauf) viel leichter zu erledigen, weil um Vieles übersichtlicher.


    Nochmals vielen Dank!


    Stefan

    Gut ich hätte schreiben können "Ausgabefrontend oder Alsa", wobei ich nicht sicher bin ob die FF-HD überhaupt Alsa benötigt.


    Nein, benötigt sie nicht. Über das HDMI-Interface der FF-Karte werden Bild und Ton an den Fernseher geliefert. Nachdem ich von Allem die aktuellen Pakete im Einsatz habe (Media Build Experimental mit TT-6400-Treibern, VDR samt mitgeliefertem DvbHdDevice, Plugins...) wäre meine intuitive Erwartung, dass solche Probleme nicht (mehr) auftreten sollten.


    Intuitiv würde ich auf ein Problem im Puffer-Management des Videostroms tippen, wobei ich aber nicht sagen kann, ob es den VDR, das DvbHdDevice oder den SAA716x-Treiber betrifft. Dazu stecke ich leider nicht tief genug in der Materie drin... Es könnte aber natürlich auch ein Plugin dafür verantwortlich sein, das an der Verarbeitung von Videoströmen beteiligt ist, wie etwa XineLibOutput oder StreamDev.


    Bin mal gespannt, ob sich diesbezüglich bei der jetzt stabilen 2.0.0 noch eine Verbesserung ergeben hat. Ansonsten werde ich mal checken, ob das Abschalten o.g. Plugins eine Änderung (Verbesserung) des Verhaltens bewirkt.


    Viele Grüße
    Stefan

    Hallo Klaus und alle Helfer,


    auch von mir ein herzliches "Danke schön!" für die neue Version. Wie viele Vorredner schon angemerkt haben, ist für mich Fernsehen ohne den VDR gar nicht mehr richtig vorstellbar... Dieses geniale Teil hat schon vor Jahren fernsehen für mich revolutioniert.


    Ich freue mich schon darauf, wie es weitergeht... und wahrscheinlich wird die 2.0.0 gar nicht einmal lange "stabil" auf meinem System bleiben. Die bisherigen Entwicklerversionen, die ich installiert hatte, waren immer ohne wirkliche Probleme und haben sich auch im "Produktiveinsatz" bewährt. Insofern werde ich wohl auch weiter am Ball bleiben und die erste 2.1.0 installieren... :)


    Viele Grüße
    Stefan

    Ist IMHO ein Problem in Deiner Installation, keines vom Core-VDR. Ich tippe auf Ausgabefrontend & Alsa ...

    Bitte nicht so vorschnell: Wie aus meiner Signatur ersichtlich, benutze ich – ebenso wie meines Wissen Klaus – eine TT-6400. Also kein Bezug zu VDPAU, ALSA und dergleichen. Nachdem das DvbHdDevice integraler Bestandteil des VDR Core ist, sollte man dem Problem wohl schon nachgehen und nicht immer gleich auf einen DAU tippen...


    Die Treiber (Media Build Experimental) sind bei mir auf dem neuesten Stand (sprich: 2013-03-10), ebenso die Firmware.


    Zudem: Habt doch Geduld, bis Klaus mal Zeit hatte, sich eine eigene Meinung hierzu zu bilden.


    Viele Grüße
    Stefan

    Klaus,


    hier eine Beobachtung, die ich versehentlich in einem Announce-Thread gepostet hatte: Ich springe relativ häufig mit "Gelb" und "Grün" schnell minutenweise durch eine Aufzeichnung, um den Beginn
    der gewünschten Sendung bzw. die zum Schneiden relevanten Stellen zu
    finden. Meistens ist dies dann erforderlich, wenn MarkAd keine Schnittmarken setzen konnte.


    In etwa 10–15 Prozent der Fälle setzt das Bild mit Klötzchen
    wieder ein oder – was eher der Fall ist – die Tonspur klingt metallisch verzerrt. Auch habe ich schon erlebt, dass überhaupt kein Ton kam. Nach Verändern der Position (Sprung um eine Minute vor oder zurück bzw. Vorlauf oder Rücklauf) setzt der Ton fast immer wieder ein (was somit als Workaround dient). Die gestörte Wiedergabe nur auf Pause schalten und die Aufzeichnung fortsetzen hat hingegen keinen positiven Effekt.


    Ein ähnliches Verhalten wurde,
    soweit ich mich erinnere, schon gelegentlich für Vorgängerversionen
    gemeldet, scheint aber noch immer nicht völlig behoben zu sein.
    Eventuell ein Problem mit beim Springen unvollständig geleerten Puffern?


    Für die in Kürze anstehende Stable-Version wäre es natürlich vorteilhaft, wenn dieses kleine Problem noch gelöst werden könnte.


    Wie immer Danke für dein unermüdliches Wirken!


    Schöne Feiertage
    Stefan

    Bitte für jeden Report einen eigenen Thread mit beschreibendem Subject starten.


    Ich würde mir noch wünschen, dass der Titel eines jeden Threads konsequent mit der VDR-Version getaggt ist, für den ein Problem gemeldet wurde. Zum Beispiel mit „[1.7.42] ...“ Nur dann hat man – ähnlich wie in den Announce-Threads – die Chance, einfach und schnell herauszufinden, welche Probleme einen potentiell erwarten, wenn man auf eine neue Version upgraden möchte, ohne erst alle Threads der jüngeren Vergangenheit durchforsten zu müssen.


    Aber vielleicht trage ich mit diesem Ansinnen ja nur Eulen nach Athen...


    Viele Grüße
    Stefan

    Man kann trotzdem auf den Wunsch von Klaus eingehen: Neuer Bereich für Core-VDR


    Das habe ich irgendwie übersehen. Klar gehen wir auf Klaus’ Wunsch ein. Schön wäre es, wenn in „VDR Core“ jeder Thread dann auch gleich im Titel mit der VDR-Version getaggt ist, für den ein Problem gemeldet wurde, damit man sich schnell die relevanten heraussuchen kann...


    Stefan


    Es ist jetzt schon mehrfach und an den unterschiedlichsten Stellen gesagt worden, dass Fehlermeldungen nicht in Announce-Threads gehören. Was ist daran denn eigentlich so schwer zu verstehen?


    Gerald

    Na, wozu sind denn Announce-Threads da? Genau hier würde ich erwarten, alle potentiellen Probleme zu finden, die mir mit der neuen Version begegnen könnten anstelle mich hierfür quer durch das Portal wühlen zu müssen.


    Wenn das unerwünscht ist, würde ich halt nur das Announcement posten und den Thread gleich schließen/sperren. Dann herrscht die gewünschte Grabesruhe.


    Im übrigen gefällt mir der Tonfall der letzten Postings gar nicht. So war ich das in den letzten Monaten nicht gewöhnt, seit ich angefangen habe, mich ein wenig zu engagieren...


    Stefan

    ich habe heute VDR 1.7.41 und die aktuelle epgsearch Version (aus dem GIT) installiert. Leider werden alle Timer mit der ID 1 angelegt und somit natürlich alle überschrieben.


    Das kann ich nicht bestätigen. Bei den diversen Upgrades der letzten Wochen sind alle Autotimer brav weitergelaufen und bereits gesetzte Timer wie geplant ausgeführt worden. Die Versionsfolge war:

    • VDR 1.7.38 / EPG Search @ 20130209-1210
    • VDR 1.7.40 / EPG Search @ 20130209-1210
    • VDR 1.7.41 / EPG Search @ 20130313-1108
    • VDR 1.7.42 / EPG Search @ 20130319-1845

    Zum Einsatz kam jeweils EPG Search aus dem GIT-Archiv in der Version zu den angegebenen Zeitstempeln.


    Stefan

    Ich habe die neue Version vor Kurzem gebaut, und bislang läuft sie zusammen mit meinen üblichen Plugins auch auch prächtig.

    Quote

    So please test this developer version intensely and report any problems you might encounter as soon as possible.

    Klaus,


    ich habe die neue Version jetzt seit ein paar Tagen am Laufen. Folgendes ist mir hierbei aufgefallen:

    • Wenn zum Beispiel MarkAd keine Schnittmarken gesetzt hat, springe ich mit "Gelb" schnell minutenweise durch eine Aufzeichnung, um den Beginn der gewünschten Sendung bzw. die zum Schneiden relevanten Stellen zu finden. In etwa 10–15 Prozent der Fälle setzt das Bild mit Klötzchen wieder ein oder die Tonspur klingt metallisch verzerrt. Letzteres wurde, soweit ich mich erinnere, schon gelegentlich für Vorgängerversionen gemeldet, scheint aber noch immer nicht völlig behoben zu sein. Eventuell ein Problem mit beim Springen unvollständig geleerten Puffern?


    • Gestern hatte ich bei einer Aufzeichnung mehrfach den Effekt, dass der Ton kurzzeitig ausfiel und gleichzeitig Teile des Bilds eingefroren sind und sich anschließend nur klötzchenweise wieder aufgebaut haben. Nach ein paar Sekunden war der Spuk vorbei, und die Aufzeichnung lief für einige Minuten fehlerfrei weiter, bis sich dieser Effekt wiederholte. Einen solchen Effekt hatte ich noch mit keiner der 1.7er-Versionen beobachtet. Ich bin mir nicht sicher, ob das (nur) auf einen fehlerhaft initialisierten DVB-Treiber zurückzuführen und somit ein einmaliger Effekt war oder ob sich hier eine Regression im VDR zeigt.

    Abgesehen davon läuft der VDR recht zuverlässig. :tup


    Viele Grüße
    Stefan

    Das hängt (zuumindest unter Debian) vom Stand des Paketes "linux-libc-dev" ab, da ist die DVB API drin. Es kann sein das du heute DVBDIR setzen musst, aber nächste Woche nicht mehr (wenn linux-libc-dev zwischenzeitlich in ner neuen Version reinkam).


    Was wäre denn die Empfehlung:

    • Primär die Header-Files der Linux-Distribution verwenden (Ubuntu hat sie scheinbar auch drin), d.h. DVBDIR nicht setzen?
    • Oder besser explizit die Header-Files von media_build_experimental referenzieren, also DVBDIR immer setzen? Hat DVBDIR in diesem Fall auch Priorität, d.h. werden dann wirklich dessen Header-Files und nicht die der Distribution genutzt?

    Dass ich offensichtlich die Header-Files der Distribution und nicht die der Treiber verwende, könnte gegebenenfalls ein paar seltsame Effekte erklären, die ich in letzter Zeit beobachtet habe.


    Danke jedenfalls für den Hinweis
    Stefan

    Die Vorlage für DVBDIR in Make.config.template ist in der 1.7.36 leider "untergegangen".


    Dann finde ich es spannend, dass der VDR sich auch ohne diese Include-Files problemlos übersetzen lässt. Werden die überhaupt gebraucht, oder benötigen nur spezielle Video-Treiber diese? Das DvbHdDevice benötigt sie offensichtlich nicht... ;D


    Stefan

    Hast du es schon mal mit 'make LCLBLD=1' versucht? Damit wird über HDRDIR das VDR-Include-Verzeichnis in die cxxflags der vdr.pc geschrieben.


    Klaus,


    danke für den Hinweis. Aus der Beschreibung in Make.config.template:


    Code
    1. # Use 'make LCLBLD=1' to build locale and plugin files under the source directory


    würde ich aber verstehen, dass ich LCLBLD=1 setzen muss, wenn ich den VDR samt Plugins ausschließlich von innerhalb des VDR-Sourcebaums (also ohne weiteres Umkopieren der produzierten Files im Rahmen eines Installatiosnvorgangs) betreiben will. Was bei mir aber nicht der Fall ist, da ich die produzierten Files alle von den Source-Verzeichnissen nach /usr/local/vdr-1.7.xy in eine entsprechende Baumstruktur kopiere (siehe meine vdr.pc weiter oben).


    Zumal im VDR-Makefile LCLBLD nur dazu führt, dass nach dem Bauen des Plugins eine Mini-Installation nach PLUGINS/lib und PLUGINS/locale durchgeführt wird. Sonst passiert nichts weiter...


    Oder habe ich die Bedeutung von LCLBLD komplett falsch interpretiert? Dein Hinweis würde ja das genaue Gegenteil meiner Interpretation nahelegen.


    Grüße
    Stefan