Posts by Urig

    Meld mich auch mal zurück. Bin momentan auch eher wenig aktiv, daher die Reaktionszeiten. Im Zweifelsfall immer in den vorherigen Post was schreiben, den hab ich normalerweise im Abo.
    Wenn es zeitlich passt, schau ich aber gerne vorbei, allerdings streiten sich bei mir immer viele Dinge um die knappe Wochenend-Zeit.


    Gruß,


    Udo

    Hier auch nochmal mein Kommentar dazu:


    Früher war die Rolle von -1 receivern an den bool-Parameter NeedsDetachReceivers gekoppelt, der gerade im Fall des Kanalwechsels eben genau dieses Verhalten unterdrückt hat. Das geschah insbesondere, weil die transfer mode Receiver ebenfalls auf Priorität -1 laufen, und es sonst durch im Hintergrund startende Aufnahmen dazu kam, dass der transfer mode gekappt und nicht wieder verbunden wurde.


    Wenn solche Seiteneffekte heute ausschließbar sind, spricht nichts dagegen, aber das ist definitiv ein kleines Minenfeld aus Seiteneffekten.



    Etwas historische Lektüre zum Thema:
    http://www.linuxtv.org/pipermail/vdr/2008-June/017073.html
    http://www.linuxtv.org/pipermail/vdr/2010-July/023240.html



    Die Alternative wäre, ein zu IsTunedToTransponder analoges Verhalten auf beliebige Devices zu erweitern, z.b. als IsTunedToTransportStream, worum es hier ja eigentlich geht: Kann das Device diesen Kanal zusätzlich empfangen, ohne irgend etwas anderes zu stören?


    (Hintergrund: Bei FF-Karten kann ein Device absichtlich auf einen Transponder/Stream getuned sein, ohne einen einzigen Receiver darauf zu haben, deswegen reicht es nicht, nur die Receiver zu betrachten.)



    Gruß,


    Udo

    "obsolete channels": Mal sehen, wie gut sich das mit meiner Lösung deckt, die über einen kleinen Hack den Zeitpunkt mitloggt, wann ein Channel zuletzt announced wurde. Das hatte dann gleich noch den Vorteil, dass man Sender erst nach einer Karenzzeit verschwinden lassen konnte. (Und produziert leider Fehlalarme, wenn die zum Empfang nötige Hardware (-> DVB-T) lange nicht angeschlossen war.)

    Ich habe so ein Teil.
    Verliert sporadisch die BT Verbindung, was mich tierisch nervt. Würde ich nicht nochmal kaufen.


    Kann ich bestätigen. Ich brauche sie nur, um gelegentlich mal auf den Desktop zu wechseln, dafür reicht sie. Die Verbindung (ca. 3-4 Meter) reißt regelmäßig spätestens nach 20-30min ab, dann muss man manchmal die Tastatur aus/einschalten, manchmal muss man aber auch den BT-Dongle rausziehen und reinstecken, um sie wiederzubeleben. Hab mir bisher nicht die Mühe gemacht, nach Lösungen zu suchen. (Debian/Wheezy)


    Gruß,


    Udo

    Sehr wahrscheinlich. Als Aktivität wird nur ein (simulierter) Tastendruck gewertet, das Live-Plugin löst dagegen direkt die Kanalumschaltung aus, statt blind irgend welche Tasten zu senden, die vielleicht einen Kanalwechsel (oder irgend etwas anderes) auslösen.


    Die Alternative wäre, den VDR erst mal mittels einer Pseudo-Fernbedienung zu bedienen, z.B. per Telnet (Remote-Plugin kann das) oder einem Fernbedienungs-Programms / App, die dann per SVDRP Tastendrücke auslöst.


    Gruß,


    Udo

    Sorry, ich war in letzter Zeit erschreckend inaktiv. Ich schiebe es auf zu wenig Zeit, zu viele andere Dinge, und einen zu stabil laufenden VDR. ;)


    Insbesondere in runvdr extreme kommt aber gerade Bewegung, da Mreimer gerade einige Verbesserungen beisteuert. Die (jetzt gemeinsame) Weiterentwicklung findet hier statt:


    http://projects.vdr-developer.org/projects/runvdr-extreme


    So bald daraus eine neue Version erwächst, werde ich die von meiner Webseite aus verlinken.


    Gruß,


    Udo


    Alle Verzeichnisse müssen unter /video (oder was halt der User dafür mittels --video verwendet) liegen, und Aufnahmen gehen grundsätzlich nach /video/local (falls diese Variante aktiviert ist). Die Konfigurationsdateien bleiben direkt unter /video.
    Fragt sich nur noch, wie das dann gehandhabt werden soll, wenn /video/local aus mehreren physikalischen Platten bestehen soll


    Eine denkbare, einfache Erweiterung des /video/local Konzepts wäre es, im Timer-Dialog eine zusätzliche Option anzubieten, die den "Ziel-Datenträger" wählbar macht. Standardmäßig wäre da "local" (bzw. ein konfigurierbarer Default-Datenträger) ausgewählt, aber wenn man /video/hdd1 und /video/hdd2 hat, kann man dort entscheiden, ob die Aufnahme auf hdd1 oder hdd2 landen soll. Der Timer-Dialog kann das Ziel direkt in den klassischen Timer-Titel einbauen, sodass nicht mal eine Änderung an cTimer oder der timers.conf nötig wird, und auch unangepasste Plugins würden grundsätzlich damit klar kommen, da es ja nur ein Teil des Titel-Strings ist.




    Zusätzliche .skip oder .hidden Dateien halte ich für deutlich komplizierter und aufwendiger.


    Die hätten auch den Nachteil, dass sie in dem Verzeichnis liegen, und damit nicht Teil des Mount-Namens sind. Die Option wäre zwingend für alle Clients und den Server gleich zu setzen, insbesondere gäbe es auf dem Server ein sinnfreies /video/.skip.

    Wenn remote syslog nicht zum Ziel führt, es gibt auch einen Mechanismus des Kernels, die Kernelmessages per Netzwerk auf einen anderen PC zu lenken. Da das sehr tief in den Netzwerkstack eingebaut ist, kann man damit sogar bei boot/suspend/hibernate noch kernel panic Meldungen und ähnlich fatale Meldungen fangen. Such mal nach dem Stichwort Netconsole.


    Gruß,


    Udo

    Klasse Idee. Aber könnte man das auch explizit umschaltbar machen?


    Hintergrund: Wenn ich meinen VDR lokal fernbediene, geht das problemlos mit Bild, wenn auch langsam, weil HD-Bilder. Wenn ich mich aber per VPN einwähle, ist der Einzelbild-Upload viel zu langsam, um darüber irgend was zu bedienen. Wenn man in der Situation einfach auf einen high level OSD-Modus umschalten könnte, wäre das Problem gelöst.


    Gruß,


    Udo

    Das letzte, was von der C't zum Thema VDR zu lesen war, war eine Anleitung, wie man einen VDR auf Ubuntu-Basis aufsetzen kann, ich denke, das kann man als Zeichen sehen, dass es kein Update für C't-VDR mehr geben wird.


    Gruß,


    Udo


    Ist bereits vorgesehen für eine der kommenden Developer-Versionen.


    Wo das gerade Thema ist, schlage ich gleich etwas vor, das ich in einem privaten Patch für Channels bereits nutze: Ein Zeitstempel, wann die Information zuletzt empfangen wurde.


    Theoretisch könnte man alles zusammen auf die Spitze treiben, in dem man Zeitstempel für first-seen, last-seen und last-modified aufbewahrt, dann hat man alle Informationen verfügbar.


    In meiner Anwendung nutze ich diese Zusatzinfos, um das Auftauchen und Verschwinden von Channel-Announcements zu erfassen, und tote Kanäle löschen zu können.


    Gruß,


    Udo

    Als alternativen Denkansatz würde mir noch einfallen, innerhalb des Cachedir eine Verzeichnisstruktur aufzubauen, z.B. $CACHEDIR/tmp und $CACHEDIR/run, welche dann ggfs. als Symlink auf geeignete Verzeichnisse verlinkt werden. Hilfsfunktionen, die $CACHEDIR/tmp/$PLUGINNAME generieren, könnte man ggfs. auch noch bereit stellen, auch sollte klar sein, das Verzeichnisse bei Bedarf noch erstellt werden müssen.


    Andererseits wäre es auch eine dankbare Lösung, dem osdteletext-Plugin endlich mal eine In-Memory Datenstruktur zu verpassen. Im STL-Zeitalter ist es ja nun wirklich einfach, komplexere Datenstrukturen aufzubauen, einfacher jedenfalls, als eine Verzeichnisstruktur auf Platte zu managen.


    Gruß,


    Udo

    Hätt ich Zeit, würde ich einen Salat beisteuern, aber leider ist schon alles ausgebucht. Ich könnte höchstens noch einen fertigen Kartoffelsalat oder Krautsalat beisteuern.


    Wie steht es mit Getränken? Aus alter Erfahrung würde ich nen Kasten Cola beisteuern. ;)


    Gruß,


    Udo

    2.6.27 hat DVBAPI 3.2, das wird selbst von den s2apiwrapper-Patches nicht mehr unterstützt. Wenn du also nicht gerade den 2.6.27 mit passenden s2api-DVB-Treibern übersetzt, und VDR gegen deren Header übersetzt, wird das nichts.


    DVBAPI 5.0 kam mit 2.6.28, ab da sollte es dann gehen - mit VDR 2.0.1 sogar out of the box.

    Meiner läuft auch noch auf einem aufgebohrtem 2.6.32. Warum? Nun, er läuft. Mit einem aktuelleren Kernel könnte ich es auch versuchen, nur weiß ich jetzt schon, dass die alten Lirc-Module (iMON PAD emuliert über eine Harmony, die wird heute ganz anders angebunden) auf neueren Kerneln nicht mehr gehen, also wird auch noch ein Update des gesamten Lirc-Systems fällig, falls ein aktuelles LIRC überhaupt noch zum laufen zu bringen ist. Plus DVB-Treiber, die müssen ja auch passend rein. Und dann wieder ganz von vorne anfangen, meine Fernbedienung zum laufen zu kriegen.


    Ich denke, ich spar mir das Wochenende an Arbeit, bis Wheezy fertig ist, das ist früh genug.

    Man könnte ihn sicher noch abmagern. Light ist er im Vergleich zum alten Patch, der das S2API mit Mitteln des alten DVBAPI nachbaut. Das ist zum Glück beerdigt.


    Alles was in der s2apiwrapper.h noch drin steckt, ergänzt nur die Definitionen, die in der frontend.h seit API 5.0 dazu gekommen sind, schön Version für Version, damit nichts doppelt deklariert wird. Ich hab sicherheitshalber einfach mal alle Änderungen gesammelt, falls irgendwann mal was davon nötig wird. (Ich hab auch eine komplette Sammlung aller frontend.h's, wer Interesse hat.)


    VDR braucht nur eine Handvoll davon, ohne Anspruch auf Vollständigkeit glaube ich FE_CAN_TURBO_FEC, DTV_DVBT2_PLP_ID, DTV_STREAM_ID, FE_CAN_MULTISTREAM. Bleibt es bei der Einschränkung auf API >= 5.3, ist die gesamte s2apiwrapper.h überflüssig, da VDR ja auch alles mitbringt. Das würde den Patch wohl auf die ersten 130 Zeilen eindampfen.


    Der Rest ist die Runtime-API-Versionsabfrage, und die paar Codeweichen. Bei den Delivery Systems gönne ich mir noch das Fallback-Verhalten von plain VDR bei API >= 5.5, wahrscheinlich würde hier aber auch eine einfache Codeweiche (DTV_ENUM_DELSYS ab >= 5.5, Legacy Mode bei < 5.5) genügen.


    Etwas unaufgeräumt ist auch, dass jedes Device das DVB-API ermittelt und speichert, ein mal zentral würde auch genügen. War halt so einfacher zu patchen.


    Gruß,


    Udo

    Wie schon gesagt, der HL-Cutter wurde von den Änderungen am Cutter ausgehebelt, wenn überhaupt könnte er nur als komplett alternative Schnittfunktion zurück kommen, zum Preis der nicht korrigierten Timestamps. Damit ist es aber ein weitgehender Rewrite, und dafür hab ich momentan nicht die Zeit.


    Fehlen tut er mir, es war jedenfalls ein Schock, als plötzlich HD-Aufnahmen von Filmen statt 10-20 Sekunden plötzlich eher 10 Minuten zum Schneiden brauchen. Auch dass man nicht während einer Timer-Aufnahme eine andere schneidet, hab ich schmerzlich wieder gelernt, der HL-Cutter war da immer so flink, dass sich gar kein Datenstau bilden konnte.


    Wenn es mal eine neue Version gibt, kommen vielleicht auch neue Features. BTRFS_IOC_CLONE_RANGE klingt einfach zu praktisch, dafür würde ich sogar das Dateisystem wechseln: Noch schnelleres Schneiden, selbst bei großen Dateien.


    Gruß,


    Udo

    Mal für die Akten, da man das sonst nirgends aufgeschlüsselt findet:


    Linux-3.8: DVBAPI 5.9 (Ubuntu 13.04 'Raring Ringtail')
    Linux-3.7: DVBAPI 5.9
    Linux-3.6: DVBAPI 5.6
    Linux-3.5: DVBAPI 5.6 (Ubuntu 12.10 'Quantal Quetzal')
    Linux-3.4: DVBAPI 5.5
    Linux-3.3: DVBAPI 5.5
    Linux-3.2: DVBAPI 5.4 (Debian 7.0 'Wheezy') (Ubuntu LTS 12.04 'Precise Pangolin')
    Linux-3.1: DVBAPI 5.3
    Linux-3.0: DVBAPI 5.3 (Ubuntu 11.10 'Oneiric Ocelot')
    Linux-2.6.39: DVBAPI 5.2
    Linux-2.6.38: DVBAPI 5.2 (Ubuntu 11.04 'Natty Narwhal')
    Linux-2.6.37: DVBAPI 5.2
    Linux-2.6.36: DVBAPI 5.2
    Linux-2.6.35: DVBAPI 5.1 (Ubuntu 10.10 'Maverick Meerkat')
    Linux-2.6.34: DVBAPI 5.1
    Linux-2.6.33: DVBAPI 5.1
    Linux-2.6.32: DVBAPI 5.1 (Debian 6.0 'Squeeze') (Ubuntu LTS 10.04 'Lucid Lynx')
    Linux-2.6.31: DVBAPI 5.0 (Ubuntu 9.10 'Karmic Koala')
    Linux-2.6.30: DVBAPI 5.0
    Linux-2.6.29: DVBAPI 5.0
    Linux-2.6.28: DVBAPI 5.0 (Ubuntu 9.04 'Jaunty Jackalope')
    Linux-2.6.27: DVBAPI 3.2 (Ubuntu 8.10 'Intrepid Ibex')
    Linux-2.6.26: DVBAPI 3.2 (Debian 5.0 'Lenny')


    Auf der sicheren Seite mit DTV_STREAM_ID (ab API 5.8) ist man also erst mit Kernel 3.7, und vor Kernel 3.0 (API 5.3) funktioniert EPG definitiv nicht. Dazwischen bin ich mir auch nicht sicher, da sendet plain VDR 2.0.0 noch sein DTV_DVBT2_PLP_ID an DVB-S2, was zwar schon definiert, aber für DVB-S2 natürlich unsinnig ist.



    Eine Logmeldung baue ich mal in die nächste Version ein, bis dahin kann sich das jeder aber auch selbst einbauen, cDevice holt sich die Runtime-Version im Konstruktor und speichert sie in dvbApiVersion, da könnte man sie auch loggen.



    Gruß,


    Udo