[HowTo] Debian Lenny, eTobi, EPIA M10000, FF, Xineliboutput, Nvram, mceusb [updated]

    Zitat

    Original von hummingbird_de
    Nun, unter Debian halte ich das für ein Gerücht. Debian-Way of Kernel-Build:

    Code
    #> aptitude install linux-source-2.6.18 kernel-package debianutils fakeroot libc6-dev libncurses5-dev gcc make
#> cd /usr/src
#> tar jxvf linux-source-2.6.18.tar.bz2
#> cd linux-source-2.6.18
#> cp /boot/config-2.6.18-5-k7 ./.config
#> make menuconfig => Jetzt die Optionen anpassen und speichern
#> make-kpkg --rootcmd fakeroot --append-to-version -k7-desktop --initrd kernel_image kernel_headers
#> make-kpkg clean => Damit wird wieder einiges an Plattenplatz freigegeben

    Nach einer Zeit findest Du dann unter "/usr/src" die zwei Packages (linux-[image|headers].....deb). Diese kannst Du mit "dpkg -i" installieren und auch wieder entferen. Da die Header mitgebaut wurden funktioniert auch der "module-assistant". Hier nicht vergessen den Link "/usr/src/linux" auf das entsprechende Verzeichnis zu ändern.


    Habe das jetzt mal so versucht (allerdings kernel 2.6.22.9, da das die Kernel-Version bei Ubuntu ist). Kiste scheint tadellos zu booten (bis auf lirc, aber danach schaue ich spaeter) und vdr laeuft auch. Allerdings will vdr-sxfe damit nicht laufen. Es sieht so aus als ob ein Plugin fuer MRL nicht gefunden wird:


    Hat jemand eine Idee?

    Infrastruktur: 4 Inverto Black Premium Quattro-LNBs auf Jultec JPS1702-16

    Server: Ubuntu 18.04, mit MAX-S8, als VNSI-Server

    Clients: Kodi mit Openelec auf Raspberries

    joew


    Nein, das Plugin für "MRL" fehlt nicht. MRL heißt "Media Resource Locator", sprich die Stream-Addresse die Du ansprichst (127.0.0.1:37890). Ähnlich URL: http, ftp ....


    Dein vdr-sxfe versucht den Stream des MRL zu öffnen und stellt fest, das Format versteht er nicht bzw. hat dafür kein Plugin/Codec.


    In meinem o.a. HowTo habe ich z.B. wegen eines solchen Fehlers die Pakete " xineliboutput* " per /etc/apt/preferences gepinnt. Damit verhindere ich, das er "xineliboutput-fbfe/-sxfe" vom e-Tobi Repository nimmt. Diese passte nicht zur Xine-Version von Lenny, aber die aus dem Testing/Lenny Repository schon.


    Ich vermute, das ist bei Dir das selbe, das verwendete vdr-sxfe passt nicht zu den installierten Xine-Libs ....


    Grüße
    hummingbird_de

    HowTo: APT pinning

    Zitat

    Original von hummingbird_de
    Nein, das Plugin für "MRL" fehlt nicht. MRL heißt "Media Resource Locator", sprich die Stream-Addresse die Du ansprichst (127.0.0.1:37890). Ähnlich URL: http, ftp ....


    Dein vdr-sxfe versucht den Stream des MRL zu öffnen und stellt fest, das Format versteht er nicht bzw. hat dafür kein Plugin/Codec.


    Danke fuer deine unermuedliche Hilfe! Es scheint wohl so zu sein, dass vdr auf diesem Port nicht lauscht. Aber vdr selber laeuft, und im logfile schreibt er immer wieder dass er zB channel-namen aktualisiert. Es sheint wohl die server-Seite der xineliboutput ein Problem zu haben. Es tauchen aber keine Fehlermeldungen in /var/log/messages auf. Uebrigens habe ich eben bemerkt, dass der Fehler nicht immer auftritt. Von 5 Bootvorgaengen ging es 4 mal nicht und 1 mal ging es.

    Zitat


    In meinem o.a. HowTo habe ich z.B. wegen eines solchen Fehlers die Pakete " xineliboutput* " per /etc/apt/preferences gepinnt. Damit verhindere ich, das er "xineliboutput-fbfe/-sxfe" vom e-Tobi Repository nimmt. Diese passte nicht zur Xine-Version von Lenny, aber die aus dem Testing/Lenny Repository schon.


    xineliboutput compiliere ich eh selber (und ich habe auch daran gedacht, sie nach dem Kernel-Bau neu zu compilieren), daher sollte das schon passen.
    [code]

    Infrastruktur: 4 Inverto Black Premium Quattro-LNBs auf Jultec JPS1702-16

    Server: Ubuntu 18.04, mit MAX-S8, als VNSI-Server

    Clients: Kodi mit Openelec auf Raspberries

    Zitat

    Original von joew
    Danke fuer deine unermuedliche Hilfe! Es scheint wohl so zu sein, dass vdr auf diesem Port nicht lauscht. Aber vdr selber laeuft, und im logfile schreibt er immer wieder dass er zB channel-namen aktualisiert. Es sheint wohl die server-Seite der xineliboutput ein Problem zu haben. Es tauchen aber keine Fehlermeldungen in /var/log/messages auf. Uebrigens habe ich eben bemerkt, dass der Fehler nicht immer auftritt. Von 5 Bootvorgaengen ging es 4 mal nicht und 1 mal ging es.


    Langsam komme ich der Sache naeher: /var/lib/vdr/plugin-loader.sh hat offensichtlich Probleme, die VDR-Version sauber zu erkennen. Folglich werdem beim Start keinerlei Plugins mitgestartet (weil ja die versionen nicht passen). Mache ich nach dem login ein manuelles "/etc/init.d/vdr restart" dann klappt es. Nun ist die Frage, warum mit dem neuen Kernel der Versionscheck beim booten schiefgeht, aber bei einem spaeteren Restart dann wieder funktioniert.

    Infrastruktur: 4 Inverto Black Premium Quattro-LNBs auf Jultec JPS1702-16

    Server: Ubuntu 18.04, mit MAX-S8, als VNSI-Server

    Clients: Kodi mit Openelec auf Raspberries

    Zitat

    Original von joew
    Langsam komme ich der Sache naeher: /var/lib/vdr/plugin-loader.sh hat offensichtlich Probleme, die VDR-Version sauber zu erkennen. Folglich werdem beim Start keinerlei Plugins mitgestartet (weil ja die versionen nicht passen). Mache ich nach dem login ein manuelles "/etc/init.d/vdr restart" dann klappt es. Nun ist die Frage, warum mit dem neuen Kernel der Versionscheck beim booten schiefgeht, aber bei einem spaeteren Restart dann wieder funktioniert.


    Wieder einen Schrtitt weiter: Um die Version zu ermitteln, ruft plugin-loader.sh "/usr/bin/vdr -u vdr -w 15 -V -L/usr/bin/vdr" auf. Dieser Befehl liefert folgenden Fehler:

    Code
    vdr: warning - cannot set dumpable: Invalid argument
