Posts by Jasmir

Ich habe ein bisschen nach diesen beiden Begriffen gegoogled: Heißt das, IPv6 Unterstützung ist bis dato nichtmal in den VDR eingebaut?

Hallo zusammen,

ich bin bin gerade auf ein Kuriosum gestossen: Der VDR (und seine Plugins) lauschen nur auf IPv4 Ports. Und ich finde gerade nichts, wie ich das ändern kann, und habe gerade das Gefühl auf beiden Augen mächtig blind zu sein.

Ich hätte gerne einen normalen DualStack, d.h. VDR & Plugins lauschen auf IPv4 & IPv6, und die zugriffsberechtigten Netze sind in der svdrphosts.conf, streamdevhosts.conf und vnsiserver/allowed_hosts.conf als IPv4 als auch als IPv6 Netz eintragbar. Als ich das Testweise in der vnsiserver/allowed_hosts.conf versuchte, gab es direkt einen "invalid File" Error.

Bei mir sind vor allem die Handys ausschließlich per IPv6 im Heimnetz angebunden (vpn).

Die Google-Suche erbrachte zu vdr + IPv6 irgendwie nichts verwertbares . Kann mich da mal bitte jemand in die richtige Richtung schubsen?

Es war noch ein make vdr.pcals zusätzlicher Schritt direkt vor dem kompilieren nötig. Dann klappts auch mit den AddOns.

Ich bin mir nicht sicher, ob es Sinn macht in den einzelnen Makefiles danach rumzugraben. Es baut ja kein einziges Plugin, muss also was sehr zentrales sein. Evtl. hat das was mit dieser vdr.pc Geschichte zu tun, aber hier steige ich nicht durch.

Hallo zusammen,

ich wollte meinen vdr-Server gerade mal updaten, und habe hier ein Kuriosum bei dem ich nicht weiterkomme:

Es purzelt kein fertiges Plugin raus, es schlagen _alle_ beim Linken fehl:

(auch die "mitgelieferten")

*** failed plugins: epgsearch epgtableid0 hello osddemo pictures servicedemo skincurses status streamdev svdrpdemo vdrmanager vnsiserver

Bei den einzelnen Plugins steht immer sinngemäß das gleiche:

