Beiträge von geronimo

    habe mir gerade die 35er Quellen gezogen und den Ablauf überflogen.
    Ganz provokativ gesagt kann es, so wie es derzeit ist, nicht funktionieren ;)
    Jeder Receiver hat die Macht, den Vdr-Core völlig lahm zu legen.


    Falls ich die Quältexte richtig verstanden habe, ist nicht die Schleife in transfer.c das Problem, sondern die Schleife in device.c verbunden mit dem Umstand, dass alle Empfänger gleichberechtigt sind mit dem Vdr-Core


    Zeile 16 ist die Übergabe der Kontrolle an den Empfänger, ggf. eben an ein externes Plugin.
    Dadurch dass die Schleife für jeden Empfänger gesperrt wird, werden alle Ausgabeprobleme zu neuralgischen Problemen, die den ganzen VDR lahm legen.
    Der Umstand, dass Plugins sich als Empfänger anmelden können, vergrößert die Problematik noch - der VDR ist an dieser Stelle hochgradig verwundbar.


    Mein Gegenvorschlag sieht so aus, dass der VDR die Pakete nicht aktiv an die Empfänger verteilt, sondern die Pakete in einen Ringpuffer einträgt und den Empfängern nur mitteilt, dass es ein neues Paket gibt. Jeder Empfänger sollte in einem eigenen Fred laufen, sodass der VDR unabhängig davon ist, wie lange ein Empfänger braucht, um ein Paket abzuholen.
    Die Empfänger erhalten nur Lesezugriff auf den Ringpuffer und haben keine Möglichkeit, einen Lock zu erstellen.
    Den Ringpuffer könnte man so anlegen, dass jeder Empfänger seine eigenen Indizes verwaltet - so können langsame und schnelle Empfänger unabhängig voneinander agieren.
    Der VDR hält seine Indizes, die keiner einsehen oder verändern kann.
    Über Puffergröße und ggf. einer kleinen Pause könnte die Hauptschleife des VDR austariert werden.
    Bei einem "Überlauf" wird einfach ein altes Paket gegen ein neues ausgetauscht.
    Jeder Empfänger, der bis zu diesem Zeitpunkt das alte Paket nicht abgeholt hat, hat dann einfach Pech gehabt.
    Auf diese Weise wäre der VDR erstmal wieder autark und hätte die zeitliche Hoheit.


    Wenn in einem solchen System ein Empfänger rumzickt und Amok läuft, würde zwar die Systemlast als solche steigen, die Funktionalität des VDR wäre aber nicht beeinträchtigt.
    Auch in einem solchen System könnte der Quertreiber ohne Kollateralschäden abgeschossen werden.


    Gruß Gero

    Zitat

    Guten Morgen ;)


    Du hast aber schon gemerkt, das wir seit Hier --> Ist das die Zukunft von HD? über das Thema diskutieren


    Danke für die Beleerung.
    Deinen Beitrag hatte ich übergesehen :( Sorry!

    Moin moin,


    Zitat

    Da du Debian benutzt, ist das "ganz kompliziert":


    Wenn das so ist, dann bin ich dabei!
    Kann aber erst am WE.


    Ich habe den Fred nicht gestartet, um eine schnelle Lösung zu erhalten, sondern um die Diskussion um die Ursachen und deren mögliche Behebung in Gang zu bringen.


    Zitat

    Da hat das ja auch nichts verloren... :) Das muss ja das Ausgabe-Plugin entscheiden, ob es das braucht.


    Das sehe ich genauso.
    Wenn der Vdr den Prozess der Verarbeitung schon auf mehrere Schultern verteilt, sollte auch die Quelle des Ärgernisses den schwarzen Peter bekommen ;)


    Zitat

    Das hört sich gut an. "Leider" hab ich keine Probleme, aber vielleicht Lust, das zu schreiben. Hm, mal sehen


    Wenn Du magst, können wir uns am WE kurzschließen.
    Dann können wir - zumindest in der timerfreien Zeit - alles durchspielen, was Euch so einfällt ;)


    Gruß Gero

    Zitat

    Du brauchst ja auch nur eine Konstante (100) zu verändern.
    Stell dir halt einfach vor, es wäre Java, wenn dir das hilft die "Blockade" zu überwinden ;)


    Lach - ganz so blockiert bin ich nich ;)


    Die Blockade ist die, dass ich es (noch?) nicht geschafft habe, eine Entwicklungsumgebung aufzubauen (mit der ich zufrieden wäre), bzw. die gewesenen längst schon wieder entsorgt habe.
    Als ich den VDR verstehen wollte, habe ich mir alle Quellen in netbeans geladen und darin bearbeitet.
    Das Setup hat etwas gedauert, aber dann war's ok.
    Mein Fokus war die Handhabbarkeit der Quellen und Behebung von Übersetzungsfehlern. Laufenlassen des übersetzten vdrs war nicht vorgesehen.
    Ich hatte ja auch mal versucht, debian-konforme Pakete zu bauen - aber das ist enorm zeitaufwändig.


    Inzwischen ist viel Wasser den Rhein runter geflossen und derzeit habe ich nicht die Zeit, mir das nomml anzutun (die ruhigen Tage sind vorbei).


    Gruß Gero

    Zitat

    Davon hast du nicht viel:
    1. nur Filme von Sony-Pictures
    2. abspielbar nur unter von Sony vorgesehenen Betriebssystemen, linux wird wohl nicht dazu gehören
    3. abspielbar nur mit von Sony dafür vorgesehener Software (ob die wohl deine spezielle Mehrmonitorkonfiguration toleriert?)
    4. abspielbar voraussichtlich nur mit Onlineverbindung
    5. ich bin mir zu 100% sicher dass die Daten nur verschlüsselt und mit starkem DRM auf der Platte landen


    Ok, ich spür was Du meinst.


    Da bin ich völlig bei Dir - von den obigen Gängeleien halte ich auch nix.
    Aber ok, an der Ecke bin ich völlig gefühlskalt. Ich habe kein Problem, mir den einen oder anderen Cracker schmecken zu lassen, während ein Film auf Platte gespült wird ;)


    Damit sehe ich meine Aussage trotzdem noch nicht wiederlegt :O


    ... und zu Punkt 3:
    In Berlin gab es doch eine Uraufführung, die von Sony gesponsert wurde. Dort wurden mehrere Beamer zu einer Matrix kalibriert.
    Ich sehe darin keinen technischen Unterschied zu meinem Setup


    Zitat

    Wie schon geschrieben fände ich 1080p 50, 60 und (nach etwas überlegen wegen z.B. "Der Hobbit") zusätzlich auch 48 sinnvoller.


    Na, mir würden 1080p/60 schon reichen ;)
    Ich halte das immer noch für die sinnvollste Tacktung, schließlich hat sich an den 60Hz-Monitoren nix geändert.


    So ganz nebenbei finde ich die Entwicklung von 4k-Panels nicht nur fürs Wohnzimmer sinnvoll.
    Bislang habe ich nur bei Eizo Monitore mit Auflösungen jenseits der 2560 gefunden - aber dafür muss man schon einen guten Mittelklassewagen abgeben :O
    Am (Entwickler-)Arbeitsplatz einen 30" mit 4k Auflösung finde ich nicht verkehrt und wenn die lästigen Balken mitten im Bild wech sind, darf so ein Monitor auch etwas Meer kosten ...


    Gruß Gero

    Zitat

    Und ja - ich halte 4k für Blödsinn. Von 1080p 50 oder 60 hätte der Zuschauer mehr.


    und das sagt ein audiophiler, der am liebsten Musik in 192-Quali genießt?


    Ich kann nur sagen, 4k hat absoluten Suchtfaktor.


    Wenn ich neben meiner Röhre einen HD-Monitor gleicher Größe stelle und auf der Röhre eine DVD guter Qualität einlege und auf dem HD-Monitor den gleichen Film von BR abspiele, dann gibt es kaum Unterschiede. Um die zu finden, muss man schon auf Standbild schalten.
    Auch wenn die ganzen TV-Verkäufer was anderes behaupten.
    Deshalb bietet HD für mich keinen Anreiz, dort Geld auszugeben - nicht solange die Röhre noch funzt.


    Ganz anders mit 4k.
    Selbst mit meinen gedrehten Monitoren mit doppelten Balken mitten im Bild bietet skaliertes HD schon eine magische Anziehungskraft.
    ... und das, obwohl ich auch eher zu den audiovielen gehöre, denen Ton wichtiger ist, als das Bild.


    Ich weiß nicht, ob 4k-TV je kommen wird, aber 4k von BR steht ja schon in den Startlöchern.
    Wenn Sony jetzt verlangt, dass man den Film vorher auf Festplatte kopiert - dann kommt mir das eher entgegen, als das es ein Hindernis wäre.
    Also ich sehe 4k sehr positiv entgegen und freue mich schon auf die Umsetzung.


    Gruß Gero

    Zitat

    Zum Thema auf anderen Kanal umschalten: Es gibt im vdr die Option "letzter Kanal" oder "bestimmter Kanal". Da solltest du einen SD-Kanal einstellen, damit der vdr immer mit einem darstellbaren Kanal startet.


    Lach - auf die Möglichkeit bin ich auch gekommen.
    Das beseitigt das Problem zwar nicht, aber es verringert die Wahrscheinlichkeit.
    Also ok :)


    Zitat

    Geht es um deinen Backend- oder HD-vdr?
    Wenn es der Backend-vdr ist:


    Lach - ich hab's mehr mit Highlander: es kann nur einen geben ;)


    Will sagen - ich habe nur einen VDR.
    Der Rest sind Clients (xineliboutput), die sich mit dem Backend verbinden.


    Zitat

    Da hast du eine SD-FF für die Ausgabe, die nur mit MPEG2-Material umgehen kann. Die HD-Sender sind in h.264.


    Schon klar!
    Ich habe die Karte ja schon als Empfänger gesperrt, sie wird nur noch als SD-Ausgabe verwendet.
    Die Röhre ist ja schließlich auch SD - sollte also schon passen.


    Trotzdem ist das Problem bislang nicht gelöst, dass bei einer solchen Mischbestückung Aufnahmen getätigt werden sollen, die nicht angezeigt werden können.
    Ich bin der Ansicht, dass die Grundthese falsch ist.
    Wenn der VDR davon ausgeht, dass es immer live-TV gibt und Aufnahmen davon abgezweigt werden, dann muss es eine Lösung für den Fall geben, dass eben Sender aufgezeichnet werden sollen, die nicht angezeigt werden können (warum auch immer).


    Zitat

    Ein Ausgabedevice darf den Aufrufer im Live-Modus niemals unnötig blockieren.
    Es darf höchstens mal ganz kurz die Annahme verweigern, wenn sein Puffer gerade voll ist. Da die Daten in Echtzeit reinkommen und auch in Echtzeit wieder rausgehen (also dargestellt werden), kann der Puffer des Ausgabedevices nie dauerhaft volllaufen. Tut er es doch, dann hat das Ausgabedevice einen Fehler. Kann das Ausgabedevice die Daten nicht darstellen, dann soll es die Pakete, mit denen es nichts anfangen kann, verwerfen.


    Das deckt sich mit meiner Erwartungshaltung.
    Wobei ich "unnötig" streichen würde und die Verweigerung von Paketen finde ich unter keinen Umständen akzeptabel.


    Fakt ist nämlich bei der SD-FF, wenn die HD-Material vorgesetzt bekommt, dann landen die Frames nimmer in der Aufnahme.
    Wie ich eingangs schon schrieb, schafft es vielleicht ein Frame pro Minute auf Festplatte.
    Der VDR wird völlig blockiert von dem Puffer-Überlauf.


    Wobei ...
    ... die SD-FF zickt nicht nur bei HD-Aufnahmen rum.
    Bei manchen Sendungen von 3sat ist die Bitrate derart hoch, dass es die FF nimmer verkraftet.
    Dann geht sie in Zeitlupen-Anzeige über mit völlig abstrusen Nebeneffekten (Zeitlupenton, Bildaussetzer, etc).
    Klar, auch in so einem Falle sind die Aufnahmen dann Schrott.
    Ich habe aber keine Ahnung, ob das nur bei einer DVB-C SD-FF auftritt, oder ob das unter DVB-S ähnlich ist.


    Vielleicht müsste man die Prozess-Kette auch mal genauer unter die Lupe nehmen und gezielt fehlerhafte Situationen provozieren.


    Zitat

    Wie sieht es denn mit dvbsddevice bzw. dem Treiber aus? Was macht der, wenn er HD-Video bekommt?


    Ob es evtl. nötig ist, die API zu erweitern, so dass der vdr das Ausgabedevice fragen kann, ob es das momentane Format überhaupt wiedergeben kann?


    Hm, das Thema hatten wir schon mal im Zusammenhang mit der Kanalliste angeschnitten.
    Prinzipiell sind dort einige Konflikte vorstellbar.
    Ich denke, das wird nach 2.0 auch ne größere Baustelle ... ;)


    Zitat

    Aber das prüft geronimo ja hoffentlich mit der Schleife.


    Sorry, aber da muss ich Euch enttäuschen.
    Ich habe keinen selbstgebackenen VDR am Start.


    Als ich mich mit Streaming beschäftigt habe, habe ich die Quellen vom VDR auseinander genommen und versucht gelegentlich was zu verstehen.
    Ich habe ja auch mit einem Streaming-Server in C++ angefangen, aber nach kurzer Zeit habe ich für mich einfach festgelegt, dass mir C++ für meine Themen zu aufwändig ist und habe dann auch den Streamingserver in Java geschrieben. Seither habe ich auch keine Quellen mehr vom VDR angeschaut.
    Bin also nur noch Anwender.
    Das heißt nicht, dass ich nicht willig wäre, bei Bedarf mitzuhelfen, aber freiwillig tue ich mir C++ nimmer an.


    Gruß Gero

    Moin moin,


    das Thema ist eines meiner letzten großen Ärgernisse, die noch ungelöst sind im VDR.


    Zwischen den Jahren gab es bei mir eine leichte Häufung von Timern, sodass ich öfters den Effekt hatte, dass eine Aufnahme nur aus Fragmenten bestand, oder ganz fehl schlug. Leider funktioniert die Timer-Konflikt-Erkennung nicht, da entweder das Thema 2mal kodiert wurde, anstatt Code gemeinsam zu verwenden, oder aber die Konstellation in der Prognose nicht alle Faktoren berücksichtigt.


    Vor kurzem aber war ich völlig fassungslos, als bei einer Aufnahme nur Schrott rauskam, als nur ein Timer aktiv war, also der VDR alle Freiheiten der Welt gehabt hätte, eine saubere Aufnahme zu produzieren.


    Das Logfile gibt zu wenig her, als dass ich es irgendwie festklopfen könnte, deshalb schreibe ich einfach mal, was ich mir zusammenfantasiert habe:
    Wie jeder meiner Sig entnehmen kann, habe ich 2 Budgetkarten am Start, d.h. parallele Aufnahmen von Ard und 2df sind eigentlich™ kein Problem.
    Das Problem äußert sich immer so, dass folgende Tupels im Log Amok laufen:

    Code
    ... vdr: [10250] ERROR: TS packet not accepted in Transfer Mode
    ... vdr: [10251] ERROR: driver buffer overflow on device 2


    Wenn dies bei einer Aufnahme passiert, gelangt vielleicht ein Bild pro Minute auf Platte.
    Nach einer Weile löst der VDR dann den Neustart (emergency exit) aus.
    Im Log sieht man dann den Neustart, aber danach geht das gleiche Dilemma wieder von vorne los.
    Ich vermute mal, das es eine Konstellation gibt, in der der VDR z.B. von 2df aufgenommen hat und sich diesen Kanal als letzten aktiven merkt.
    Bei einem Neustart wird dann der Kanal eingeschaltet und das Drama fängt von vorne an.


    Wäre es nicht sinnvoller, an dieser Stelle zu versuchen, zu einem SD-Kanal aus dem gleichen Bouquet umzuschalten?
    Ist wahrscheinlich nur ein Problem der Kabelkunden mit SD-FF und nur solange bis HD bei allen Sendern im Kabel ankommt (falls es je dazu kommen sollte).
    Jedenfalls ist es bei mir so, wenn ein SD-Kanal (z.B. ein Sender der 3.Programme) aktiv ist, dann funktioniert die Aufnahme in HD ohne Probleme.
    Vielleicht gibt es ja auch noch eine elegantere Lösung?
    Vielleicht könnte man das Frontend als optional mit der geringsten Prio konfigurieren?


    Jedenfalls ist der "emergency exit" in seiner jetzigen Form völlig wertlos.


    Derzeit ist es wohl so, dass die Aufnahme als "Abfallprodukt" der Anzeige gesehen wird.
    Vielleicht wäre es an der Zeit, das umzustellen und festzulegen, dass die Aufnahme das vorrangige Ziel eines VDR ist. Eine mögliche Anzeige wäre dann ein Addon, welches auch in die Hose gehen kann "kein Kanal verfügbar" oder so.
    Vielleicht könnte man auch konfigurativ festlegen, wo die Prio liegen soll: Live-TV oder Aufnahmen.
    Seit ich einen lauffähgigen VDR habe, gibt es für mich kein Live-TV mehr.
    Am Erfolg des zeitversetzten Live-Signals konnte ich aber erkennen, dass ich mit meiner Einstellung wohl zu einer Minderheit gehöre.


    Gruß Gero

    Zitat

    Und den ersten Kunden, denen das auffällt, werden sich dann auch bei ARD/ZDF über die schlechte Bildqualität beschweren. Alle anderen Programme funktionieren ja einwandfrei...


    Ich denke, das wird niemand auffallen - außer vielleicht, dass ein paar Probleme wegfallen :O
    Derzeit ist es ja so, dass die Bitraten der ersten Reihe fast doppelt so hoch ist, wie bei den privaten und bei manchen SD-Sendern (z.B. 3sat) sind die Bitraten so hoch, dass eine SD-FF damit überfordert ist.


    Zitat

    die Kabelanbieter erzeugen die analogen Signale selber (aus den digitalen) und speisen die in ihr Netz ein.


    Manchmal kommen da recht seltsame Effekte zusammen.
    So habe ich schon mehrfach Sendungen bei arte entdeckt, die - trotz SD - aus progressivem Bildmaterial bestanden. Leider kann man nicht generell davon ausgehen, dass die Sendungen einfach nur runterskaliert werden.
    ... wobei ich mich schon frage, wie man interlaced aus progressivem Material herstellen kann.


    Gruß Gero

    Zitat

    Muss toll sein ne Firma mit Zwangskunden zu haben. Dann braucht man sich das rumgejammere der Kunden nicht anhören und kann das machen was das meiste Geld bringt


    Yo - und damit unterscheidet sich Kabel Deutschland grundlegend von den ÖR-Sendeanstalten :O

    Oh Mann!


    Du kommst mir vor, wie ein kleiner Junge, der aus "I Robot" kommt und sagt: ich will auch ein Auto das fliecht.


    Den Fred, aus dem Du Deine HW-Komponenten zusammen gesammelt hast, kannste völlig vergessen.
    Dort geht es um Anzeige und Darstellung.
    Transcodieren ist was völlich anneres.


    Hier ein paar Grundlagen, damit Du ein Gefühl für die Materie bekommst:
    Übertragungsraten
    CPU-Charts: http://www.tomshardware.de/cha…-2012/benchmarks,140.html - dort solltest Du Dir insbesondere den mit Handbrake anschauen.


    Als näxtes solltest Du Dir mal Deinen Vertrag mit den Telekomikern anschauen. Wenn Du dort bei upload-Rate schaust, steht da: bis zu xxx
    Dazu kommt, dass die Rate nur die Bruttorate im günstigsten Falle beträgt.
    Was Du an Netto-Mindestdurchsatz bekommst, ist was ganz anderes.


    Dann nimm einfach mal ein kurzes Filmchen und lass den von einem Deiner Rechner transcodieren.
    Übliche Tuhls wie ffmpeg geben die Wandlungsrate in Frames/s an - erst wenn Du über die 50 Frames/s kommst, kannst Du hoffen, dass es mit dem Streaming auch was wird.
    Mit der gemessenen Zeit, die die Umwandlung Deines Filmchens gedauert hat, gehst Du dann in die CPU-Charts und schaust, welche CPU der Deinen entspricht, bzw. gerade drüber ist.
    Aus der Zeit, die die Wandlung tatsächlich gedauert hat und der Filmlänge findest Du den Faktor, die die CPU schneller sein sollte.


    So aus dem Bauch heraus würde ich behaupten, dass zur Umwandlung eines Filmes keine bezahlbare Desktop-CPU ausreicht, d.h. Du bist bei Multicore-Opteron oder -Xeon Systemen. Das sind reine Serversysteme aus der Region scheißteuer™
    Weiß ja nicht, ob Dein Papa Dich mit einem Dukatenscheißer ausgestattet hat - ansonsten muss ne alte Oma lange für stricken ;)


    Gruß Gero

    Zitat

    Ich dachte anfangs einfach daran, dass man in upstart das Starten von X deaktiviert...


    Na ok - das sollte aber kein Problem darstellen. Oder?


    Zitat

    Maximieren des x-terms klappt auch nicht so richtig, zumindest wird in meiner Umgebung dann das Fenster größer als die VM ohne aber Scrollbalken anzubieten.


    Hm, also wenn der Windoof-Manager von Ubuntu nicht Schrott ist, dann sollte das - zumindest nach Installation der "Gasterweiterungen" klappen.
    Das Problem mit den Größen ohne Scrollbalken kam bei mir nur, wenn die Gasterweiterung nicht installiert ist.


    Ich könnte mir auch vorstellen, dass es Probleme macht, wenn man bei dem Bildspeicher der Grafikkarte für die VM zu knausrig ist ;)


    Über das Menü der VM kann das jeweils aktuelle CD-Image mit den Gasterweiterungen eingebunden werden. Danach muss man nur noch innerhalb der VM die Installation starten.
    Auf der CD gibt es diverse Installer für die Erweiterungen - ich hatte bislang noch keine Probleme damit.


    Zitat

    Ich konfiguriere die VM einfach als headless.


    Hm, was ist dann der Vorteil der VM?
    Ich denke mal, dass Ihr sowieso unter Ubuntu arbeiten werdet - oder täusche ich mir da?


    Gruß Gero

    Zitat

    Ich würde diese VM nun gerne etwas strippen, d.h. am liebsten einfach nach dem Start in einer Shell landen und nicht immer erst mühsehlig über Maus und Side-Bar ein x-Term starten.


    Das "strippen" hat mich erst auf die falsche Fährte gelockt. Nein - nicht wie Du denkst ;)
    Ich dachte zuerst, Du wolltest das Image der vm verkleinern.
    ... aber dann ging mir ne Glühbirne auf.


    Das was Du suchst ist keine Funktion von yavdr, sondern das bringt virtualbox von Haus aus mit.
    Nennt sich Schnappschuß, oder auch Sicherungspunkt.
    Du startest die VM und bereitest Dir da drin Deine Arbeitsumgebung vor. Wenn Du dann den Punkt erreicht hast, wie Du gerne normal anstarten willst, erstellst Du Dir einen Sicherungspunkt (aus dem Menü der VM).
    Aus dem VM-Manager kannst Du dann jederzeit so einen Sicherungspunkt aktivieren.


    Aber Vorsicht: ein Sicherungspunkt merkt sich auch den Zustand des Dateisystems, d.h. alles was danach erarbeitet wurde, geht verloren.
    Um das zu verhindern, kann man "gemeinsame Ordner" verwenden. So könntest Du die Quellen in einem Verzeichnis des Hosts lagern und in der VM einbinden.
    Diese Daten sollten dann vor einem Rollback der Maschine sicher sein.


    Das bedeutet aber auch, dass wenn Du was in der VM veränderst, was Du gerne behalten möchtest, dann musst Du Dir einen neuen Schnappschuß erstellen. (Der bisherige Startpunkt lässt sich mittels VM-Manager wieder löschen)


    hth Gero


    P.S. Bei KDE gehört sowas zur Grundausstattung ;)
    Im Startmenü unter Verlassen gibt es das Sitzungs-Menü.
    Wenn bei den Systemeinstellungen unter "Starten und Beenden" -> "Sitzungsverwaltung" -> "Bei der Anmeldung" "manuell gespeicherte Sitzung wiederherstellen" ausgewählt ist, gibt es im Sitzungs-Menü den Menü-Eintrag "Sitzung speichern".
    Eine so gespeicherte Sitzung wird direkt nach der Anmeldung wieder hergestellt, d.h. man startet jedesmal in der gleichen Umgebung ;)
    Eclipse und Firefox sträuben sich zwar gegen einen automatischen Start und kontact behauptet gelegentlich, bereits zu laufen - aber sonst ...

    Moin Moin


    Respekt Johns, Du bist mal wieder der Schnellste :)


    Zu den Use-Case Kommentaren folgendes:
    Meiner Ansicht nach gibt es 2 Use-cases für ein PIP

    • PIP-passiv: das was ich gerade schaue wird von Werbung oder anderem Schwachsinn unterbrochen. Dann soll die aktuelle Bildausgabe verkleinert und irgendwo hinbepackt werden und ich zappe im Vordergrund Bild und Ton. Wird PIP geschlossen, bedeutet das, dass der Sender des kleinen Bildes wieder zum Vollbild wird.
    • PIP-aktiv: ich schaue was, was nicht 100% prickelnd ist, und bin wunderfitzig, was auf anderen Kanälen so los ist. Dann bleibt der aktuelle Sender das Vollformat-Bild, genau wie auch der Ton weiterhin vom aktuellen Sender kommt. Im PIP zappe ich durch die Kanäle. Ein Schließen des PIP bedeutet lediglich, dass das kleine Fenster geschlossen wird. Der Sender im großen Bild bleibt aktiv.

    Da ich der Meinung bin, dass alle Ausgaben vom Skin beeinflussbar sein sollten, geht die Konfiguration von PIP-Position und Größe auch über ein Skin. Ob das Skin dem Anwender erlaubt, Größe und Position zu verändern, sehe ich im Verantwortungsbereich des Skins und nicht des PIP-Plugins. Denkbar wäre eine Analogie zur OSD-Größe. Das Skin könnte ja einen Rahmen um das PIP pinseln wollen - demzufolge muss es Größe und Position kennen, bzw. bestimmen können.
    Last not least - ist es ja auch das Problem des Skins, das OSD entsprechend anzupassen, wenn ein PIP aktiv ist.


    Das PIP-Plugin könnte beide Use-cases mit unterschiedlichen Hotkeys/Menükeys unterstützen. Dazu könnte "PIP aktiv" bedeuten, dass sich ein Kanalwechsel auf das kleine Bild bezieht, "PIP passiv" entsprechend dass sich ein Kanalwechsel auf das große Bild bezieht. So müssten keine Verrenkungen für den Kanalwechsel gemacht werden.
    Der Ton wird immer vom großen Bild bezogen.
    Das wäre dann auch für die Anwender intuitiv und nachvollziehbar.
    Ewentül könnte man noch eine Power-User-Umschalt-Funktion vorsehen, die zwischen aktiv und passiv umschaltet.


    Gruß Gero

    Zitat von Django

    Das macht mich ja doch mal neugierig, das mal (wieder) auszuprobieren.


    Als BOfH kennst Du Dich mit dem System wahrscheinlich besser aus als ich.


    Versteh es deshalb bitte eher als Erfahrungsbericht, denn als Radschlag.
    Ich muss gestehen, dass die meisten Linux-Probleme die Ursache in meiner eigenen Unzulänglichkeit fanden.


    Im Laufe der Jahre haben sich bei mir einige Regeln etabliert, mit denen ich ganz gut fahre:

    • nur unterhalb von /home sind Nutzeränderungen erlaubt/akzeptabel
    • selbst übersetzte Anwendungen werden in /usr/local/src/<program> gebaut
    • --prefix=/usr ist absolut tabu!
      Der (Debian-)Default von /usr/local sollte immer verwendet werden.
    • zumindest Debian ist so angelegt, dass alles unter /usr/local vorrangig verwendet wird, d.h. man braucht sich weder um Include- oder Lib-Pfade noch um Ausführungspfade zu kümmern
    • Anwendungen, die sich nicht um FHS scheren werden grundsätzlich unter /opt installiert. Ich habe mir z.B. ein /opt/java angelegt und darunter werden die jdks installiert, die ich direkt von oracle sauge. Damit das funktioniert, wird unter /etc/profile.d eine Datei jdk_oracle erzeugt, in der die Environment-Variablen angepasst werden.

    Bei Nicht-Produktions-Systemen habe ich mir angewöhnt, /usr/local als eigene Partition einzubinden. So kann ich jederzeit die selbst-übersetzten Anwendungen deaktivieren und die Systemstabilität/-integrität kontrollieren.


    Bei servern ist es ja oft so, dass man ein Raid aufsetzt, dort aber Verzeichnisse ablegen möchte, ohne das Raid deshalb oberhalb dieser Verzeichnisse einzubinden.
    Ich habe mir angewöhnt, auf dem Raid Verzeichnisse mit führendem Punkt dafür anzulegen und diese dann entweder per "mount -o bind" oder per Softlink an den gewünschten Ort zu projezieren. So behält man Ordnung im System und nebenbei erleichtert es auch das Backup ;)


    Bei Produktiv-Systemen partitioniere ich so, dass das System auf einer Partition kleiner 10 Tb - äh meine natürlich Gigabeit - landet.
    Das Log-Verzeichnis wird auf eine andere Partition geleitet. Dies macht besonders bei einem VDR mit SD-FF Sinn, da hier die Logeinträge mit "Puffer-Überlauf" oder "Paket nicht erlaubt im Transfermodus" regelrecht Amok laufen können.
    Interessant für einen VDR dürfte auch ein Root-FS im RO-Modus sein.


    Entwicklungs-Systeme partitioniere ich so, dass zuerst eine kleine Partition ( < 2 Gig ) mit ext2 für /boot erstellt wird.
    Dann folgen 2-3 Partitionen mit 10 Gig und dann der Rest.
    /boot ist die Partition mit dem boot-Flag und Grub kommt in den MBR.
    So funktioniert Multiboot auch wenn die Root auf einem Raid liegt.


    Im Heimatverzeichnis der Anwender mounte ich u.a. ~/Documents und ~/Downloads auf das Raid. So können bei Multiboot-Systemen unterschiedliche Systeme auch unterschiedliche Desktops haben (Konfigurationsdaten sind unterschiedlich) und die eigentlichen Anwenderdaten sind konsistent (jedes System hat seinen eigenen /home Baum).


    Seit wheezy hat Debian auf multiarsch-Betrieb umgestellt, d.h. man darf jetzt 2 Stühle vor einem Bildschirm benutzen ;)
    Kwatsch beiseite: konkret bedeutet das, dass 32Bit-Anwendungen unter 64bit-Systemen nicht mehr aufgeführt werden.
    Um solchen Anwendungen verwenden zu können, muss die andere Architektur erstmal freigeschalten werden:

    Code
    dpkg --add-architecture i386

    Nach einem "apt-get update" stehen die 32bit Anwendungen im Anwendungskatalog wieder zur Verfügung.
    Bei manchen Anwendungen kann es passieren, dass die Abhängigkeiten nicht sauber gepflegt sind und beim Start die Fehlermeldung kommt, dass libXYZ nicht gefunden wurde.
    Wenn man nachschaut, ist die libXYZ sehr wohl vorhanden - aber eben nur als 64bit Variante.
    Dann muss man die 32bit Version nach installieren mit "apt-get install libXYZ:i386".
    Vergisst man beispielsweise die Freischaltung der fremden Architektur, kommt hier die Fehlermeldung, dass die libXYZ nicht installierbar ist.


    Bei Debian lernt man die Konsole wieder neu schätzen.
    Um Tipp-Arbeit einzusparen, gibt es bei mir (in .bashrc) folgende Alias-Definitionen:

    • ac wird verwendet, um nach einem installierbaren Paket zu suchen
    • ai wird verwendet um ein solches Paket zu installieren
    • ii dient der Recherche, um rauszufinden, welche Paket-Version gerade installiert ist
    • mit dist-upgrade wird das System aktuell gehalten. Wenn man das annähernd täglich ausführt, dann kommt es auch nicht zu stundenlangen Update-Orgien.


    Soviel mal für's Erste. Wünsche viel Erfolg und Freude beim neu ausprobieren ;)


    Gruß Gero

    Hi Django,


    wenn Dein neuer VDR auch wieder 10 Jahre halten soll, dann hätte ich noch ein paar denkenswerte Punkte:


    auch wenn ich nicht glaube, dass die ÖR sich irgendwie um Content bemühen (es sei denn, die Klage gegen die Kopfpauschalgebühr hätte Erfolg), oder dass die TV-Anstalten die HD-Auflösung steigern werden, könnte es ja doch sein, dass Deine 4 Leitungen knapp werden.
    Dann gibt es immer noch die Variante Unicable oder so.


    Dann gibt es meiner Ansicht nach 2 Extrem-Positionen beim HD Setup:

    • Du spielst die Aufnahmen so ab, wie sie aufgenommen wurden. Evtl. Skalierung erledigt der Client.
      In einem solchen Setup genügt ein NAS als Backend und moderate Rechner als Clients.
      Audio-Wandlung on the fly von DD nach Sterero oder so sollte der Client auch mit einem Lächeln nebenbei erledigen können.
    • Du willst Support für Mäusekino und Hosentaschenrechner (Seagate Goflex, Himbeere und andere Obstsorten), dann sollte der Server etwas potenter sein.
      Wenn für das Streaming nur Audio konvertiert werden muss, reicht natürlich ein i3-3220T - wenn dagegen auch Video umgerechnet werden soll, dann darf es durchaus auch ein i7-3770K oder ein Multi-CPU-Xeon sein ;)

    Wenn man sich beide Varianten vom Preis-/Leistungsfaktor betrachtet, dann wiegt die mögliche Einsparung beim Client nicht die Meerkosten am Backend auf. Insbesondere wenn Videokonvertierung notwendig werden sollte. Muss ich erwähnen, dass ich die erste Variante bevorzuge?


    Auch wenn die Gefahr einer Auflösungsvergrößerung bei den TV-Anstalten in den näxten 10 Jahren unwahrscheinlich erscheint - auf BR ist die Steigerung der Auflösung bereits angekommen.
    ... und der Suchtfaktor von 4k ist ein vielfaches gegenüber dem von Full-HD :)
    (so ganz subjektiv!)


    Das führt zu der Empfehlung, bei Graka und CPU lieber eine Nummer größer zu gehen.
    Ich gehe jetzt einfach mal davon aus, dass Du Deinen HD-VDR 2geteilt aufbauen wirst (also Backend im Keller, Client im Saloon) ...
    Bei Variante 1 könntest Du den Server im Keller lassen, wie er ist und Du gönnst Dir einen neuen Client im Livingroom (oder zumindest in der Nähe ;) )
    Als CPU würde ich Dir für den Client eine I3-3220T und bei der Graka eher eine GT 640 oder größer empfehlen.
    Auch wenn es geringfügig mehr kostet, als die Minimal-Konfiguration - denke ich, dass es langfristig die bessere Wahl ist.
    Zumindest fürs Wohnzimmer, wo der Chef de maison bestimmt, wie der Haussegen hängt.
    (Der Unterschied zwischen einer Sandy im i3 und einem Ivy beträgt gerademal 5 Öre - also vernachlässigbar. Dafür ist Ivy schneller und sparsamer.)


    Gruß Gero