Beiträge von M-Reimer

Unauffällig stimmt. Dafür viele tote Knöpfe

Was das Fenster angeht: Mit sehr viel Zeit und sehr viel Fingerspitzengefühl ist es machbar ein Loch erst grob vorzusägen und dann mit z.B. Schlüsselfeilen fein nachzubearbeiten. Das Plexi dann genau einpassen. Bei mir ist das so genau geworden, dass das Plexi ohne Kleber hält.

Was das Plexiglas angeht: Du hast doch bestimmt irgendwo ein Päckchen CD-Hüllen. Mein Plexi ist aus einer Front einer CD-Hülle geschnitten. Kostet faktisch nix. Wenn das doch mal unschön werden sollte, dann baue ich mir einfach ein neues.

IDE und SATA-Konverter zusammen kann nur dann gehen, wenn der IDE2SATA-Adapter entweder Cable-Select beherrscht oder gejumpert werden kann. Ich zweifle an, dass es sowas wirklich gibt...

Wäre denn eine PCI-Karte mit eigenem SATA-Controller eine Möglichkeit? Wenn der VDR nicht allzu eng aufgebaut ist, dann würde eine Karte, die auch eSATA beherrscht, ein echter Mehrwert!

Gerade mit den öffentlich rechtlichen kann ich garnichts anfangen. Demnach sind das auch die ehesten Kanäle, bei denen ich auf HDTV verzichten könnte. Lindenstraße und Musikantenstadl in HD *schauder*.

Allerdings muss ich zugeben, dass ich zumindest RTL kaum sehe. RTL2 schon öfter mal und SuperRTL dann und wann mal. Deutlich wichtiger ist mir Pro7, wobei ich mich auch dort schon geärgert habe (Serie, die ich eigentlich gerne gesehen habe erst nach 22:00 verschoben und dann auf früh morgens am Samstag).

Anständige Spielfilme finden sich nunmal gehäuft auf den privaten Kanälen, während bei den ÖR "Tatort" läuft...

... und gerade für die ÖR würde ich mir eine Verschlüsselung wünschen. Auf die kann ich am ehesten verzichten und das gesparte Geld könnte dann in ein "Sky-Abo" (ehem. Premiere) re-investiert werden.

Hallo,

wenn ich mir das so durchlese:
http://www.heise.de/newsticker/meldung/139929
dann würde ich sagen, dass anscheinend jetzt doch letztlich alles so kommt, wie es schon in diesem Thread:
CI-"plus"
vermutet wurde.

RTL und VOX künftig in HD. Auf den ersten Blick natürlich gute Nachricht.

Weniger schön dagegen:

Zitat

SES-Astra-Sprecher Markus Payer gab auf Nachfrage von heise online zudem an, dass man gerne CI-Plus als Zugangssystem einsetzen würde.

Noch übler:

Zitat

tatsächlich dürften die Provider beziehungsweise ihre Inhaltelieferanten es nicht gerne sehen, dass sich mit vielen nicht zertifizierten CI-Receivern mit Festplatte oder USB-Port für Wechselmedien problemlos TV-Mitschnitte anfertigen lassen.

Was genau ist so schlimm daran, dass man TV-Mitschnitte anfertigen kann? Diese Bevormundung durch die Industrie geht mir ganz schön auf den S*ck!

VDR also außen vor und die ganze Entwicklung, die bisher in Richtung HD getan wurde, für die Katz?

Wie geht es eurer Meinung nach nun weiter?

Geht, wenn man VDR ohnehin als Root laufen lässt. Wenn das nicht der Fall ist, dann kommen meine beschriebenen Probleme zum Tragen. Ein Kompromiss könnte sein, dass man runvdr-conf.d via sudo freigibt. Keine Ahnung ob das gehen würde.

Allerdings habe ich selbst keinen Bedarf mich da weiter mit zu befassen. Wie oft schaltet man denn täglich ein Plugin an- und aus? Und wenn man das tatsächlich tut, dann hat das wohl einen Grund (Fehlersuche, ...) und man ist deshalb ohnehin via SSH auf dem VDR.

Das "alles in einer Config"-Konzept sagt mir da doch eher zu...
Am ehesten könnte ich mich noch mit einem "dialog"-Basierten Konfig-Programm anfreunden, welches via SSH die Plugins schaltbar macht.

BTW: Ich habe gerade mal einen Versuch gewagt:

#!/bin/bash
function printparams {
  echo "Parameter1: ${1}"
  echo "Parameter2: ${2}"
}
declare -a TESTARR=()
TESTARR[0]="printparams"
TESTARR[1]="dies ist ein '' Test"
TESTARR[2]="ein String mit \"Quotes\""
"${TESTARR[@]}"

Ergebnis:

Parameter1: dies ist ein '' Test
Parameter2: ein String mit "Quotes"

Deshalb meine Frage: Warum wird im runvdr-extreme überhaupt manuell gequotet, wenn es doch wohl auch ohne geht... Mir sieht es so aus, als würde die Bash direkt quoten. Die einzelnen Array-Elemente kommen ja sauber getrennt in meiner Unter-Funktion an.

ein

echo "${TESTARR[@]}"

lügt übrigens! Die Bash expandiert auch hier die Array-Elemente und übergibt diese als einzelne Parameter an "echo" weiter. Echo hängt aber alle Parameter via Leerzeichen aneinander. Das was "echo" ausgibt ist also nicht das, was ausgeführt wird!

Zitat

Originally posted by Frodo
Ich fürchte wenn das einer in Perl realisiert verstehen die meisten auch nur noch Bahnhof.
Denn dort kann man genauso kryptisch programmieren.

Stimmt. Kommt immer darauf an, wie man programmiert. An der Stelle wäre dann mal ein großes Lob für runvdr-extreme angesagt. Absolut vorbildlich strukturiert und soweit gut lesbar. Macht schon beim ersten Überfliegen im Editor einen sauberen Eindruck. Nur das mit dem Zusammensetzen der Befehlszeile und das Quoten. Da steige ich irgendwie noch nicht so ganz durch...

Ab einer gewissen Komplexität ist es in Shellscript aber definitiv vorbei. Ich habe gerade erst so einen Fall. Ich habe es erst in Shellscript probiert, da ich davon ausgegangen bin, dass es eventuell für ein breiteres Publikum verständlich ist. Bis ich dann irgendwann "Shell-Typische" Würgarounds gebraucht habe und das Script letztlich auch sehr langsam gelaufen ist. In Perl übersetzt und schon ist das ganze um den Faktor 30 schneller.

Zitat

Ausserdem hat man dann wieder die Abhängigkeiten mit Perl Modulen weil man irgendetwas benötigt was die Standard Perl Distribution gerade nicht dabei hat.

Das ist allerdings auch etwas, dass ich immer mal wieder befürchte. Meine einfache Lösung: Möglichst mit dem auskommen, was Perl mitliefert. Gängige Kandidaten, die ich z.B. bewusst mit "system" anwende, sind "wget" und "gpg". Beide könnte man mit Perl-Modulen ersetzen, aber einfacher wird dadurch nichts und man bekommt unnötige Abhängigkeiten.

Mal was ganz anderes, passt aber zum Thema

- Wird das osdserver-Plugin noch weiterentwickelt? Läuft es in VDR 1.6 und 1.7?
- Wie genau ist das mit dem OSD für die Plugin-Auswahl gedacht?

Würde ich VDR z.B. nicht als Root sondern als User "vdr" laufen lassen, dann muss dieser User Schreibrecht auf das Verzeichnis mit den Config-Daten haben, da sonst "runvdr-conf.d" nicht die Symlinks dort anlegen kann. Was mich jetzt rein von der Sicherheit her etwas stört ist, dass die Scripts in eben diesem Verzeichnis beim Booten mit Root-Recht ausgeführt werden. Auch wenn es unwahrscheinlich ist: Der User "vdr" könnte so problemlos "root" werden.

Ist für mich zwar nicht so kritisch, da ich eigentlich die Idee mit dem "AddPlugin" direkt in der Config nett finde (auf jedem Fall besser wie das manuell in eine lange Befehlszeile zu bauen), aber interessieren würde es mich doch

Spricht eigentlich etwas dagegen, runvdr-extreme in Perl umzusetzen? Gerade das Zusammenbauen von Befehlszeilen stelle ich mir dort reichlich einfacher vor, denn Befehlszeilen werden nicht zwingend von einer Shell geparst, sondern "system" nimmt auch ein Array an, welches dann aus beliebig gearteten Strings für die Parameter besteht. Das ganze Quoten und die damit verbundene Komplexität und schwere Lesbarkeit für Außenstehende würden entfallen...

Selbst wenn die FF-Karte mehr kostet, wäre sie doch letztlich unter Umständen eine stabile und einfache Lösung für HD-Ausgabe.

Wenn HD wirklich in Zukunft interessant wird, bzw. eine gewisse Wichtigkeit erlangt, dann wäre doch nett, wenn man das mit VDR so einfach nutzen könnte, wie mit der FF-Karte für SD-TV. Karte einbauen, Firmware dazu, VDR anwerfen, geht. Noch sehe ich da keine ebenso einfache Alternative für HDTV.

