Posts by hivdr

    Also ich habe dann tatsächlich mal etwas gebastelt..


    Der Parameter pos erlaubt: resume | mark.# | time.# (Sekunden) | frame.# | # (<100 -> Prozent, sonst Byte-Index)
    (offen bleibt also individuelles resume.#)


    Per default wird das File "abgeschnitten", innerhalb dieses Bereichs wird dann auch korrekt navigiert (wenns der Client denn beherrscht).
    Ausserdem kann man dem ganzen noch ein Präfix "full_" voranstellen (bessere Bezeichnung ist mir nicht eingefallen), bei dem dann doch mit der Gesamtlänge bzgl. range gearbeitet wird (wie man einen config-Schalter einbaut, weiss ich nicht, ausserdem erscheint es mir Stream-spezifisch in der URL flexibler). Hier freut mich zwar, wenn Du die Idee "genial" nennst, nur wie gut es funktioniert ist etwas zweifelhaft. Mal klappt es problemlos, dann gar nicht: der vlc zeigt nur "Müll".. und das obwohl ja die gleichen Daten geschickt werden, lediglich der gemeldete range-Bereich ist anders (umfassender). Es scheint mir auch vom Material abzuhängen, aber auch bei ein und derselben Aufnahme und den gleichen Stellen hat es mal geklappt und mal nicht (Restart vlc egal). Manchmal fordert der vlc dann auch die letzten 128 Byte an - und hängt (also kein Absturz, nur die Wiedergabe). Sehr seltsam.


    Den HEAD-Teil habe ich nicht berücksichtigt, mir ist nie ein HEAD-Request untergekommen.
    Die Berechnung des Frame aus der Zeit (wie in marks oder eben selbst angegebene Sekunden) geht einfach von 25fps aus.
    Theoretisch könnte man bei den Frames noch immer zum nächsten oder vorherigen I-Frame springen - aber ich hatte (ohne full_) keinerlei Probleme mit beliebigen Stellen, auch mitten-im-Frame (byte- oder Prozent-Index).


    Bei mir klappt es also soweit. Es ist aber natürlich weit weg davon, absolut gründlichst durchgetestet zu sein. Da ich es im Moment selbst noch gar nicht benutzen kann wie beabsichtigt (mein Haupt-VDR ist zu alt für das neue Plugin), kann es auch noch etwas dauern, bis es zu ggf. nötigem Feintuning kommt. Aber falls mir selbst noch ein grösseres Problem auffällt, werde ich es hier nachtragen.


    schmirl - würde mich freuen, wenn Du es übernimmst bzw. Dich inspirieren lässt.
    Etwas Qualitätskontrolle schadet definitiv nicht (hatte seit Ewigkeiten nichts mehr mit C/C++ am Hut, und von VDR-Programmierung verstehe ich schon gar nichts).


    Diff gegen das aktuelle Repository (bzw. vom 30.8. - wenn das noch aktuell ist..):
    (diff ist auch nicht so mein Metier, ich hoffe das ist so für "patch" brauchbar)



    Viel Spass, wenns wer brauchen kann freue mich über Rückmeldungen.

    Ich habe noch etwas experimentiert mit den Headern. Weder das Hinzufügen des "fehlenden" Server-Headers, noch ein anderer content-type (mp4) oder Änderungen bei den Cache-Headern haben etwas bewirkt.
    Ich denke also an den Headern liegts nicht.


    Es muss am Inhalt liegen. Und tatsächlich: stelle ich eine VDR .ts Datei via Apache bereit, so kann der Andro-VLC auch darin nicht springen. Da ist wohl einfach die Android-Version noch nicht weit genug.


    Solange also der VLC-Port nicht entsprechend weiterentwickelt wurde, bleibt nur, die Daten serverseitig zu steuern.


    Anhand der Infos hier, http://www.vdr-wiki.de/wiki/index.php/Index (resume enthält offenbar eine frame-number) und der im recplayer schon enthaltenen Funktion positionFromFrameNumber() werde ich hoffentlich demnächst die Zeit finden, das mal testweise einzubauen, etwa via Parameter &resume=1.


    externremux hin zu einem besser verträglichen Format würde dann vermutlich auch helfen, was ja auf Deiner Agenda steht. Aber ich selbst habe nicht vor, nur deshalb mit hohem Rechenaufwand / Energiebedarf das Material generell durch den converter zu jagen..


    Nachtrag thlo : ich vermute das smarttvweb plugin macht dann eben auch irgendeine Konvertierung der Daten hin zu einem Format, mit dem zumindest der MX-Player dann besser umgehen kann. Ist ja interessant was es alles gibt. Samsung TV hätt ich auch, aber noch D-Serie. Und von dem proprietären Schmarrn will ich ja mit dieser Sache grade weg - Samsung smartview ist eigentlich eine nette Sache, aber nervt durch soviele indiskutable Schweinereien: nicht nur beschränkt auf Samsung-TV, auch die App läuft nur auf Samsung-Geräten, und selbst da oft genug nicht, spätestens nach dem nächsten Android-Update.. dazu nutzt es irgendwelches UPnP-Gedöns, das man nicht mal eben durch einen Router durchbekommt. Sauberes Streaming auf einem einzelnen Port, so muss das..

    Danke für die Rückmeldung schmirl !


    Das scheint ja im Moment nicht gerade ein Trend-Thema zu sein..


    Zeit habe ich leider auch nicht wirklich viel (eigentlich keine..), trotzdem hatte ich mich jetzt zuletzt sogar ein bisschen mit dem Source auseinandergesetzt - und eben auch gesehen, dass da ganz normale HTTP Range Requests zum Einsatz kommen. Habe dann auch mal zum Probieren (nix sauberes was man "veröffentlichen" oder zum Patchen einreichen möchte) einen Parameter &offset=xy eingebaut, der als Prozent der Laufzeit interpretiert wird, wo gestartet wird (wenn range.from == 0). Das hat mit dem Desktop-VLC direkt funktioniert, er hat dann auch gleich die Fortschritts-Anzeige entsprechend gezeigt. Der Android-VLC dagegen kam damit nur klar, wenn man generell keine Range-response sendet, sondern eine normale 200er mit eben den Daten mit offset xy%.


    Auch das mit dem Sniffen hatte ich mir schon vorgenommen und nun mal eben gemacht. Leider ohne grosse Erkenntnis.


    Auch der Android-VLC sendet initial einen Range-Request 0-. In einer per Apache bereitgestellten .mp4 Datei konnte auch ohne weiteres navigiert werden:



    Ein Sprung führte zu:



    Nun das ganze gegen den VDR / streamdev-server (wieder zurückgerollt auf aktuellen Original-Stand!):



    Ich erkenne keinen wesentlichen Unterschied in der Response bzgl. ranges. Trotzdem reagiert der Android-VLC hier so, dass er einfach kein Spulen/Springen anbietet!
    (und wie oben gesagt, wenn man ihm einen range-Response von "mittendrin" gleich auf den 0- request untergeschoben hat, konnte er damit gar nichts anfangen - keine Wiedergabe)
    Auffällig ist beim Andro-VLC (probiert auf Nexus 7 sowie hier mit einem Galaxy S3) ausserdem, dass er nie sofort die Wiedergabe startet, sondern man immer erst nochmal den "play" Button drücken muss.


    Naja, ich weiss auch nicht wann ich nochmal Zeit habe, da weiterzuforschen. Aber vielleicht konnte ich Dich ja auf eine Idee bringen.


    Das mit dem Start ab aktuellem "resume" fände ich wie gesagt extrem hilfreich. Funktionieren täte das definitiv (s.oben), indem man eben wie Du sagst den Anfang "unterschlägt", genau. Beim Desktop-VLC (s.oben) auch indem man statt dem angeforderten initialen range den ab Start-Index zurückgibt. Ich habe aber leider keine Idee, wie ich aus dem Inhalt von "resume" (I wie I-Frame?) den Byte-Index in der Aufnahme mache..


    Aber auch das allgemeine Problem mit Andro-VLC und kein Springen (was er wie gesagt grundsätzlich offenbar schon beherrscht) zu beheben wäre natürlich sehr schön.


    Danke für die Arbeit am Plugin!


    Ein Nachtrag noch.. auch der Android MX-Player kann ohne Probleme im per Apache bereitgestellten Video springen - nicht aber bei streamdev. Irgendwas muss da noch anders sein. Strange.

    Auch ich habe die neuen Aufnahme-Streaming-Fähigkeiten des streamdev plugin jetzt entdeckt.
    Ist ja nur im repository drin, in der letzten versionierten 0.6.0 noch nicht.
    Und soweit ich sehe sind die Fähigkeiten auch noch praktisch "undokumentiert" - weder auf der Homepage des Plugin selbst, im README des Pakets oder im VDR
    Wiki sind sie erwähnt. (Im Streaming-Artikel des Wiki steht sogar noch explizit "Da der Streamdev-server keine Aufnahmen streamen kann.." -
    habe da eben mal einen Hinweis auf den aktuellen Stand mit aufgenommen).
    Lediglich unter den Tickets der plugin-Homepage und bei einzelnen Threads hier habe ich Hinweise darauf gefunden.
    Auf diese Weise werden wohl viele Leute nichts davon mitbekommen.
    Oder habe ich irgendeine Doku übersehen?


    Anhand der recordings.html wie im Web-Interface verlinkt bekommt man Streaming-Links auf die Aufnahmen. Alternativ klappen offenbar die Indices dieser Liste mit Streaming-URL http://host:port/<index>.rec


    Mich interessiert das vor allem um auf ein Tablet zu streamen - und zwar so, dass man leicht zwischen Haupt-TV und dem Tablet hin- und herwechseln kann.


    Während bei Wiedergabe des Streams über den Desktop-VLC (Win) in der Aufnahme gesprungen werden kann, ist das leider beim Android-VLC nicht der Fall (ebensowenig beim MX Player). Der Android-VLC schafft es aber (anders als MX Player) auf einem neuen Nexus 7 nun endlich, mit aktiviertem HW-Decoding HD-Streams (live und eben nun auch Aufnahmen) flüssig wiederzugeben (jedenfalls stabil und ohne Artefakte, leichtes Ruckeln mag noch dabei sein - 720p wie 1080i - ausreichende Netzverbindung vorausgesetzt).


    Warum klappt das Navigieren in der Aufnahme bei Android nicht? Wie funktioniert das Springen denn Protokoll-technisch?


    Gibt es einen Parameter in der URL, mit dem man die Start-Position angeben kann? Wenn nicht, das wäre eine sehr interessante Erweiterung, finde ich..
    Bzw auf dem Tab würde es so erst brauchbar, wenn man jede Aufnahme immer nur ganz von vorne starten kann und nicht springen ist das nicht praxistauglich.


    Sehr hilfreich wäre auch die Möglichkeit, die Aufnahmen an der Stelle zu starten, an der sie eben auch im VDR grade "stehen" - wiederum per Parameter oder sonstwie kodiert in der URL, etwa /123.rec.current


    Schliesslich habe ich noch die App androvdr probiert: fürs Live-Streaming aus der Channel-Liste heraus ist das ja ganz gut brauchbar, um nicht umständlich die URLs selbst im MediaPlayer eingeben zu müssen. Aufnahmen unterstützt sie aber wohl noch nicht - bei Versionsdatum Juli 2012 auch schwer möglich, damals gabs die Funktion im streamdev ja noch gar nicht..
    Weiss jemand, ob daran evtl. nochmal weiterentwickelt wird? Gibt es den Source dazu?
    Oder existiert eine andere ähnliche App die noch gepflegt wird?


    Merci für die Aufmerksamkeit!

    Naja schnell - yaVDR ist nun nicht die schnellste Installation, aber ob TT Karte oder mit ner S464 (GT430) ist gleich "schnell" (ex linvdr 5min) aufgesetzt.

    Ich verwende nicht yaVDR, habe alles selbst gemacht. Schnell ist relativ, aber nach Anleitung vorgegangen hat damals alles wesentliche praktisch auf Anhieb funktioniert. Meilenweit entfernt vom Aufwand den man mit xine/vdpau hatte anno 2009. yaVDR hatte ich auch mal probiert, geht natürlich schneller wenn dann alles tut, aber in meinem Fall war es leider nicht so (das war 2010).


    Kann ja sein dass es heutzutage mit yaVDR und diesem "softdevice" wirklich schnell und gut funktioniert. Ich weiss es nicht, ich bin halt skeptisch.


    Tatsache ist, dass ich (und offensichtlich auch viele andere) mit der 6400 zwei wirklich stabile, smoothe VDR habe, die absolut an die "gute alte Zeit" mit der SD-FF anknüpfen können, die Spass machen, und weitgehend keinerlei Probleme im Alltag haben. Ein bisschen Glück mag dabei sein, auch mit der 6400, dass alles "passt" (mit der sonstigen HW und den Treibern etc).


    Zu dem Antennen-Post im HW-Forum (da schau ich eigentlich nie rein, auch hier ja eher nur noch selten dank problemlosem Betrieb): das klingt nicht gut. Wenn das so "professionell" und eindeutig gemessen wurde - da müssen wir Dir mal vertrauen - ist das natürlich nicht schön.
    Ich möchte keinesfalls den Hersteller "in Schutz nehmen", wenn er Mist gebaut hat, sei es technisch oder bzgl. CI-Versprechen.
    Aber es ist ja oft so, dass etwas streng nach Spec nicht 100% perfekt ist, aber trotzdem bei den meinsten Leuten funktioniert, sprich "good enough"..


    Ich möchte nur dem Eindruck entgegen treten, der hier entstehen könnte, dass die Karte generell Mist ist und überflüssig. Aber das haben ja glücklicherweise auch andere hier schon gemacht. Daher ist von meiner Seite damit erst mal wieder genug gesagt.


    Eins aber noch konkret zu den Tunern. Ja, auch ich kannte von früher das Phänomen, dass gewisse Transponder nur mit einem der Tuner funktionieren.
    Das war zB Tele5 (SD), und jetzt ist es auch 3satHD. Man muss dann in der Tat zB mit femon den Tuner wechseln oder eben den anderen "binden", ja!
    Ich hielt es allerdings immer für möglich, dass dafür auch eine meiner Leitungen bzw. der Anschluss am LNB verantwortlich ist.
    Zum Glück betrifft es nur nicht ganz so wichtige Sender, jedenfalls nur solche aus anderen "Ebenen" als low-H, wo sonst fast alles zu finden ist.
    Also wenn daran wirklich die 6400 Schuld hat, ist das schon sehr unschön / Schade, keine Frage!
    Aber können das andere ausser uns bestätigen?

    ... der Tuner ist auch ein Konstruktionsfehler!

    Ist das jetzt Deine private Beobachtung, oder gibt es Quellen die auf ein breiteres Problem schliessen lassen?
    Bei mir tuns die Tuner genau so gut wie die Karten, die ich vorher im Einsatz hatte - bei eher mässigem Signal (Fensterdurchführung). Es gibt gelegentlich mal ein Dropout, aber eben auch nicht öfter als früher, eher besser.


    Generell muss ich in diesem 6400-Mäkel-Thread auch noch mal eine Lanze für die Karte brechen!
    Das mit der CI mag für alle ärgerlich sein, die darauf gewartet haben. Genau so wie es ärgerlich war, jahrelang auf die Karte warten zu müssen.
    Aber die Karte als solche ist einfach ein Garant (naja, jedenfalls eine verdammt gute Chance) für einen schnell aufgesetzten, stabil und problemlos laufenden VDR.
    Zwischen 2003 und 2009 hatte ich einen VDR (SD-FF). Von 2009 bis 2011 (eine, dann zwei) Bastel-Baustellen mit vdpau - klar, wer das Basteln am VDR lieber macht als ihn zu benutzen (der Weg ist das Ziel..). Seit 2011 habe ich dank der 6400 wieder zwei VDR. Bin froh, dass sich Klaus da offensichtlich nicht von einigen Miesmachern hier aus der Ruhe bringen lässt. Niemand ist gezwungen, die 6400 zu kaufen, aber sie für überflüssig zu erklären ist einfach grob daneben.


    Wenn es mittlerweile mit der SW-Ausgabe so toll funktioniert, ist das wunderbar. Persönlich glaube ich es erst, wenn ich es selbst probiert habe. Und dazu habe ich im Moment (zum Glück) keinen Anlass.

    Hier zwei Auszüge aus einer Antwort der ARDler auf eine Email von mir. Zunächst muss man ja festhalten, dass das meiste Spielfilmmaterial sowieso nur in 24 fps vorliegt. Dazu die ARD: [...]

    Tja, lustig, alles was die da schreiben bestätigt das bisher Gesagte bzw. die Kritik an der damaligen Entscheidung 720p.
    Siehe auch den c't Artikel aus 16/2010:
    http://www.heise.de/ct/inhalt/2010/16/44/ (leider nicht lesbar)


    Quote

    Das stellt sich mir zusätzlich noch die Frage wie schlau sind da
    unsere VDRs bzw. Ausgabeplugins. Erkennen die solch ein Fakeinterlace
    wie es gerne bei Filmen eingesetzt wird. Also schiebt er dann einfach
    Even und Odd zusammen oder wendet er da z.B. einen Temporal Spatial
    drauf an?


    Meines Wissens gibt es jedenfalls ein Flag in der Spezifikation, das diesen Fall kennzeichnet und die Receiver anhält es so zu machen (simples Zusammenbauen der exakt zusammenpassenden Halbbilder). Und ich gehe davon aus dass das zB die 6400 auch so macht - bzw. reicht sie die Frames ja auch in 1080i an den TV weiter, ggf. macht das also sogar der TV selbst ebenfalls. Mir sind jedenfalls schon lange keine Kamm-Artefakte bei 1080er Sendern mehr aufgefallen, auch nicht bei "Pause". Zumeist dürfte ich es dabei mit dem erwähnten defakto-25p-Material zu tun haben.


    (Edit, der Korrektheit halber)
    Man muss natürlich unterscheiden zwischen dem DVB-Datenstrom (mit dem erwähnten Flag) und der Übertragung über HDMI. Ob es auch bei HDMI 1080i möglich ist, eine solche Frame-Zusammengehörigkeit zu signalisieren, ist mir nicht bekannt, ich befürchte eher nicht. Da die 6400 nur 1080i beherrscht (kein 1080p), ist es relativ egal ob sie laut DVB-Flag Halbbilder zusammenfügt oder nur durchleitet: was zum TV geht ist interlaced. Trotzdem bin ich mit dem Ergebnis zufrieden und auch bei Pause gibt es keine ernsthaften Kamm-Artefakte - auch nicht bei vermutlich nativ interlaced Material (wie N24 HD Laufschrift). Ich nehme an, hier leistet der TV (Samsung D8090) eben ordentliche (Deinterlacer) Arbeit. 100% scharf ist es natürlich auch nicht.

    ich finde es schade, dass die Bandbreite nicht ordentlich genutzt wird. Das so gesendete Material benötigt dummerweise 100% mehr Platz auf meiner Festplatte. Möglicherweise spart der Encoder aber durch die redundanten Bilder ein paar Prozent.

    Also Video-Kompressionsalgorithmen sind schon sehr gut dabei, solche Redundanzen zu erkennen und zu nutzen - ich würde doch stark vermuten (ohne es 100% zu wissen) dass das deutlich mehr als "ein paar Prozent" sind. Die hohen Bitraten dürften also schon dann umso mehr dem allgemeinen Detailgrad / Bildqualität zugute kommen. Leider habe ich allerdings sehr oft bei den von den ÖR ausgestrahlten Sachen kaum den Eindruck, als wäre da übertrieben viel Detail. Noch weniger, als es die 720er-Limitierung erlauben würde. Auch finde ich es zwei Jahre nach dem (ohnehin späten) offiziellen HD-Start doch sehr schwach, dass immer noch so viele Sendungen, v.a. Brot-und-Butter Formate wie die Nachrichten (Tagesschau / heute), noch immer nicht in HD produziert werden - mal abgesehen davon wie viel einem das jetzt an Mehrwert bringt oder nicht.


    Aber sie sind halt sparsam, unsere ÖR. Und sie schenken uns Anfang Mai jede Menge neue HD Kanäle. Und ich schweife ab :)

    Ja, ist doch bekannt dass ein erklecklicher Teil des TV-Materials (alles rund um Filme und viele Serien) nur mit 25 Frames/s (oder max. ca 30) vorliegen. Was sollen sie dann auch anders machen als die Bilder zu verdoppeln?


    Gut, sie könnten aufwendige Verfahren Sender-seitig anwenden, um das Material "smoother" zu rechnen, mit teurer Technik - besser, als das in TVs eingebaute Hardware könnte. Aber das wäre wohl übertrieben. So etwas ähnliches tun sie ja angeblich mit dem international zB bei Sportveranstaltungen produzierten 1080i-Material bei der Umrechnung auf 720p: deinterlacen, besser als es jedes Heimgerät kann.


    Das (das erstere mit dem 25p-Material) war ja auch ein Grund, warum viele Leute (darunter damals schon vor langem in einer recht emotional geführten Diskussion auch ich) 1080i gegenüber 720p bevorzugen würden: durch die Zerlegung der 25 Frames in 50 je exakt zusammenpassende Halbbilder und entsprechender Zusammensetzung in den Clients (was diese auch beherrschen müssen, ist spezifiziert) hat man in zahlreichen Fällen unterm Strich auch defakto non-interlaced Wiedergabe. Und für den Rest des Programms (darunter zB unwichtige Dinge wie Fussball ;) kann man mit den Nachteilen von interlaced leben - lieber jedenfalls als mit der geringeren Auflösung bei 720p.


    Aber das Thema hat sich seither etwas totgefahren - auch wenn die ARD zwischenzeitlich noch von 720p als Produktionsformat weg ist (aber nicht für die Ausstrahlung) - es ist nun halt mal wie es ist, und mir sind keine neuen Entwicklungen bekannt dass die ÖR sich von irgendwelchen guten Argumenten beeindrucken lassen würden.. :)

    Code
    1. Can't locate Proc/ProcessTable.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at ./scripts/rmmod.pl line 4.


    Darauf war ich auch gestossen beim letzten Update. Wurde schon hier irgendwo erklärt - evtl. im Thread zum Treiber. Abhilfe schafft, das entsprechende Perl-Modul zu installieren, etwa in Ubuntu mit: apt-get install libproc-processtable-perl


    Wäre natürlich noch interessant, mal erklärt zu bekommen, was das genau ist, und warum das nun plötzlich gebraucht wird.
    Und wäre gut, es im Wiki mit zu erwähnen.

    Zwei Infrarotempfänger ... müssen allerdings auch sein.


    Nein, die müssen absolut nicht sein. Der Empfänger der 6400 lässt sich einwandfrei via LIRC auch für XBMC verwenden.


    Details dazu in diesem Thread:


    TT 6400 und XBMC mit einer FB


    Im ersten Post laufe ich da noch in eine etwas falsche Richtung, aber weiter unten wirds dann besser..


    Kurz zusammengefasst: das /dev/input/eventX lässt sich in LIRC konfigurieren, das dann sein /dev/lircd sowohl VDR wie auch XBMC zur Verfügung stellt. Während man den VDR "verlässt" (läuft natürlich weiter zB für Aufnahmen) schaltet man im VDR das Reagieren auf die FB ab, nach Ende XBMC wieder an. Das wars schon.

    Na der Thread ist doch die perfekte Vorlage für mich.
    Um es vorweg zu sagen: klarer Pro-6400 Beitrag - als kleiner Service für alle die ihn deshalb lieber gar nicht erst lesen ;)


    Ich war vor 2 Jahren von der FF zu vdpau (auf ION) gewechselt, weil ich endlich ins HD-Zeitalter starten wollte.
    Ein knappes Jahr später hatte ich dann noch einen zweiten VDR gebaut, auf i.w. gleicher HW-Basis.
    Der eine war selbstgebastelt, der andere auf Basis yavdr (erst 0.2 dann 0.3).


    Im Aufbau waren beide ein Riesenaufwand. Der selbstgemachte v.a. bzgl. xine - eben der vdpau-Ausgabe. War halt Sommer 2009 auch noch nicht so verbreitet - zwar nicht gerade Pionierarbeit, aber trotzdem viel zu tun. Aber auch mit yavdr hatte ich persönlich jede Menge Probleme - geht natürlich nicht allen so.


    Die beiden Jahre bis zur 6400 waren in der Rückschau "harte Zeiten". Zwar waren die Kisten einigermassen alltagstauglich, aber Spass gemacht haben sie nicht. Ruckler waren zuletzt weniger das Problem. Aber die Stabilität. Und insgesamt war das einfach keine "flüssige" Angelegenheit.


    Seit ich nun 2x 6400-basierte Systeme habe (siehe Sig), bin ich wieder rundum glücklich mit meinen VDRs. So wie sich das gehört. Sie sind stabil und smooth. Man kann wieder spulen! Also vernünftig. Allein dafür rentiert es sich schon!
    Mag sein dass die Technik auf der Karte aus heutiger Sich nicht gerade edge-of-technology ist und dafür auch eher teuer. Aber sie ist eben genau für einen bestimmten Zweck gemacht - und den erfüllt sie perfekt. Daher ist sie mir das absolut wert. Für mich ist ein "echter VDR" (Frontend) ohne 6400 nicht mehr denkbar, Sorry. Für mich ist aber auch ein VDR eben in erster Linie ein VDR, und kein HTPC. Mediaplayer etc sehe ich also als absolut zweitrangig an.


    Auf der Basis habe ich aber zwischenzeitlich auch XBMC installiert, auf beiden Kisten. Auf der mit ION läuft es dank vdpau ebenfalls soweit flüssig, d.h. ich kann zB HD .ts vom VDR ansehen. Auf der mit H67/Intel2000 ist es bei Video noch nicht so doll, da müsste ich mich wohl mal mit vaapi befassen - aber für die Mediatheken der ÖR reichts auch. Und Musik und Fotos sind sowieso kein Problem. XBMC als TV-Frontend interessiert mich nicht - wozu wenn man einen VDR hat? Und bitte - das Umschalten des HDMI-Eingangs am TV ist nun wirklich nicht so tragisch. Klar, wer nicht wie ich 95% VDR und nur 5% XBMC hat, mag das anders sehen - aber dann kauft er sich halt eine Harmony. Oder es gibt demnächst noch Fortschritte in Sachen CEC? Die technischen Grundlagen hat die Karte sicherlich, via CEC die HDMI-Eingänge zu steuern.


    Noch zur Distributionsfrage. Ich bin sicher yavdr ist eine gute Distribution, und mit etwas Glück kann man mit wenig Aufwand einen kompletten VDR erhalten. In dem noch dazu sehr viel "drinsteckt". Ich selbst bin aber davon wieder abgekommen. Sobald man irgendein Problem hat oder selbst Hand anlegen will, steht man im Wald. Denn mit Doku des technischen Aufbaus ist es nicht weit her - nachvollziehbarer Weise beschäftigen sich die Macher eben lieber mit dem Ausbau der Funktionalität als mit Doku. Aber d.h. dass man diese ausgefeilte, mit zahlreichen Details und Funktionen versehene Distri nur mit hohem Aufwand selbst soweit durchschauen kann, dass man nicht für jede Kleinigkeit auf eine Nachfrage im Forum angewiesen wäre. Daher kann ich nur empfehlen, wenn man Linux-Grundkenntnisse hat, lieber alles selbst zu machen: dann weiss man genau wo was wie gemacht ist, und hat einfach alles "im Griff".
    Als Grundlage dafür eignet sich wunderbar die Anleitung im VDR-Wiki "Ubuntu HD VDR mittels TechnoTrend S2-6400".


    Alles meine Meinung, versteht sich..


    Abschliessend Dank an alle, die bis zuletzt an die 6400 geglaubt haben, sie schliesslich tatsächlich doch noch gebaut haben (sogar noch vor dem Duke), und mit mittlerweile gut funktionierenden Treibern versorgt haben.


    So - nun dürfen zum Ausgleich wieder die vdpau-Verfechter ran..

    Ich habe jetzt auch wieder das dvbhddevice aktualisiert.


    (Der Patch von Copperhead neulich läuft damit nicht durch, die zwei fehlgeschlagenen "hunks" (oder waren es "chunks"?) scheinen aber unwichtig, da sie nichts ändern - die Zeilen bei + / - sehen identisch aus - vielleicht nur whitespace. Ich habe es also ignoriert, es funktioniert trotzdem).


    Ich kann bestätigen, dass bei Fortsetzung der Wiedergabe aus Pause weniger Tonaussetzer auftreten. D.h. genau der erste kurze (ca 0.5-1s nach Start) ist noch da, aber der zweite längere (tritt auf zwischen 2s und 6s nach Start mit ca 1s Länge) ist weg - abgesehen von extrem seltenen Ausnahmen.
    Dafür hatte ich zeitweise den Eindruck dass mehr Artefakte im Video sind - aber das kann auch unverändert sein, der übliche Effekt wenn man was ändert und dann ganz genau hinsieht. Mal gibts ordentlich Klötzchen, mal kaum.


    Die Auflösungsanpassung schon bei der letzten Aktualisierung hatte ich ganz übersehen. Funktioniert bei mir gut (nehme Einstellung "nur HD", SD darf gerne der VDR hochrechnen und sehe ich eh nur noch selten). Je nach TV führt das Umschalten natürlich zu einem kürzeren oder längeren Blackout, so dass man sich ggf. auch dazu entscheiden wird lieber doch fix in 1080i auszugeben - einen wirklichen Unterschied konnte ich bei 720p Sendern jetzt nicht ausmachen. Gelegentlich ist das grade sichtbare OSD nach der Umschaltung leicht verstümmelt, aber das ist nicht weiter tragisch.


    Merci an die Macher, wird immer runder!

    Copperhead


    Danke auch für den Patch, hat geklappt, plugin scheint noch / wieder zu funktionieren wie gewünscht.
    Wobei die Änderungen jetzt nicht unbedingt ein Update rechtfertigen: Finnisch / Italienisch brauch ich nicht, und diese Video-Mode-Anpassungen scheinen mir auch für den normalen Astra-TV-Betrieb mit dt. Sendern nicht relevant?
    War nicht mal die Rede davon, 720p-Sender auch so an den TV zu übertragen? Nur so als nächste Herausforderung an die Entwickler :)


    Und natürlich die Sache mit CEC (siehe Thread XBMC/FB).


    Auch den Treiber habe ich aktualisiert. Funktioniert bisher. Verbesserungen kann ich bisher nicht erkennen, aber die Probleme die mir so bekannt sind treten eben auch nur gelegentlich auf, d.h. es wird dauern bis man sagen kann ob sich da was getan hat.
    Aufgefallen ist mir höchstens, dass die Tonaussetzer beim Fortsetzen nach Pause (hatte ich so noch nicht explizit hier angesprochen) eher ein bisschen störender sind als bisher, weil sie auch gerne mal erst 6s nach Fortsetzen nochmal auftreten. (nix im Log)
    Alles in allem aber OK.
    IR-Geist war ja wie gesagt bereits allein durch die FW weg - d.h. evtl. überflüssige Hacks im Treiber deswegen könnte man wohl entfernen, insbesondere falls sie irgendwie minimal die Reaktivität verschlechtern. Dachte erst das sei der Fall, man kann nicht garzu schnell hintereinander Tasten drücken, sonst werden sie verschluckt - aber nachdem ich den Treiber nochmal zurückgerollt hatte war es dann doch das gleiche, also wohl keine ernsthafte Verschlechterung.

    genau über sowas denken wir auch nach -> sollte gehen. (tv auf xorg kanal anmachen -> wenn dvbhddevice an geht cec umschaltung -> dann cec wegnehmen beim aufruf von xbmc und analog)


    Wie - mit den schon jetzt vorhandenen Mitteln soll das gehen? Gut, dass er beim VDR-Start auf den richtigen Eingang umschaltet, wenn man CEC im plugin an hat, mag sein - aber wie gesagt kann man die Einstellung i.a. nicht brauchen, weil sonst auch der ausgeschaltete TV bei nächtlichen Aufnahmen plötzlich los geht. Und wenn man dann den VDR beendet würde der TV wieder dahin zurückgehen, wo er vorher war? Keine Ahnung ob das funktioniert. Aber für mich würde das nicht passen.
    Erst mal bin ich standardmässig auf dem VDR-HDMI, XBMC ist die Ausnahme. Zweitens beendet man den VDR ja gerade nicht, wenn man zu XBMC umschaltet, das "cec wegnehmen" müsste man also explizit irgendwie anstossen können. Ausserdem klingt "CEC wegnehmen" so, als wäre das ein An/Aus-Signal. Nach meinem Verständnis ist es ein vollständiges Protokoll, um alles mögliche zu signalisieren, also den TV weitgehend komplett steuern zu können.


    Die Idee wäre also, dass man eine richtige CEC-Befehls-Schnittstelle hat, mit der man eben explizit beim Start von XBMC auf den richtigen HDMI umschaltet, und danach wieder auf den VDR-HDMI schaltet. Ich könnte mir vorstellen dass im Treiber schon alles vorhanden ist, aber so eine Schnittstelle müsste wohl erst noch geschaffen werden.


    kannst du bitte deine lirc einstellungen, die lircd.conf, remote.conf und was man sonst noch so braucht evtl. lircmap.xml von xbmc reinstellen? Dann kann ich das für die user der mld einbauen. Wäre super!


    Also bei LIRC verwende ich die Default-Belegung für "Linux input layer", also nur den Verweis auf /usr/share/lirc/remotes/devinput/lircd.conf.devinput in der lircd.conf. Und entsprechend den Verweis in /etc/lirc/hardware.conf: REMOTE_DEVICE="/dev/input/ir"


    Die aufgezeichneten LIRC.* Einträge in remote.conf und die lircmap.xml sind dann natürlich abhängig von meiner FB (Philips SBC RU 631) - das wirst Du so kaum allgemein verwenden können. Aber als Beispiel habe ich es mal angehängt (da .xml nicht erlaubt als .xml.txt).

    Files

    • remote.conf

      (802 Byte, downloaded 54 times, last: )
    • Lircmap.xml.txt

      (1.98 kB, downloaded 71 times, last: )

    So, XBMC läuft, inklusive FB parallel zu VDR (nett: gibt ja sogar ein Mediathek-Plugin für ARD/ZDF/BFS/3sat etc).


    Nun muss ich also beim Start/Stop den HDMI umschalten. Das ist zu schaffen, hatte ich gesagt. Ja, klar, ist zu schaffen.
    Aber schön wärs natürlich schon wenn.. :)


    Und da kommt mir jetzt grade so in den Sinn: CEC! Die 6400 startet per CEC den TV, wenn der das kann und man es ihr / dem Plugin nicht abgewöhnt (was natürlich jeder als erstes tut, der den VDR auch mal für Aufnahmen in Abwesenheit nutzt - also fast jeder vermute ich).


    Also theoretisch müsste man per CEC ja auch sonstige Befehle übertragen können - wie zB das Umschalten des HDMI-Eingangs. Selbst wenn das TV-spezifisch unterschiedliche Codes sind, die könnte man ja beim Start/Stop-"Skript" (commands.conf) eintragen.


    Bräuchte man nur noch eine Art svdrpsend.pl für CEC. Und natürlich im Plugin müsste man CEC aktivieren können und gleichzeitig das TV-Power-On beim Start deaktiveren.


    Bisher existiert wohl nichts in der Art. Aber im Prinzip möglich sollte es sein? Wenn im Treiber und Plugin alles nötige implementiert wäre..

    Evtl. die anderen HD Sender schauen


    Also da steht "HDTV", nicht HD+!
    Meine Aussage bezog sich nicht darauf, dass hier Argumente gegen HD+ diskutiert werden (davon gibt es wahrlich genug), sondern richtete sich gegen die immer wieder aufkommenden Aussagen wie "ach, HD, wer braucht das, sieht man doch gar nicht wirklich, seid doch ehrlich, alles nur technische Daten.." - so in der Art.
    Und _das_ passt wirklich nicht hier her. Dagegen wollte ich argumentieren: doch, HD ist toll, HD will man haben.


    zB auch nach meinem Post wieder von Treito: "nur bei Standbildern sieht man HD". Naja. Klar ist in Bewegung deutlich weniger Schärfe zu sehen, vermutl. schon rein biologisch bedingt (menschlicher Sehapparat), bei 1080i durchs Interlacing, durch begrenzte Bitrate bei garzu viel Action. Aber auch da gibt es einen Unterschied. Und ausserdem ist das kein Argument gegen HD. Abgesehen von Sport und Daueractionkrachern hat man einen sehr hohen Anteil an (fast) "Standbildern".


    Quote

    Ich sehe das ganz einfach, HD+ ist eines der vielen Pay-TV Angebote. Jeder soll selber entscheiden welche Pay-TV angebote er nutzen will oder nicht.


    Rein kostentechnisch betrachtet sicherlich.
    Aber es gibt schon einen entscheidenden Unterschied. Die Programme von HD+ gibt es seit Jahrzehnten, die meisten Leute sind sie gewohnt und möchten nicht einfach drauf verzichten. Gleichzeitig sind die SD-Varianten nicht mehr zeitgemäss, natürlich möchte man die HD-Sender (hat eh lange genug gedauert).
    Der normale Weg wäre gewesen, dass auch die Privaten mit der Zeit von SD auf HD umstellen, ebenso wie die ÖR. Und zwar, ohne damit gleichzeitig so ein völlig lächerliches und indiskutables System wie HD+ einzuführen, mit dem jeder, der die gewohnten Programme in zeitgemässer Qualität sehen möchte, gezwungen wird, sich diesem Wahnsinn zu unterwerfen. Sicherlich kostet die Umstellung auf neue Technik Geld. Aber das ist normal bei Betrieb und Weiterentwicklung eines Geschäfts. Auch vor HD wurde regelmässig alles mögliche modernisiert. Das nennt man Investitionen zur Sicherung des zukünftigen Geschäftserfolgs. Wer heute immer noch nur den SD-Matsch anbietet, wird ggf. immer weniger Zuschauer haben.
    Die Privaten versuchen mit HD+ einfach nur, die Verhältnisse, die sich über lange Zeit gefestigt haben, von jetzt auf gleich komplett umzukrempeln und die Zuschauer "komplett unter Kontrolle" zu bringen - insbesondere zum Sehen von Werbung zu zwingen. Zugegeben, nachvollziehbar beim Stichwort "Sicherung des Geschäftserfolgs" bei Werbe-finanzierten Sendern. Nur wenn am Ende das dann nur noch die anschauen, die es ohnehin umgehen, wurde auch nichts gewonnen.
    Denn welcher vernünftige Mensch würde sich je diesem System unterwerfen.
    Vielleicht halten sie ihre Zielgruppe für so dämlich. Man wird sehen. Wie viele Leute in der Masse tatsächlich die Karte verlängern. Die letzten Zahlen dazu (aufgeblasen zum grossen Erfolg von HD+) waren ja doch eher zweifelhaft.

    Jetzt muss ich dazu auch noch ein paar grundsätzliche Worte sagen.


    Ob nun auf den Privaten nur Müll kommt oder nicht gehört nicht hier her. Vielleicht hat das Forum für sowas auch ein passendes Board. Aber im Prinzip geht es um den VDR, hier verbringen Leute viel Zeit damit an Geräten zu basteln, mit denen man fernsieht, und das dürften die meisten dann auch gelegentlich dazu nutzen. Ob nun für Arte oder RTL2 HD ist wirklich jedem selbst überlassen. Niemand ist gezwungen Werktags-Nachmittag-Programm auf den Privaten zu konsumieren. Sucht man sich das richtige raus, kommen auf fast allen Sendern gelegentlich brauchbare Dinge. Und genau dafür hat man einen VDR - man sieht das gute dann, wenn man Zeit hat, und ignoriert den ganzen Müll einfach. Ausserdem ist alles relativ - there is always a bigger fish - oder anders gesagt es gibt immer einen Intellektuellen der auch meine arte-Sendung XY als Zeitvertreib für Idioten sehen würde..


    Dass inzwischen auf den HD+ Sendern durchaus eine Menge halbwegs brauchbares (natives / echtes) HD kommt würde ich schon behaupten. Was fällt mir ein (bitte nicht inhaltlich bewerten, das sehe ich nicht alles an, zur Beurteilung der Bild-Qualität reicht schon vorbeizappen): Royal Pains, Hawaii Five-0, Smallville, Good Wife, Lie To Me, Der letzte Bulle & Danni Lowinski.. und jede Menge weitere Serien. Die Mehrheit der US-Serien die ich über das letzte Jahr verfolgt habe. Inzwischen doch auch die meisten aktuellen Spielfilme. Aktuelle "Events" wie das USFO-Casting (schon 2010) bis zu Fussball/Formel1. Natürlich gibt es auch noch Gegenbeispiele (Kocharena).


    Kurz: ich finde schon dass die HD+ HD-Sender inzwischen ähnliches HD-Niveau / Anteil haben wie die ÖR. Technisch gesehen. Dabei noch die höhere Auflösung (bitte keine 720p/1080i Diskussion jetzt..) (nur die Haupt-Sender, bei zB SIXX HD siehts noch schlecht aus mit echtem HD - auch auf N24 HD habe ich noch wenig HD gesehen, im Vergleich zu den Dokus auf ServusTV und Anixe - sogar die alten Lassie-Folgen haben streckenweise erstaunliche Schärfe)


    Sprich: ich möchte heutzutage das alles nicht mehr in SD sehen - Punkt. Es ist vielfach deutlich besser in HD, und sei es weil die SD-Varianten künstlich verschlechtert werden, um Bedarf für HD zu erzeugen. Ich mag den Matsch nicht mehr sehen.


    Es gibt Leute die HD nicht "sehen"? Denen es egal ist? Mag sein. Sei es die Sehkraft (meine ist extrem schlecht, aber eine Brille tuts), sei es ein schlechter oder kleiner TV oder zu weit weg oder einfach "kein Interesse". Aber das hier ist das VDR-HDTV-Forum. Wer sich nicht für HDTV interessiert, was macht der hier?
    Klar ist auch: auch bei nativem HD gibt es Szenen, wo man es nicht sofort sehen kann. Innenaufnahmen, Grossaufnahmen - sei es schlechte Aufnahmetechnik oder der Verzicht auf künstliches Schärfen, Griesel bei wenig Licht - ich sehe auch nicht immer auf den ersten Blick ganz eindeutig "das ist HD" oder nicht. Aber spätestens bei Totalen, also Übersichtsaufnahmen, draussen, mit vielen Details, Aufnahmen im Wald oder dergleichen ist es einfach ein Unterschied wie Tag und Nacht. Wer das nicht sieht..!? Und darauf will man nicht mehr verzichten. Paradebeispiele.. sei es nun Lost gewesen (Inselaufnahmen oft atemberaubend, aber auch Gesichter mit jedem Barthaar / jeder Pore), oder aktuell HawaiiFive0, oder wirklich gestochen scharfe Innenaufnahmen beim "letzten Bullen", oder auch auf den ÖR zB die beste Serie aller Zeiten (Breaking Bad) mit oft starken Einstellungen oder die Natur-Dokus auf ARD am Montag (trotz nur 720p). HD ist eine neue Dimension. Wer das ernsthaft bestreitet, hat einfach noch kein echtes HD gesehen (oder kann es nicht richtig sehen, warum auch immer). Deshalb baut man sich einen HD-VDR. Und dafür gibt es dieses Board.


    HD+ ist ganz grosse Sch*! Ja klar! Welcher denkende Mensch würde das anders sehen? Also muss ich es boykottieren? Nö! Echt nicht! Siehe oben: ich möchte im Jahr 2011 vernünftige Qualität. Bin sogar noch bereit für Werbung 55 Euro im Jahr zu zahlen (ja, schlagt mir mal ordentlich ein Brett vor den Kopf, vielleicht wache ich auf).
    Die ganzen Restriktionen zu umgehen ist die beste "Bestrafung" für den Nepp. Gut, mag kurzfristig gedacht sein, wehe bei der nächsten Verschärfung. Aber ich sehe nicht ein mich selbst zu kasteien aus ideologischen Gründen.


    Dass also HD+ (bzgl. der Restriktionen) Dreck ist ist klar. Dass es absolut legitim ist die Restriktionen zu umgehen sieht hier wohl auch jeder so. Was nun genau legal oder theoretisch gar strafrechtlich relevant ist.. Hier im Board darf es nicht technisch diskutiert werden, wie man es macht, und das muss man respektieren. Keiner von uns hätte Lust auf rechtliche Auseinandersetzungen.


    Ich glaube allerdings dass sich die Menge der VDR-Nutzer in so überschaubarem Rahmen hält, dass denen deswegen keine grauen Haare wachsen. Es ist schon ein gewisser Aufwand nötig das zum Laufen zu bringen. Den meisten "Normalos" kann man HD+ also höchstens mit einer Dreambox empfehlen. Und das ist immerhin ein kommerzieller Hersteller, der bisher nicht in Grund und Boden geklagt wurde. Bei 1000 Euro für eine 8000 eben auch ein überschaubarer Markt, keine kritische Masse.
    Aber völlig klar: könnte ich HD+ nur so haben wie vorgesehen, würde ich es auch nach einem Lachanfall links liegen lassen. Und den Untergang des Abendlands beweinen, da es heute ohne HD einfach keinen Spass mehr macht..


    Soweit also mein pro-HD Plädoyer. Und pro-HD+ (bei uneingeschränkter Nutzung, trotz PayTV). Und gleichzeitig f*ck-HD+
    Natürlich bleibt zu hoffen dass es floppt und früher oder später der ganze Mist drumrum aufgegeben wird.
    Bei bezahlten Musik-Downloads währte die DRM-Ära ja auch nicht ewig.