Beiträge von M-Reimer

Zitat

primaer wuerde ich sie aber _jetzt_ auch nach /usr//share/vdr/... legen.

Am besten an die Stelle, an der es jetzt bereits unter Gentoo liegt:
/usr/share/vdr/graphlcd/fonts
Logos dann nach
/usr/share/vdr/graphlcd/logos

Zitat

aber warum nun graphlcd.conf nach /etc/vdr/plugins soll, verstehe ich nicht so recht: graphlcd-base
hat auch noch ander eprogramme die es benutzen, nicht nur vdr. bei lcdproc liegt die
konfig ja auch nicht unter /etc/vdr/plugins, oder?

Vergiss meinen Kommentar zur graphlcd.conf. Ich habe nur gefragt, warum Gentoo den Symlink überhaupt anlegt. graphlcd.conf gehört nach /etc. Schon weil graphlcd-base eben auch vom VDR unabhängige Tools mitbringt und diese die Config auf finden wollen.

Zitat

Original von halbfertiger
- zusätzlicher Stecker für Stromversorgung, anstatt in einem Stecker

Die eine Seite geht zum Mainboard, die andere kommt vom Netzteil. Wie soll das in einem Stecker gehen (von Sonderlösungen abgesehen, wie externe Gehäuse, in denen das Netzteil direkt verbaut ist).

Man darf auch nicht vergessen, dass SATA-Stromkabel auch 3,3V führen. Noch nutzen das die Hersteller nicht, da sonst sehr viele alte Netzteile ein Fall für den Schrott wären. Allerdings gehe ich schon davon aus, dass man sich bei der Entscheidung, 3,3V aufzunehmen, etwas gedacht hat. Nach einer angemessenen Übergangszeit werden die Festplattenhersteller diese Spannung vermutlich nutzen wollen.

Zitat

Original von hd.brummy
Unter gentoo, z.B., liegen fonts in /usr/share/fonts/(corefonts)/ darauf hin sollte das im source angepasste werden.

War das unter Gentoo nicht bis vor kurzem "/usr/share/vdr/graphlcd/fonts", was IMHO auch ein besserer Default wäre. Die Fonts gehören erstmal zu graphlcd.

Ich habe das bei mir so gelöst, dass es bei mir unter /etc/vdr/plugins/graphlcd entsprechende Symlinks nach /usr/share gibt.

Nachtrag:
http://mirror.hamakor.org.il/p…vdr-graphlcd-0.1.8.ebuild

Hier sieht man eindeutig, dass Gentoo es genau so macht, wie ich schon seit längerer Zeit. Fonts liegen unter /usr/share/fonts/graphlcd/fonts. Das einzige, dass dieses ebuild macht, ist eine Handvoll Symlinks von /usr/share/fonts/corefonts in das Font-Verzeichnis von graphlcd. An der Stelle könnte man höchstens fordern, dass diese TTF-Fonts doch bitte via Fontconfig direkt aus dem System-Font-Verzeichnis geholt werden, sofern das nicht sowieso schon der Fall ist.

Komisch, dass Gentoo einen Symlink von /etc/graphlcd.conf nach /etc/vdr/plugins/graphlcd/graphlcd.conf baut. Bei mir tut das schon seit einer Ewigkeit ohne diesen.

Um es erstmal kurz zusammenzufassen: Ich mag beide nicht. Weder Gottschalk noch Jauch.

Wetten dass kann ich schon länger nicht mehr ertragen. Vor einiger Zeit habe ich mir das dann und wann angeschaut, aber um ehrlich zu sein: Das ganze Gelaber zwischen den Wetten nervt mich extrem. Für mich ist das lästiger als Werbung bei den Privaten. Eigentlich wäre es sinnvoll Wetten dass aufzunehmen, das Gelaber rauszuschneiden und das ganze erst dann anzuschauen. So nachbearbeitet ist die Sendung dann vermutlich nur noch etwa eine Stunde lang.