HAL hat nichts mit Soundausgabe zu tun. Wäre mir zumindest neu. Der Ton wird via ALSA ausgeben. Da ist wohl eher relevant ob der User in der Gruppe "audio" ist. Selbst wenn der Xserver gegen die HAL-Libraries gebaut wurde (AFAIK kann man das mit ganz neuen X-Servern machen, um Mäuse, Tastaturen o.Ä. per Hotplug aktiviert zu bekommen), dann kann immer noch der "hald" abgeklemmt werden. Keine Ahnung wie man das in Ubuntu macht. Ich habe bisher von den "Debians" immer gebührenden Abstand gehalten.

Was deine Meldungen angeht: Wie hast du das Modul installiert? Du hast aber schon den ganzen dvbs2-liplianin-Treiber gänzlich via "make install" installiert, oder? Nur das eine Modul rausklauen wird nix!

HAL kannst du ohne Bedenken und ohne Gnade wegkillen. Am besten deinstallieren. Sowas hat weder auf einem VDR, noch auf einem Server was verloren! Bei meinen Slackware-Installationen wähle ich den HAL-Start immer schon beim Setup ab.

Was deinen mcli-Aufruf angeht: ifname ist die LAN-Karte. Wie hast du denn hinbekommen, dass die bei dir "netceiver" heißt? Da dürfte wohl "eth0" hingehören.

der 32bit mcli wird in einem "echten" 64-bit System nicht laufen. Mit Gefummel und doppelten Libraries könnte das aber wohl gehen.

Ich habe es zwar selbst nie probiert, aber angeblich ist >4GB RAM unter Linux 32-bit kein Thema.

Wir reden aneinander vorbei

Dein Patch geht eben weil er die Abwärtskompatibilität nicht drin hat!

Kernel 2.6.27.7 hat bereits das neue API, aber der Patch mit Abwärtskompatibilität schaltet erst bei 2.6.28 auf das neue API um...

Eben deshalb rate ich dringend davon ab im Wiki den Link zu ändern. Alte Kernel sollten mit dem offiziellen Source tun.

Zitat

Originally posted by Razorblade
@Mreimer: Kannst Du nochmal genau sagen welche Probleme Du mit dem (welchem genau) Patch hattest?

Sorry, dass ich deinen Beitrag erst so spät bemerke. Ich habe, wie schonmal geschrieben, selber keinen Netceiver und den beim Bekannten habe ich vor ca. einer Woche nach langem Kampf doch noch zum Laufen gebracht.

Was den Patch angeht: Das Problem ist, dass der neue Patch einfach davon ausgeht, dass mit Kernel 2.6.28 die Neuerungen im API gekommen sind. Der bei Slackware 12.2 verwendete Kernel 2.6.27.7 hat aber z.B. definitiv schon das neue API (dein Patch hat wunderbar funktioniert, der angepasste Patch versucht gegen das alte API zu kompilieren, welches nicht da ist). Zumindest das semaphore.h-Thema (anderer Ort der Header-Datei) ist auch schon für Kernel 2.6.26 dokumentiert. Kurz und knapp: Die bedingte Kompilierung arbeitet nicht feingranuliert genug. Wenn man es richtig machen will, müsste man die Kernel-Versionen vergleichen, um die bedingte Kompilierung so umzurüsten, dass auch wirklich da "umgeschaltet" wird, wo die entsprechenden Änderungen im Kernel auch gekommen sind.

Der Sinn nach einem Patch für ältere Kernel erschließt sich mir ohnehin nur bedingt, denn für alte Kernel sollte doch der offizielle Source tun?

Alles in allem freue ich mich auf das VDR-Plugin für den Netceiver, denn das dvbloop-Modul ist schon ein Problem für sich. Es ist nicht trivial zu kompilieren und wenn man es doch schafft, dann läuft es zumindest instabil (bei meinen Versuchen und nach zigfachem neuladen des Moduls bekam ich erst ein "Ooops" und dann kurz darauf einen Kernel Panic!).

Zitat

Originally posted by netz
Das geht auch mit einem Firefox Add-on "User Agent Switcher".

Oder gleich PrefBar

http://prefbar.mozdev.org/

Macht schon im Auslieferungszustand eine ganze Stange Erweiterungen überflüssig und lässt sich mit weiteren Buttons noch erweitern.

Zitat

Originally posted by netz
Hallo Michi,
ok, vor kurzen habe ich die Session-Cookies für mail.google.com docs.google.com und www.google.com freigeben müssen. Ansonsten funktionierte Google-Docs nicht.

Da muss sich etwas ändern.

bis dann,
Nando

http://www.heise.de/newsticker/meldung/90069

Also am besten konsequent auf Google-Dienst verzichten oder deren Einsatz zumindest meiden. Eine gute Alternativsuchmaschine suche ich schon lange, aber auf so Sachen wie "GMail" oder ähnliche Dienst lasse ich mich garnicht erst ein.