vdr: cap_set_proc failed: Operation not permitted


    Dazu habe ich http://www.linuxtv.org/piperma…/2006-January/007201.html gefunden, aber das bringt leider auch keine Besserung.

    Infrastruktur: 4 Inverto Black Premium Quattro-LNBs auf Jultec JPS1702-16

    Server: Ubuntu 18.04, mit MAX-S8, als VNSI-Server

    Clients: Kodi mit Openelec auf Raspberries

    Zitat

    Original von hummingbird_de
    Das Problem habe ich mit Etch/Lenny auch. Du liegst mit Deiner Vermutung wohl schon ganz richtig. Die Standard Kernel von Debian sind mit "No preemption" gebaut.


    Daher teste ich gerade unter Etch einen Kernel mit dem Preemtion Model "Low latency Desktop".


    Habe jetzt auch den low-latency-kernel probiert. Das Ergebnis ist enttaeuschend: sowohl Ruckler als auch OSD-Traegheit ist schlimmer als mit dem standard (generic) kernel.


    BTW: Bei Ubuntu(gutsy) ist es relativ einfach, einen realtime-Kernel zu installieren:

    Code
    apt-get install linux-rt


    Zitat


    Der Kernel läuft jetzt ca. eine Woche und das Gerät bedient sich sehr "smooth". Kaum DXR3 typische Ruckler, OSD und Umschalten sehr schnell :)


    Ich vermute, dass das mit irgendeiner anderen Einstellung zusammenhaengt. Wie gesagt: low-latency bringt bei mir eher eine Verschlechterung :(

    Infrastruktur: 4 Inverto Black Premium Quattro-LNBs auf Jultec JPS1702-16

    Server: Ubuntu 18.04, mit MAX-S8, als VNSI-Server

    Clients: Kodi mit Openelec auf Raspberries

    Hmm, was hast Du für eine Hardware?


    Was ich schon länger vermute, aber mangels Zeit und Hardware nicht testen kann, ist das die aktuellen 2.6er Kernel auf aktuellen schnellen Prozessoren toll laufen. Aber leider auf etwas "älteren" langsameren Prozessoren irgendwie nicht mehr so dolle.


    Ist mir schon mit Ubuntu auf einem Laptop mit PIII 800MHz aufgefallen, sehr zäh. Also der Spruch mit Linux und ältere Hardware zieht meines Erachtens heute nicht mehr. Schade das es keine gute Distro mehr für Kernel 2.4 gibt .... (Und auch kein VDR ...)


    Neben dem Low Latency Desktop, habe ich natürlich auch den passenden Prozessor Support ausgewählt und der Kern rennt gut. Allerdings auf einem Sempron64 3100+ ....


    Alles in allem habe ich den Eindruck Debian Etch mit 2.6.18 ist auch auf langsameren Prozessoren gut zu gebrauchen. Jedenfalls laufen die o.a. Laptops besser als mit Ubuntu, bei gleichem Funktionsumfang ....


    Hmm, vielleicht versuche ich nochmal ein Debian Sarge mit Kernel 2.4 und Tobis Repository ....


    Grüße
    hummingbird_de

    HowTo: APT pinning

    Zitat

    Original von hummingbird_de
    Hmm, was hast Du für eine Hardware?


    Das ist ein Digitainer (von Real, 850MHz Celeron/Coppermine) mit 2 Budget-Karten. Ich verwende allerdings nicht den SCART-Ausgang (wie zB easyvdr) sondern habe gnome auf dem VGA-Ausgang. Die VDR-Ausgabe erfolgt ueber vdr-sxfe unter gnome.

    Zitat


    Ist mir schon mit Ubuntu auf einem Laptop mit PIII 800MHz aufgefallen, sehr zäh. Also der Spruch mit Linux und ältere Hardware zieht meines Erachtens heute nicht mehr. Schade das es keine gute Distro mehr für Kernel 2.4 gibt .... (Und auch kein VDR ...)


    Der Desktop laesst sich soweit fluessig bedienen. Aber vdr/lirc ist eben traege und ruckelt. So langsam habe ich den Verdacht, dass ich da noch etwas RAM reinstecken sollte:


    Auch wenn da nur wenig im swap herumgammelt, wenn das ausgerechnet zum x-server, vdr-sxfe oder lircd gehoeren sollte (wie finde ich das heraus?), so waeren die Ruckler bzw. die Traegheit verstaendlich.

    Zitat


    Neben dem Low Latency Desktop, habe ich natürlich auch den passenden Prozessor Support ausgewählt und der Kern rennt gut. Allerdings auf einem Sempron64 3100+ ....


    Nunja, wegen WAF wollte ich nicht ganz so dick auftragen. Dicker Prozessor bedeutet ja meist auch grosses Gehaeuse, viel Strom und viel Laerm :(

    Zitat


    Alles in allem habe ich den Eindruck Debian Etch mit 2.6.18 ist auch auf langsameren Prozessoren gut zu gebrauchen. Jedenfalls laufen die o.a. Laptops besser als mit Ubuntu, bei gleichem Funktionsumfang ....


    Hmm, vielleicht versuche ich nochmal ein Debian Sarge mit Kernel 2.4 und Tobis Repository ....


    Wie gesagt: ich wuerde lieber bei aktuellen Kernel/distri bleiben, um upgrade-Probleme moeglichst zu vermeiden. Habe da im Keller noch eine ctvdr-Leiche (P2, 266MHz, 1*FF+2*Budget) herumgammeln, die nicht mehr auf einen aktuellen Stand zu bringen ist. Ich will nicht noch mehr solche Leichen Ansammeln.

    Infrastruktur: 4 Inverto Black Premium Quattro-LNBs auf Jultec JPS1702-16

    Server: Ubuntu 18.04, mit MAX-S8, als VNSI-Server

    Clients: Kodi mit Openelec auf Raspberries

    joew


    Also bzgl. WAF kann ich Dich beruhigen, meine Athlon/Sempron64 (s.Sig.) gehen im VDR Betrieb dank PowerNow kaum über 30°. Welches um ca. 8° Kühler ist als mein PIII 866MHz der bis vor kurzem der Haupt-VDR war. Ich verwende immer AC CPU Cooler.


    Ich benutzte ein Desktop Gehäuse von Silverstone, das in etwa die Ausmasse eines Heimkino Receivers hat und vom Alu-Finish dazu passt. In Summe laufen 5 (!) Lüfter darin, alle Temperatur geregelt und sehr leise. Einzig ein leichtes Geräusch des Luftflusses ist zu hören (wenn man daneben sitzt). Selbst wenn ich mir einen Remux-Stream ziehe, geht die CPU Temperatur kaum über 45° und die Kiste wird kaum lauter. Eigentlich sind kleine Gehäuse durch Ihre kleinen hochdrehenden Lüfter lauter.


    Ich habe gute Erfahrung mit einem Desktop in HiFi Größe und 80mm Lüfter gemacht. Die sind leise und günstig zu bekommen. Warum darf ein VDR nicht die Größe eines Heimkino Receivers haben? Wenn das ein schönes Gehäuse ist, haben Frauen kein Problem damit. Weitere Vorteil, vernünftige Netzteile, Erweiterbarkeit, Wärmehaushalt um Klassen besser zu kontrollieren .....


    ===


    Zu Deinem Problem, warum benutzt Du Gnome und nicht ein X ohne Desktop-Manager? Das würde die einiges an Speicherverbrauch ersparen.


    Es gibt die Faustregel, wenn ein System "swapped", ist es zu spät. Ich würde meine Zeit nicht damit verschwenden welcher Prozess ausgelagert wird, Du kannst es eh nicht vernünftig beeinflussen. Sondern das System optimieren, Weg mit dem Gnome und anderem unnützen Zeugs und wenn nötig Speicher rein.


    Ich glaube ja fast, das bei Dir das Problem zwischen vdr-sxfe und xinelibout liegt. Was nutzt Du hier, tcp, udp, oder shm? Vielleicht versuchts Du mal die "lokale" Variante und/oder Softdevice:


    - Xorg und Gnome & Abhängigkeiten deinstallieren => Achtung xorg.conf sichern
    - aptitude install xorg xterm
    - "x:23:respawn:/usr/bin/X11/X -ac -dpi 100 -nolisten tcp -noreset &>/var/log/Xserver.log" => in die /etc/inittab, aber erst wenn es zu 100% funzt.
    - /etc/default/vdr um den Eintrag "export DISPLAY=:0.0" erweitern
    - Für softdevice die Datei /etc/vdr/plugins/plugin.softdevice.conf mit dem Inhalt "-vo xv:full" anlegen.
    - vdr starten


    Am Ende vom Tag könnte aber auch die Einsicht stehen, Dein Digitainer hat nicht ausreichend Leistung für die Ausgabe über Software. Mein alter VDR hatte ein FSC D1184 mit schnellem Intel i810 Chipsatz mit intergrierte XvMC fähiger Grafik und ich habe nie daran gedacht diese für Ausgabe über Softdevice zu nutzen. Das EPIA Gerät aus dem o.a. HowTo läuft aber gut.


    Was mir aber bei Test in den vergangenen Monaten auffiel, ist, das aktuelle VDR Versionen schon zu Aussetzern und Rucklern neigen. Das habe ich mit FF-/SS2-/DXR3-Karten, wie auch bei Ausgabe über xinelibout und softdevice gesehen. Prozessoren von VIA Nehemia über PIII 866MHz über AthlonXP zu Athlon/Sempron64. Speicher von 256MB bis 1GB. Sehr oft im ProSieben Bündel, ich habe dazu auch mal einen Thread geöffnet gehabt....


    Meine jetzige Variante schmales Debian & e-Tobi für amd64, Ausgabe über Softdevice/XV rennt geschmeidig und schnell = Familien-tauglich.


    Grüße
    hummingbird_de

    HowTo: APT pinning


    Du kannst nicht Zufällig mal di exorg.conf diser Konfiguartion posten? Wollte ähnliches einrichten.


    Gruß, Heinzelrumpel

    heinzelrumpel


    Öhem, wenn Du den Anfang des Threads, besser die ersten beiden Posts, beachten möchtest .... ;)


    Grüße
    hummingbird_de

    HowTo: APT pinning

    Zitat

    Original von hummingbird_de
    heinzelrumpel


    Öhem, wenn Du den Anfang des Threads, besser die ersten beiden Posts, beachten möchtest .... ;)


    Grüße
    hummingbird_de


    Yo, habe ich soeben beachtet.Danke für den Zaunpfahl.

    Hallo hummingbird_de,


    ich möchte mir einen VDR ähnlich deiner Konfiguration auf der ersten Seite aufbauen und bin entsprechend deiner Anleitung vorgegangen. Ich habe z.Z. allerdings Probleme mit der Hardwarebeschl.. Evtl. könntest du mal in meinen Thread vorbeischauen und vielleicht fällt dir dazu was ein.


    Link


    Grüße
    Torsten

    ASRock B75 Pro3-M, Intel Celeron G530, TeVii S464 V2.0, ASUS GT610-SL-1GD3-L,2 GB RAM (Kingston), Western Digital WD20EARX 2TB, CoolerMaster Silencio 550 Midi Tower, Cougar A300 (300 W)
    ya-vdr 0.5.0

    Hi,


    jaja, ich weiß, dieses Thema wird sehr oft breitgetreten, aber ich muss trotzdem nochmal nachfragen. Habe in der Tat schon mehrere Stunden damit verbracht es hin zu bekommen:


    Ich versuche ein neues VDR System auf Debian Lenny mit dem Epia ME6000 aufzusetzen eine FF und eine Budget Karte sind schon drin, spielen aber im Moment leider noch keine Rolle). Soweit so gut. Habe mich an die Anleitung von Humingbird gehalten, bleibe aber leider schon bei der MPEG2 Beschleunigung stecken.


    Überall habe ich in den Foren gelesen, dass es Out-Of-The-Box mit Debian klappen soll - aber wohl nicht bei meiner Box :(


    - Kernel 2.6.25 mit via AGP Modul.
    - Xorg sowohl mit VIA als auch mit OpenChrome Treiber konfiguriert.


    Wenn ich nun mplayer starte:


    Code
    mplayer -vo xxmc,xv -vc ffmpeg12mc dvd://


    oder auch so:


    Code
    mplayer -vo xvmc,xv -vc ffmpeg12mc dvd://


    startet zwar die DVD (libdvdcss ist installiert), aber die CPU Auslastung ist 100%. Habe sowohl den original Mplayer vom Debian Repository als auch den vom DebianMultimedia Repository genutzt.


    Meine Xorg conf sieht so aus, wie die im zweiten Betrag gepostete. Wahlweise mit "via"- bzw. "openchrome"-Treiber.



    Normalerweise wurschtel ich mich so durch und irgendwann läuft es dann, aber hier verzweifele ich gerade und würde mich über ein paar Tipps oder Hinweise freuen.


    Gruß,
    Sascha

    ... and in case I don't see you: Good morning, good afternoon and good night. (Truman Burbank - The Truman Show)

    Hallo Hummingbird_de!


    Danke für dein tolles Howto! Habe mir damit und mit einem EPIA ML8000G-Board einen neuen VDR gebaut, der meinen bisherigen (siehe Sig.) abgelöst hat.


    Eine Ergänzung hätte ich noch, und zwar eine andere ModeLine für den TV-Out

    Code
    Modeline "720x576" 27.15 720 736 880 896 576 578 579 606


    Damit hat man 50 statt 60 Hz. Funktioniert mit meinem Fernseher besser.


    mfg
    Reini

    Mein neuer VDR:
    Hardware: Intel NUC     (DN2820FYKH), 2GB RAM, DVB-T2: TT-connect CT2-4650 CI, 1TB HDD
    Software: vdr 2.1.6(yavdr), XBMC mit VNSI und VAAPI, Kernel 3.13
    Mein alter VDR:
    Hardware: Celeron 466, 512MB RAM, DVB-S: Nexus-S 2.1, DVB-T: TT-1300, 120 GB HD, DVD-Brenner, 240x128 GLCD, Mustek USV
    Software: vdr 1.6.0(e-tobi.net), graphlcd und mp3 mit span-support, Kernel 2.6.18

    reini1305


    Freut mich, das das "betagte" HowTo weiterhilft, obwohl ich einige offene Punkte noch nicht gelöst habe.


    Baue das Gerät aus dem HowTo gerade nochmals wieder auf, von der Pieke mit Debian 5.0 etc. als Streamdev-Client für meine Tochter. Bin mir noch nicht ganz sicher ob ich evtl. alternativ eine DXR3 Karte als Ausgabe-Device für xinelibout nehmen soll. Die Option "-dxr3/-aadxr3" gibt es für vdr-fbfe aber leider wie immer eher schlecht dokumentiert ...


    Ich werde Deine Modline im HowTo mit aufnehmen, vielen Dank.


    Kind regards
    hummingbird_de

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

    Zitat
    Code
    #> aptitude install xorg sterm vdr vdr-plugin-xineliboutput vdr-plugin-sysinfo xineliboutput-sxfe vdr-addon-noad vdr-burnbackgrounds vdr-enigmang-icons vdr-genindex vdr-xpmlogos vdradmin-am nvram-wakeup
#> aptitude clean


    Ich hatte das Problem beim Installieren der Software, dass kein Releasekandidat für den xineliboutput-sxfe gefunden worden ist.
    Ich habe die sources.list auf deine angepasst gehabt.
    Genauso wie die Datei preferences.


    Noch so eine kleine Frage am Rande, muss das Paket sterm nicht xterm heißen?
    Oder heißt es jetzt ganz anders hatte vorhin glaube ich was mit libsterm blabla oder so ...


    Beim manuellen Start über vdr-sxfe hatte ich dann den folgenden Fehler:

    Zitat


    xine: cannot find input plugin for MRL [xvdr:tcp://127.0.0.1:37890#nocache;demux:mpeg_block]
    [5958] [vdr-fe] fe_xine_open: xine_open("xvdr:tcp://127.0.0.1:37890#nocache;demux:mpeg_block") failed
    Error opening xvdr:tcp://127.0.0.1:37890
    [?12l[?25h[5958] [vdr-fe] unloading post plugins


    Hi,


    jepp "xterm", den Typo darfst Du behalten ;)


    kannst Du mir mal bitte die Ausgabe von

    Code
    #/> apt-cache policy xineliboutput-sxfe

    und /etc/apt/preferences & /etc/apt/sources.list posten?


    Kind regards
    hummingbird_de

    HowTo: APT pinning

    Hey ... ;)


    das ist nicht böse gemeint. :)
    War nur ein kleiner Tipp am Rande.
    Ich habe Respekt vor deinen Künsten und diesem HowTo! :gott


    Die Sachen werde ich posten sobald alles neu installiert ist ... :)
    Eine kleine Frage am Rande an den Profi:
    Ich habe die Tevii S650 und möchte den internen Receiver nutzen, wenn du da eventuell nen Tipp für mich hast, würde ich mich freuen, wenn du diesen hier http://vdr-portal.de/board/thread.php?threadid=89660 vermerken würdest.
    Danke im Vorraus. :)

    So ... :)


    Hier die Ausgabe von "apt-cache policy xineliboutput-sxfe"":


    preferences:


    sources.list:

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden