Nach ein paar Tagen folgendes Ergebnis: [...]
Deckt sich mit meiner Erinnerung. In der Anfangszeit von HD in Deutschland war es deutlich mehr, weil ARD und ZDF jeweils einen festen Teil der Bandbreite genutzt haben. Nachdem die getrennte Wege gegangen sind, haben sie die Bandbreite dynamischer aufgeteilt, danach war spürbar weniger Füllmaterial im Stream.
* schleicht durch die alte Nachbarschaft
Jo, der Patch für vdr-2.1.5 funktioniert immer noch, hab ihn selbst vor 2 Monaten in einen aktuellen VDR eincompiliert, läuft seit dem unauffällig. Hab aber nicht genau geschaut, ob er auch was filtert.
Der Patch greift ziemlich tief in den Stream ein und schreibt ihn on-the-fly um, von daher verstehe ich, dass er nie fest eingebaut wurde. Trotzdem schön, dass er nach 6 Jahren noch immer nicht in Vergessenheit geraten ist. 
Na dann will ich doch auch mal vorübergehend von den Toten auferstehen... Dabei seit mindestens 16 Jahren, wenn nicht länger, aber auch schon seit rund 6 Jahren weitgehend inaktiv gewesen. Wenn der VDR halt läuft und läuft und läuft und läuft....
Irgendwann hatten sich halt andere Themen dazwischen gedrängelt, und Zeit kann man halt leider immer nur ein mal verbrennen.
Aber immerhin: Aktuell saniere ich gerade meinen alten, nicht tot zu kriegenden handgepflegten VDR, nachdem er jetzt 4 Jahre schlicht gar keine Updates gesehen hat. Vielleicht belebe ich auch meine Plugins von damals wieder.
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
Ich meine mich dumpf an irgendwas überdachendes auf der Terasse zu erinnern. Notfalls gilt wie immer: Nur der, der am Grill steht, wird nass.
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.
Hab mir Zeit und Ort auch erst mal vermerkt, hoffe das klappt.
