Posts by Cybso

    Kurzum: Wenn ich`s drauf hätte, würd` ich es selber schreiben. Aber wäre natürlich klasse, wenn sich Cybso drüber hermachen würde.


    Ich bin nicht tot. Allerdings sehe ich derzeit auch nicht, wann ich mich mal länger als ein bis zwei einzelne Tage daran setzen kann - und dann geht die meiste Zeit für die Wiedereinarbeitung drauf. Falls sich hier noch ein C++-Programmierer dafür interessiert, könnten wir allerdings mal versuchen, Ideen und Aufgaben aufzuteilen.

    Ja, aber Job- und Familienbedingt leider nicht mit so großer Effizienz wie ich mir gehofft hatte. Die letzten 5 Wochenenden, die ich mir dafür vorgenommen habe, sind allesamt ins Wasser gefallen.

    Ich habe den Befehl an zwei Stellen integriert. Zuerst für einen regulären Startup in der /etc/network/interfaces nach dem Aktivieren des Netzwerkinterface:


    Code
    1. auto eth0
    2. iface eth0 inet dhcp
    3. post-up /usr/sbin/etherwake 00:1F:D0:59:39:DD


    Damit der Server auch geweckt wird, wenn der Client aus dem Schlafzustand aufwacht:


    /etc/pm/sleep.d/40_etherwake:


    Mit chmod 0755 ausführbar machen.

    Wie ist dann "Jederzeit vor- und zurückspulen können" gemeint? Ergibt sich das nicht eh automatisch durchs Vorhandensein eines Livebuffers?


    Damit meinte ich, dass man den Buffer nicht (wie bisher) explizit Starten muss. Ich formiliere die Antworten etwas genauer.


    Warum kann man nur zwei Optionen auswählen?


    Damit am Ende nicht sowas wie "100%, 100%, 100%, 95%, 100%" herauskommt. ich will wissen, welche Funktionen wirklich wichtig sind.

    Mist, jetzt habe ich doch eine Antwort vergessen gehabt, die ich noch einbauen wollte: "Expliziter Wechsel in einen gesonderten "Replaymodus" (wie bisher)" als Gegenstück zu "Kein Wechsel in den Replaymodus". Es gab ja glaubich einige, die das explizit so haben wollten. Hab sie noch schnell ergänzt, auch wenn es schon einige Teilnahmen gab. Man kann seine Wahl ja auch noch ändern...

    In http://www.vdr-portal.de/board…konzert-livebuffer-plugin wird seit inzwischen 12 Seiten über Pro und Contra "Livebuffer"-Patch diskutiert. Dabei hat sich gezeigt, dass die Vorstellung darüber, was so ein Modul überhaupt zu leisten imstande sein soll, stark divergieren. Da ich selbst von der vorhandenen Umsetzen nicht so begeistert bin, habe ich angefangen, mich in den VDR-Quelltext einzuarbeiten um ggf. selbst einen entsprechenden Patch zu schreiben.


    Mit dieser Umfrage soll sich herauskristallisieren, welche Funktionen für die Akzeptanz eines neuen Livebuffers wirklich wichtig sind. Aus diesem Grund ist die maximale Anzahl der Antworten auf zwei begrenzt - eine eierlegende Wollmilchsau hätte wohl jeder gerne ;-) Die Umfrage ist unverbindlich in dem Sinne, dass möglicherweise nicht jede Funktion auch tatsächlich sinnvoll umgesetzt werden kann.

    Vielleicht möchte sich KLS dazu äußern, ob es von Ihm eine mögliche "Schnittstelle" geben könnte, wodurch es doch als Plugin realisierbar wäre. Denn wie man hier im Thread gesehen hat schlagen die Wellen bei der "will ich nicht haben" Fraktion recht hoch, deshalb der Plugin Ansatz.


    Wenn ich den Proof-of-Concept fertig habe, dann kann ich vielleicht besser einschätzen, ob eine Pluginschnittstelle sinnvoll wäre und wie die Aussehen müsste. In jedem Fall müsste sie aber wohl mehrere Interfaces beinhalten, die speziell für dieses Problem sind, so dass ich weiterhin einen (sauberen) Patch für eine bessere Möglichkeit halte. Eine Möglichkeit, das von Kern zu trennen und dennoch zu verhindern, dass der Patch jede Version angepasst werden müsste, wäre vielleicht ein CPP-Makro an den entsprechenden Stellen, hinter denen sich dann in der gepatchten Version die entsprechende Funktionalität verbirgt. Oder einfach leere Methodenrümpfe, die der Compiler dann wegoptimieren würde, wenn der Patch nicht drin ist. Aber wie gesagt, alles der Reihe nach!


    Die Umfrage habe ich nicht eingebunden, weil ich nach den letzten Reaktionen nicht sicher war, ob ein Konsens über die Fragestellung vorhanden ist. Wenn du meinst, das passt so (und niemand spontan noch "stop!" schreit) mache ich sie heute abend fertig...

    Die Integration in den bestehenden Live Stream ohne den VDR Core anzutasten scheint ja die Herausforderung zu sein, denn nur so kann sichergestellt sein, dass man ohne dem Plugin wieder einen plain vdr hat und somit auch die "Gegner" dieser Funktion zufrieden sind.
    So wie ich das verstanden ist es nicht ganz klar, ob es überhaupt eine nutzbare Schnittstelle ohne patchen gibt um den Stream dafür abzugreifen und weiterzubearbeiten, unabhängig vom verwendeten Ausgabedevice.


    Nach allem was ich bisher gesehen habe geht es nicht, ohne den Core zu verändern (also: Patch), erst recht nicht wenn man wie hier gewünscht so Späßchen machen will wie den Buffer auch für Aufnahmen nutzen oder gar bei einer FF-Karte live umschalten will (da ich nur Budgetkarten habe werde ich das eh nicht machen können). Ich habe aber gesehen, was der alte Patch mit dem Core angestellt habe, und versuche auf jeden Fall geschickter und mit weniger Änderungen am Core hinzukriegen.


    Doch wie schon angedeutet, Familie und Arbeit gehen vor, daher erwartet nicht kurzfristig produktive Ergebnisse. Aber da ich das Dinge ja selbst haben will... ;)

    Du kannst ja mal versuchen auf einem System mit 300 MHz Pentium 2 XBMC laufen zu lassen, dann erhältst du einen ersten Eindruck.


    Allerings ein 300 MHz Pentium 2 mit OpenGL ES und H.264-Hardwaredecoder. Die reine GUI eines XBMC zu rendern sollte möglich sein, wenn auch vielleicht mit weniger Eye-Candy. Schwierig dürfte es werden, Videos in anderen Codecs als X.264 abzuspielen, und genau darauf spielte die Frage wohl an (SDTV = MPEG1/2).

    Kurzer Zwischenstand: Ich habe den VDR mit xineliboutput-Plugin und DVB-T-Stick nun in der Entwicklungsumgebung ans Laufen gebracht. Als nächstes versuche ich nun, den Datenfluss herauszufinden. Sagte ich schon, dass es schön wäre, wenn sich ein Entwickler, der den Code schon so einigermaßen kennt, für Fragen zur Verfügung stellen würde ;-)?

    Ich dachte das sind Engländer?


    Stimmt, habe mich vom $ irritieren lassen.


    Innerhalb der EU gilt die Mehrwertsteuer im Land des Verkäufers, das sollte man sogar einheitlich angeben können (obwohl ich irgendwie eine Info im Hinterkopf habe, dass man optional auch die Steuer wiederkriegen und statt dessen im eigenen Land abführen kann, aber da mag ich jetzt auch was durcheinander bringen).


    Beim internationalen Versand, und darauf zielt der $-Preis wohl ab, gibt es aber zumindest in Deutschland je nach Empfängerland unterschiedliche Regelungen. Beim Versand in die USA muss die Steuer zum Beispiel wieder vom Empfänger abgeführt werden. Daher würde die Angabe $-Preis + Mehrwertsteuer überhaupt keinen Sinn machen. £ + britische MwSt. schon eher. Immer vorausgesetzt, dass das Ding auch von UK aus verkauft wird.

    Ich habe bei der Erstellung der Files XBMC über das VDR-Menü gestartet und dann die Maschine über die Secureshell per "halt" runter gefahren.


    Ich meine eigentlich, dass du sie so herunterfahren sollst, dass das Problem dabei auftritt. Dem Logfile nach wurde die Maschine komplett heruntergefahren.


    Falls du das ganze aber so meintest, dass auch bei einem Shutdown via "halt" das Problem auftritt, dann hat es offenbar nichts mit yaVDR zu tun. Dann scheint es ein Problem vom darunterliegenden Ubuntu-System oder dem Kernel zu sein. Das wäre dann ein recht weites Feld, spezielle Kernelparameter beim Booten könnten helfen. Oder testweise selbst einen aktuellen Vanillakernel zu kompilieren. In den Ubuntuforen und -wikis findest du Material dazu (Stichwort "eigenen Kernel kompilieren"). Mach dir wegen der 3.x-Version keine Gedanken, nach meinen bisherigen Erfahrungen funktioniert das System auch damit - ich betreibe selbst ein yaVDR mit Kernel 3.2, da erst dort einige Treiber, die ich benötige, vorhanden sind.


    Ähm, aber auch wenn nicht viel passieren dürfte, sichere bitte deine Daten vor Experimenten mit eigenen Kernel, falls du nicht genau weißt, was du da tust.

    Ja, das habe ich gemacht! ...gestern habe ich dann zufällig mal ein bisschen länger gewartet (ca. 15 Min.???) und dann fuhr das System 'runter. ...ließ sich danach aber nur wieder einschalten, nachdem ich am Netzteil!! den Powerschalter aus- und wieder eingeschaltet habe. ...nicht, dass ich hier noch ein ganz anderes Problem habe.


    Ich bin mir ziemlich sicher, dass es sich dabei um ein anderes Problem handelt. Wenn der Shutdown ausgelöst wurde, dann würde der init-Prozess irgendwann ein KILL und schließlich ein TERM-Signal an Prozesse senden, die nicht beendet wurde. Da in Bezug auf das alte Problem der XBMC sich jedoch durch ein normales kill beenden ließ, dürfte dies den Shutdow nicht aufhalten.


    Ein paar Informationen aus dem Syslog wären vielleicht hilfreich. Mach mal folgendes:


    1. Lass den PC ein paar Minuten aus, um die Zeitstempel klarer voneinander abgrenzen zu können. Merk dir die Uhrzeit.
    2. Fahr den PC hoch und lasse ihn anschließend wie gewohnt herunterfahren
    3. Lass den PC noch ein paar Minuten aus, siehe 1. Merk dir die Uhrzeit.
    4. Starte den PC und logge dich ein. Kopiere dir die Datei /var/log/syslog (in der Regel nur von root lesbar, aber mit "sudo chmod 755 /var/log/syslog" kannst du das ändern) [Edit: Ich bin gerade nicht im Heimnetzwerk und kann deswegen nicht nachschauen, aber ich glaube das Syslog steht auch über das yaVDR-Webinterface zur Verfügung]
    5. Such in dieser Datei anhand der Zeitstempel den kompletten Part zwischen 1 und 3 heraus.


    Lade diesen Teil am besten bei pastebin hoch und stell den Link hier rein.


    Die Datei sollte eigentlich keine persönlichen Daten enthalten, trotzdem wäre es natürlich gut, wenn du vorher nochmal drüber schaust ;)

    Und da fangen die Probleme in etwa an: Bei einer FF-Karte oder einer FFHD-Karte kommen die Daten gar nicht bis in den PC. Die Karte selbst transportiert die Daten vom Empfänger zum Ausgabedevice. Das hat den Vorteil, dass jegliche Verzögerung beim Umschalten vermieden wird, da die Daten nicht 2x über den Bus müssen, und auch das Puffern im VDR entfällt.
    Bei anderen Ausgabedevices kommt das transfer control (transfer.c) zum Einsatz, um die Daten vom Empfänger zum Ausgabedevice zu transportieren.


    Danke für den Hinweis, solche Dinge sind exakt der Grund, weswegen ich mir wünsche, jemand möge mir den Datenfluss des Streams im Programm skizzieren :)

    Um die schnelle und schlanke Direktverbindung bei FF-Karten zu erhalten, müsste ein livebuffer zunächst nur im Hintergrund aufzeichnen, und erst bei Pause oder Rückspulen in den gepufferten Modus wechseln. Vergleichbar mit dem bisherigen Pause-Modus, nur dass halt nicht bei 0 angefangen wird, sondern in die buffer-Aufzeichnung gesprungen wird


    Das wäre in diesem Fall die sinnvollste Methode, ich würde nur in jedem Fall gerne vermeiden in einem - aus Benutzersicht - gesonderten Replay-Modus zu gelangen. Im reinen Softwaremodus dürfte das auf jeden Fall klappen, aber wie sieht das bei den FF-Karten aus? Kann man überhaupt ohne Verzögerung umswitchen? Mangels FF-Karte würde ich einen Patch auf jedenfall zunächst für den reinen Softwaremodus entwickeln, aber so kann ich das zumindest im Auge behalten.

    Ich glaube wir reden eigentlich wirklich von der selben Sache und haben nur minimal unterschiedliche Vorstellungen über die Details.


    Ich bin gerade dabei mir eine Entwicklungsumgebung für den VDR zusammen zu basteln. Wenn ich es hinkriege das Ding zu kompilieren und zu betreiben (besondere Schwierigkeit: mein Laptop hat keine DVB-Karte, ich muss also über Streamdev gehen oder mal schauen dass ich mir nen DVB-T-Adapter besorge) schauen wir mal weiter. Aber nur Vorsorglich, versprechen tu ich nichts, und je nachdem wie sich meine Zeit und Motivation entwickelt könnte es sein, dass ein eventueller Proof-of-Concept-Patch von jemand anderem weiterentwickelt werden müsste.