/usr/bin/ld: vnsi.o: relocation R_X86_64_PC32 against symbol `_ZTV17cPluginVNSIServer' can not be used when making a shared object; recompile with -fPIC/usr/bin/ld: final link failed: Bad valuecollect2: error: ld returned 1 exit statusMakefile:126: recipe for target 'libvdr-vnsiserver.so' failedmake[1]: *** [libvdr-vnsiserver.so] Error 1

Zusätzlich werde ich bei _jedem_ Plugin mit tonnenweise Fehlermeldungen erschlagen:

Failed to open '/usr/src/vdr/vdr-2.3.8/vdr.pc': No such file or directoryNo package '/usr/src/vdr/vdr-2.3.8/vdr.pc' found

Build Command:

make clean-plugins distclean all plugins

Ein Test mit der (bereits installieren) Version 2.3.1 brachte keine derartigen Fehler, die Plugins purzeln da fertig raus. Darum denke ich, das mein Build-System soweit in Ordnung ist.

Kann mir hier mal jemand auf die Sprünge helfen?

PS: beim 2.3.7 habe ich das gleiche Problem wie beim 2.3.8. Google spuckt da auch nichts sinnvolles aus.

Quote from Treito

1. Der Vdr kann so kein PID-Update mehr machen, aber Namen und PID's ändern zu lassen finde ich z.B. recht praktisch.

Ich muss mal nachlesen, wozu das gut ist.

Quote from Treito

2. Wenn es jemanden stört, dass der VDR in der channels.conf "rumpopelt", der kann ja die Funktion deaktivieren.

Da haste Recht. Allerdings nutze ich zwei VDRs: Einen als headless Server mit drei DVB-S Inputs im Keller, und einen mit Streamdevclient als head im Wohnzimmer. Dabei wird u.a. die Channels.conf per NFS exportiert. Um hier nicht in irgendwelche Probleme zu laufen, lasse ich das "die Datei bleibt so"-Dings lieber vom OS erledigen. Da bin ich mir dann auch relativ sicher, das ich keine Config-Geschichten im VDR vergesse. Wenn das aber ein Update diese Datei in den Orkus giesst weil es da nen Symlinks draus macht nutzt das auch nichts mehr.

Ich wollte hier nur dafür werben, das
- alle Configs (im weitestem Sinne) nach /etc/ wandern
- diese nicht durch irgendwelche Scripte geändert werden wenn irgendein nicht-maintained Etwas dran rumgeschraubt hat. (Oder noch besser, man wird vor die Wahl gestellt und bekommt einen diff angeboten)
Villeicht bin ich hier auch ein bisschen von (achtung, Oxymoron!) ein bisschen von Gentoo verwöhnt

Quote from hotzenplotz5

da aber z.b. die channels.conf von vdr auch während des betriebs überschrieben wird, hat sie meiner meinung nach in etc nix verloren.

Wie gesagt -> ist eine Streitfrage. Man kann es als ständig veränderte Datenbank sehen, oder als Config-Datei. Defacto ist es beides. Ich ändere die Rechte der beiden Dateien (channels und setup conf) gerne auf root:root, damit der VDR da nicht mehr dranne rumpopeln kann wenn es 1x läuft. (Erhöht den WAF)
Dann ists eine reine Config ohne DB-Funktion

Quote from hotzenplotz5

Code

Config-Dateien sollten niemals nach einem Update einfach so überschrieben werden

ist auch der fall !
wenn es ein template dafür gibt, sollte man das am "header" erkennen.

Die channels.conf und setup.conf unter /etc/vdr hats mir netterweise durch einen Link auf /var/lib/vdr übergebügelt

Hallo zusammen,

nach jahrelangem selbstkompllieren habe ich nun zum ersten Mal eine fertige Distribution genutzt -> yaVDR-0.4pre1. Erstmal ein grosses Lob an die "Macher", es gefällt mir sehr gut das solche Sachen wie vdpau direkt "outofbox" laufen. Auch die theoretische, einfache Upgrademöglichkeit gefällt mir sehr gut. Hier allerdings eine Bitte:

- Config-Dateien nach sollten alle unter /etc/* residieren. (Ich weiss, ist hier eine philosophie-Frage, weil sich z.Bsp, die channels.conf gerne mal ändert)
- Config-Dateien sollten niemals nach einem Update einfach so überschrieben werden. (Ich weiss, das ihr irgendein komisches Template-System eingebaut habt. Aber da steig ich nicht durch)

Hallo zusammen,

ich habe mir einen yaVDR 0.3a installiert und da sehr viel dran rumkonfiguiert. Leider bootet das Teil nicht mehr und ich bräuchte Hilfe beim debuggen:

Hardware - ZBOX HD-ID11
Distri: YaVDR 0.3a, sehr viel umkonfiguriert da es nur als "Anzeigekopf" für einen VDR-Server im Keller über streamdev-Client dienen soll.

Symtome:
Beim Boot des 2.6.32-31 Wiederherstellungsmodus sehe ich kurz "lade initrd" -> danach wieder das BIOS (er resettet also)
Beim Boot des 2.6.32-25 Wiederherstellungsmodus sehe ich den Kernel bis zum USB-Subsystem durchlaufen (vermutlich, da sehr schnell), danach wird der Bildschirm schwarz und das System hängt. Keine Reaktionen auf Strg+Alt+Enf o.ä.

Ich habe in der grub-config schon die Parameter nosplash noquiet nofb rangehangen, in der Hoffnung das ich etwas mehr sehe. Leider bleiben die Symtome so. X habe ich durch auskommentieren der "xinit"-Zeile in /etc/init/openbox hoffendlich stillgelegt, den vdr durch setzen von ENABLED=0 in /etc/default/vdr

Kann ich noch irgendwelche Einstellungen machen, das mir garantiert kein Framebuffer/X/sonst irgendwas dazwischenhaut und ich die ganze Zeit "Sicht" auf den Boot-Prozess habe? Ich bin leider bei lilo + sysvinit stehengeblieben, der Bootloader grub und das "wall-of-text" Boot-scripte + upstart Konzept sind neu für mich. Da bräuchte ich mal Tipps.

Neuer Status:

xine ohne "-r" -> gleiches Problem

Statt xine-out mal xineliboutput ausprobiert -> der seltsame Childprozess ist weg. Also ist xine-out in Verbindung mit vdr-1-7-15 kaputt.

Donkey-Kong

Meine Bemerkung mit udev ziehlt darauf, an welcher Stelle im Boot-Prozess deine "rc-local" ausgeführt wird. Ich kenne ja dein System nicht.
Grund: Dieser Link unter /dev wird vermutlich von udev bereitgestellt, und wenn das halt noch nicht vollständig gestartet ist, gibts den Link auch nicht -> Dein hdparm rennt ins Leere

Eine zweite Möglichkeit ist, das im Laufe des Boot-Prozesses bzw. auch danach aus irgendeinem Grunde nochmal auf die Festplatte zugegriffen wird. So kann ein durchaus erfolgreich abgesetzter hdparm-Befehl durch das erneute hochfahren der Platte ausgehebelt werden.

Am besten Du leitest die ausgaben mal in eine Log-Datei um (ggf auch direkt ein "hdparm -C" hinterher

G-SezZ
Kann man so machen, ist aber ziehmlich unsauber. Generell hab ich die Erfahrung gemacht, das einem diese Art von "Problemlösungen" früher oder später auf die Füsse fallen.

Naja, sobald Du die Platte irgendwie anfässt (mounten, nach Partitionen suchen, lesen/schreiben usw.) ist sie natürlich sofort wieder aktiv. Des weiteren muss auch erst udev voll aktiv sein, damit die "by-uuid"-links erstellt werden.

PS: Du hat in der rc.local auch schon auf das sudo verzichtet, oder?

Ein paar Tests:

die beiden VDR-Prozesse behindern sich in der Tat mächtig:
- ob Aufnahmen tatsächlich durchgeführ werden, liegt bei 50%
- sehr gut sieht man das Problem bei der DVD-Wiedergabe mit dem DVD-Plugin: Da sich beide VDR-Prozesse um die DVD "streiten", gehen die Wait-I/O's mächtig hoch und man hört den Laser stark auf&abfahren. Die Wiedergabe kann man da natürlich vergessen.

Noch niemand eine Idee?

Das mit /dev/disk/by-uuid/ kannte ich noch garnicht. Super, wieder was gelernt.

Donkey-Kong, dann ist das ja wirklich super einfach...

So, ich habs im BIOS mit dem manuellen Setzen der Spannung probiert (war tatsächlich auf "auto"). Allerdings werden nach wie vor alle Eingaben unter 1,1 Volt geflissentlich ignoriert. Auch unabhängig davon, welchen Spannungswert ich im BIOS fest einstelle.

*kram* *wühl*
Nekro FTW!

Ich in gerade dabei, cpupowerd-0.2.1 auf einen K9 loszulassen:
Ich kann die Voltage frei zwischen 1,1 und 1,3 Volt bewegen, solbald ich jedoch Werte unter 1,1 Volt angebe bleibt er stur auf 1,1Volt. Gibt es da irgendwelche Tricks?

biosinfo:

Following DMI entries found:
 - Mainboard vendor:   "EPoX COMPUTER CO., LTD"
 - Mainboard type:     "nForce4 DDR: 9NPA+ / 9NPA+Ultra / 9NPAJ / 9NPA Ultra Series"
 - Mainboard revision: "1.x"
 - BIOS vendor:        "Phoenix Technologies, LTD"
 - BIOS version:       "6.00 PG"
 - BIOS release:       "12/21/2005"

CPUInfo:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 43
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping        : 1
cpu MHz         : 2000.000
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good pni lahf_lm cmp_legacy
bogomips        : 4021.38
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp


processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 43
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
stepping        : 1
cpu MHz         : 2000.000
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good pni lahf_lm cmp_legacy
bogomips        : 4021.38
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

Inzwsichen habe ich auch mal einen Start ohne Plugins (bis auf xine-out) versucht, die Prozess-geschichte bleibt die gleiche.

Hat niemand eine Idee?

Dann schau Dir mal die Ausgabe von blkid an. Mit einer bekannten UUID auf dieser Platte + grep + awk sollte sich da recht schnell eine Zeile bauen lassen, die das richtige Device für hdparm rausfindet.

Die UUID zielt immer auf Dateisysteme, nicht auf Blockdevices. D.h. hdparm kann mit UUIDs nichts anfangen. Wozu brauchst Du überhaupt regelmässig hdparm?

Du kannst statt mit /dev/sdx auch einfach mit der UUID der entsprechenden Dateisysteme arbeiten.

Ein entsprechenden mount-Befehl würde dann beispielhaft so aussehen:

mount UUID="c16437ee-96f5-4331-9bb7-05803ce0cf22" /mnt

Welche UUIDs die derzeit vom System erreichbaren Dateisysteme haben, bekommste sehr einfach mit

blkid -c /dev/null

raus.