Wer Bilder einstellt, kann selber die Beschreibung editieren und dort auch einen Link einbauen. Unschön ist, dass das nur einmalig beim Einstellen geht, da die Rechte von der Gallery so gesetzt werden, dass nur noch der Admin editieren kann. Ich bin an einer Lösung dran (wird ein Plugin werden, welches die Rechte von neu eingestellten Bildern in soweit editiert, dass der einstellende User ein Schreibrecht bekommt), aber noch ist das nicht fertig.

Und um mich mal anzuschließen: Wann kommt das Netzteil und um was geht es genau dabei? Steckernetzteil oder eingebaut im Gehäuse?

Ich habe schon alles abgesucht, finde aber kein Restposten-Netzteil, welches die nötige Spitzenleistung verträgt. Zumal die 3,3V in den meisten Fällen durch einen extra Wandler aus den 5V oder 12V generiert werden müssen. Alternativ: Beide Spannungen mit DC/DC-Schaltwandlern aus 12V generieren, aber dann wird das Netzteil schon ein kleines 12V-Standgerät

Zitat

Originally posted by wbreu
naja, HowTo's zu VDR mit Ausgabe via X-server/xineliboutput gibt's genug.

Dann ist der Weg zu vdpau nicht mehr weit.

Also ist das er Anfang. Im ersten Versuch kann man es dann ja mal etwas auf der CPU ruckeln lassen. Wenn das schonmal geht, dann einfach Xine durch eine "VDPAU-fähige"-Version ersetzen und den X-Server mit dem aktuellsten Nvidia-Treiber ausstatten?

Zitat

Sorry, aber solange es keine Distri gibt, die das out-of-the-box unterstützt, wirds wohl ohne viel Handarbeit nicht gehen.

Will ich ja garnicht. Es hat sich für mich bewährt, genau zu wissen, wie was läuft. Mit etwas vorgefertigten ist man im Falle der Fälle recht hilflos. Deshalb wird das bei mir auch auf Slackware laufen, denn da kenne ich den ganzen Init-Prozess auswendig.

Zitat

Das Beispiel mit Ubuntu zeigt doch, das es nicht schwierig ist, das Aufzusetzen, allerdings fehlt es sehr oft am Feintuning (sprich richtige Paramter an der richtigen Stelle)

Und genau sowas gehört ins Wiki. Irgendwer sollte eine erste Basis dort veröffentlichen und wenn die Einstellungen sich als falsch erweisen, kann man später immer noch anpassen. Noch muss ich mich ausschließen, denn mein eigener VDR wird bis auf weiteres auf einer FF-Karte laufen. Allerdings könnte ich mir ehrlich gesagt mal einen Test-VDR leisten...

Wenn auch nur ein Kernel-Modul closed source ist, dann ist das zumindest fragwürdig. Alle Kernelmodule werden gegen die Kernel-Headers kompiliert und die sind seit eh und je unter GPL V2.

Ich kann zwar nichts zur hier diskutierten Box sagen, da ich nicht weiß, ob mittlerweile Sourcecode freigegeben wurde, und in welchem Umfang das geschehen ist. Zudem ist der angebliche "Beweis" wohl durch ein Foren-Update nicht mehr erreichbar (Error 404). Ich selber habe die Box nicht und kaufe sich auch nicht, wenn dort proprietäre Firmware laufen sollte, die nicht angepasst werden kann.

Ganz allgemein stört mich aber die Ansicht diverser Hardware-Hersteller ganz enorm. Hier wird Open Source häufig als billige Know How Quelle missbraucht. Man nimmt sich Linux, vielleicht noch ein paar Usermode-Tools (busybox, ...) und baut damit eine (kostenlose!) Basis. Alles was man aber selber macht, stellt man immer schön unter proprietäre Lizenz. Ein Minimum an Quellcode-Archiven wird meistens veröffentlicht, um der GPL "genüge zu tun". Nur wenige stellen ein Source-Paket zur Verfügung, das ohne weiteres von Grund auf eine Firmware kompilieren lässt. Bei einigen ist zumindest eine "Teil-Firmware" kompilierbar, die sich, mit aus dem Original geklauten Binärbrocken, komplettieren lässt, aber wirklich schön ist sowas nicht.

Meiner Meinung nach wird hier die Idee hinter Open Source nicht verstanden. Die Leute in der Community haben nämlich nicht viele tausend Stunden Zeit investiert, das ein Hardware-Hersteller die Kosten für die Entwicklung einer proprietären Firmware einspart.

Zitat

einlesen muste ich mich auch .

Das kann aber nicht das Ziel sein, die Infos über einen zig-seitigen Thread zu streuen. Gibt es wirklich nirgends ein Howto, bei dem man einsteigen kann?