Die Karte kann, soweit ich das im Sourcecode des Plugins verstehe, durchaus skalieren. Man kann sich also festlegen, welches Format zum TV gesendet wird.

Weiteres weiß man, wenn der erste die Karte testet.

Synchronisieren muss sich jede Lösung für die Ausgabe. Ob da jeder TV langsam ist, weiß ich nicht.

Und der XServer hat mit einem schnelleren Synchronisieren erstmal garnichts zu tun. Er ist notwendiges Übel, weil der Nvidia-Treiber nicht ohne läuft. Bei Intel-Grafikkarten wäre ein direktes Ausgabe-Plugin ganz ohne X-Server, Xine und wasweißich möglich.

Auf jedem Fall ist diese Diskussion hier in Gänze Off-Topic.

Meiner Meinung nach wohl eher nicht. Deren Ziel ist ein ganz anderes. AFAIK gehen die doch sogar so langsam richtung XBMC und die vielen Addons, die den X-Server brauchen, werden auch nicht laufen.

Zitat

Original von speefak
aber immer positiv denken : immerhin wechseln immer mehr zu Linux, welches ist recht egal, wenn das die Industrie dann irgendwann mal schätzt wird Hardware wie auch Software in dem Umfang wie bei Windows unterstützt - nur das diese dann hoffentlich nicht auch so verbugt ist.

Meine Meinung zu der Sache: Ich will die Closed-Source-Software, die es unter Windows gibt, garnicht unter Linux haben. Und Treiber sollten bitte Open Source sein, dass ggf. nicht nur der Hersteller die Möglichkeit hat, einen Bug zu suchen oder den Treiber für ein 10 Jahre altes Gerät nochmal auf einen aktuellen Kernel zu portieren. Nur meine Meinung. Diskussion ggf. via PN oder in einem anderen Thread. Wir werden Off-Topic

Schaffe dir, falls du im Betrieb mehrere Geräte umschalten musst, einfach einen HDMI-Umschalter an. Ist auch besser für die Stecker

Zitat

Original von Copperhead
Das war nur der Fall, wenn man über ein AVBoard RGB ausgegeben hat.

Das AVBoard hat eine Schutzschaltung. Theoretisch sollte das AVBoard also den RGB-Ausgang schützen.

Allgemein kann man sagen, dass es nicht verkehrt ist, die Geräte auf ein Potential zu bekommen, bevor man irgendwas steckt. Ich habe zum Umschalten meiner (SD-) Geräte einen Scart-Umschalter, bei dem die Massen aller Geräte verbunden sind. So liegen alle Geräte mit allen Masseleitungen auf dem gleichen Potential und Schalten der Signalleitungen sollte vergleichsweise harmlos sein.

Richtig gefährlich ist es, wenn die Geräte sich im Potential unterscheiden. Das ist durchaus möglich wenn ein Gerät schutzgeerdet (PC, VDR) ist und eines schutzisoliert (TV) ist. Bei den allermeisten Schaltnetzteilen wird zur Entstörung über Y-Kondensatoren ca. 110V mit ganz geringem Strom auf die Gerätemasse übertragen. Im Gegensatz zum schutzgeerdeten Gerät läuft diese Spannung beim schutzisolierten Gerät nicht direkt nach Erde ab sondern liegt an der Gerätemasse an. Beim Stecken der Verbindungen läuft also ca. 110V Differenzpotential im ungünstigsten Fall direkt über die Signalleitungen vom schutzisolierten zum schutzgeerdeten Gerät.

Eben.

Rocketeer: So leid es mir tut, aber diese ganze Diskussion ist hier OFF TOPIC. Vermutlich bist du der einzige hier, der an Windows interessiert ist.

Zitat

Original von helau
Ein virtueller rootserver fuer ca 7 Euro im Monat reicht fuers VDR-Portal aber dicke, zumindest wenn man es beim richtigen Provider macht.

Für ein paar EUR mehr gibt es auch ein passendes Managed-Hosting inklusive SSH-Zugang. Webserver-Software auf dem aktuellen Stand halten kostet auch Zeit. Bei einem öffentlich zugänglichen System müsste man sich regelmäßig um Sicherheits-Updates kümmern. Eine Aufgabe die ich gerne meinem Hoster überlasse.

Ich will ja die Euphorie nicht bremsen, aber Ulrich Eckhardt hat noch nirgends zugesagt, dass er das DVD-Plugin übernehmen will. Wobei das natürlich absolut zu begrüßen wäre. Das Plugin ist schon lange ungepflegt und eine saubere Integration eines DVD-Players in den VDR ist durchaus interessant. Ohne Kenntnis der für DVD-Playback nötigen Libaries ist das aber keine einfache Aufgabe, das Plugin zu übernehmen...

Zitat

Original von Rocketeer
@www-dvbshop-tv:
Mal noch eine Frage: Die Windows-Treiber wird es doch dann sicherlich auch zum DL bei TT geben. Wir die Karte eigentlich auch via ProgDVB o.ä. zum Leben zu erwecken sein, oder wird hier empfohlen, auf die Windows-Anwendung zu warten ?

Fragen, die privat an den DVB-Shop gehen sollen, wären eventuell hier eher On-Topic:
http://www.dvbshop.net/shop_co…hp/coID/7/content/Kontakt
Ich persönlich zweifle daran, dass in absehbarer Zeit unter Windows etwas anderes als die Software von TT laufen wird. Für breiten Support wurden vermutlich auch zu wenige Karten gefertigt.
Optimale Ausnutzung der Karte ist dann auf lange Sicht erstmal nur mit dem VDR möglich, womit wir dann wieder On-Topic wären.

Zitat

Original von Copperhead
Wäre es eine gute Idee diese Gehäuse in einem Schrank einzusetzen, indem oben nur noch 1cm Platz ist?

Ich habe beim Überfliegen gerade gelesen, dass jemand zur Optimierung der Luftführung die Luftlöcher oben sogar zugeklebt hat. Ich denke das wird funktionieren. Es gibt noch Luftöffnungen links und rechts am Gehäuse. Eventuell sollte man die rechten Löcher in der Seite sogar zukleben, dass der Netzteillüfter nicht kalte Luft von Rechts zieht sondern warme durch das Gehäuse von links.

Was das Netzteil angeht: http://www.reichelt.de/?ARTICLE=56812

Um das nachzurüsten können aber die üblichen verdächtigen (Atric und Co.) verwendet werden. Eventuell hat eine der Stiftleisten auf der Karte ja die Funktion ggf. einen internen IR-Empfänger anzustecken. Dort könnte man dann evtl. auch den extern angesteckten anzapfen und das Signal einem IR-Einschalter zuführen.

Zitat

Original von Atechsystem

hab ich hier: EasyOne HD S2

Gibt es für 60€ in diversen Shops. Timer, Aufnahme und Abspielen absolut zuverlässig.

Meinte natürlich auf VDR-Basis und der kann eben doch etwas mehr als die meisten Kaufgeräte. An einen gut konfigurierten VDR kommt bestenfalls die Reel-Box ran.

Nur zwei Beispiele: markad-Plugin und mp3-Plugin. Mit letzterem ersetzt mir der VDR ein zusätzliches Internet-Radio.

Zitat

Original von Keine_Ahnung
Du vergisst das VDR Startscript das den VDR neu startet wenn die Firmware abstürzt.

Ob das mit dem aktuellen Stand des Treibers noch nötig ist, sei dahin gestellt. Die alte FF ist schon gut abgehangen.

Zitat

Und dann die diversen Speicherupdate und Bandbreiten Hardware Mods

Die Karte ist mit der Zeit eben "gewachsen". Hier geht es um komplett neue Hardware, die dann hoffentlich keinen Bandbreiten-Engpass mehr hat.

Zitat

Und dann muss man sich evtl. noch nen Mediaplayer hinfummeln damit er da auch seine nicht VDR Video ausgeben kann (on the Fly recoding).

s/muss/kann/
Pflicht war das nie. Es geht auch ohne. Ich hatte ja auch "bedingungslos stabiler HD-Festplattenreceiver" geschrieben und nicht Media-Player.

Die Video-Dateien, die ich am VDR wiedergeben will, sind zumindest bei mir die, die ich ohnehin mit dem VDR aufgenommen habe. Und die laufen auch ohne zusätzlichen Player.

Die Karte richtet sich an diejenigen, die einen bedingungslos stabilen HD-Festplattenreceiver auf VDR-Basis bauen wollen. Jede zusätzliche Zeile Code kann Fehler haben und für Probleme sorgen. Diese Kette ist bei VDPAU recht lang:

[list=1]
[*]xineliboutput-Plugin
[*]vdr-sxfe
[*]xine-lib
[*]libvdpau
[*]X-Server
[*]Nvidia-Closed-Source-Treiber
[*]GraKa-Firmware
[*]---> TV
[/list=1]

Bei der neuen FF dagegen:

[list=1]
[*]dvbhddevice-Plugin
[*]Treiber
[*]DVB-S2 FF Firmware
[*]---> TV
[/list=1]

P.S. Kann eigentlich hier mal wieder ein Mod den Besen schwingen?

Zitat

Läuft bei mir wunderbar.

Bestens. Dann also xbm als Alternative zum glcd Format. Schon weil der Code bereits existiert.

Zitat

DAS ist das Problem, einmal schnell irgendwas seltsames genommen und JEDER User fummelt da stundenlang rum.
Ein Problem ist z.B. das die Transparente Farbe an erster Stelle in der Farbliste stehen muss. Keine Ahnung obs dafür nen Parameter gibt, der Texteditor ist schneller als sich da reinzufummeln.

http://www.imagemagick.org/scr…ons.php#transparent-color

Zitat

Mach mal XPM mit nem Texteditor auf Dann siehst du das es nur nen Workaround dafür ist, das ELF keine Resourcen kann. Und so was als Grafikformat nutzen... schon ne seltsame Idee.

Finde ich ganz und garnicht seltsam, denn dieses Format kann, dank Plain-Text, sehr einfach in allen möglichen Programmiersprachen verarbeitet werden, ohne dafür eine Library oder ein Modul zu benötigen. Der Aufbau ist auf dem ersten Blick offensichtlich. Ich habe in der Vergangenheit schon öfters in Scripten als Zwischenschritt XPM-Dateien erzeugt (z.B. via "convert" aus ImageMagick) um diese Text-Files dann im Script-Code einlesen zu können.

Zitat

Jup, am besten gleich XML, natürlich in Unicode, dann kann man den Speicherbedarf nochmal verdoppeln Dann brauchts aber natürlich nen DOM Parser im Code (natürlich mal schnell selbst programmiert damit man keine Abhängigkeiten hat ) damit das auch anständig portabel ist.

UTF-8 benötigt nur für Nicht-Ascii-Zeichen mehr Speicher. Allerdings ist XML selbstverständlich nur für Vektorformate sinnig (SVG). Bei Pixelformaten wäre ein XML, das letztlich Zeilen und Spalten beschreibt, um für jede Zelle einen Farbwert zu merken, schon reichlich Overkill.

Abhängigkeiten sind per Default erstmal immer dann schlecht, wenn man sie irgendwie vermeiden kann.

xbm wurde auch schon erwähnt. Soll wohl schon gehen mit der 0.2.0pre. Wäre also wohl einfach zu portieren und allemal besser als eine zusätzliche Abhängigkeit.

Was die Konvertierung angeht: Ich kenne skinenigma nicht. Keine Ahnung was da falsch läuft. Eventuell könnte man das Problem aber entweder via Fix am Skin oder mit anderen imagemagick-Parametern in den Griff bekommen.

Und was "anständig binäres" angeht: Binär ist in der heutigen Zeit niemals anständig und gerade bmp ist proprietär. Bitte nicht sowas!