Beiträge von musv

    Hatte auch den Fehler:

    Code
    modprobe ddbridge
    
    
    ddbridge: Unknown symbol dvb_usercopy (err 0)


    "make menuconfig" trägt - außer bei diesem einen Modul - überall 'y' ein. Richtig wäre natürlich 'm'. Wir bauen Module.


    Muß ich mir anschauen. Der Bug kommt jedenfalls von media_build upstream.


    CU
    Oliver


    Ok, das war jetzt der Hinweis, der mir die Lösung brachte.


    Hab normalerweise alles fest reincompiliert, was geht. Bei meiner älteren Version (Kernel 3.9.3) funktionierte das auch noch mit dvb-core (media_support=y).


    Dann hab ich jetzt ewig in der Kernelconfig gesucht, wo ich das im Untermenü "Multimedia Support" umstellen kann. Ging nicht. Im Untermenü konnte ich kein Sternchen durch ein 'm' ersetzen. Die Lösung war dann, den gesamten "Multimedia Support" bei "Device Drivers" als Modul zu bauen. Damit baut es auch die ganzen rc_maps für Input Lirc als Modul. Ist nicht schön. Aber funktioniert erst mal soweit (Gentoo: Kernel 3.13.6). Zumindest läuft vdr wieder.


    Ist denn bei beiden(!) Tunern ein Kabel angeschlossen?


    Nein, natürlich nicht. Ich hab ja (vorerst) nur ein Kabel. Deswegen hab ich in den Optionen auch das:

    Code
    -D 0


    drinstehen. D.h. die Idee ist, dass ich erst mal nur einen Tuner verwende und den zweiten deaktiviere.


    Geh ich recht in der Annahme, dass vdr versucht, bei den zusätzlichen Ausgabe-Plugins (xvdr und vnsiserver) den 2. Tuner anzusprechen?



    UPDATE:
    Ich doof.

    Code
    options= --grab=/home/vdr/Daten/vdr/video \
    --dirnames=,,1 \
    -l 3                <---- hier fehlt der Backslash
    -D 0


    Jetzt scheint's zu gehen.


    Vielen Dank für Deine Hilfe, 3PO. Hätt ich ohne Dich nicht hinbekommen.

    Wenn Du Dir viel Ärger ersparen willst, dann vergiss ganz einfach die originalen Kerneltreiber für DVB, denn die taugen nichts!


    Nimm die hier:


    --> Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)


    Hab ich gemacht. Mit Xineliboutput bekomm ich einen wunderbaren Empfang. Die Karte funktioniert klasse damit. Vielen Dank.


    Frage: Warum sind diese Treiber dann eigentlich nicht im offiziellen Vanilla-Kernel enthalten?


    und gut is. ;)


    Noch nicht ganz. Wie erwähnt, funktioniert Xineliboutput. Aber bei xvdr und vnsiserver hab ich Schwierigkeiten.


    Mit dem VNSIServer und XVDR krieg ich im XBMC nur ARD (vermutlich auch noch die anderen Sender des Transponders) ran. Bei ZDF und 3sat bleibt das Bild schwarz. Die übliche Fehlermeldung:
    VNSIServer


    XVDR:


    Vermutung:
    VDR startet und schaltet auf ARD. Versuch ich dann über XVDR oder VNSIServer zu connecten, blockiert da ARD vom VDR die Karte. Hab die ganzen Optionen schon durchsucht, aber so richtig ist mir noch keine Lösung ins Auge gesprungen.


    /etc/conf.d/vdr (systemd-Config)


    /etc/systemd/system/vdr.service


    /etc/vdr/setup.conf


    Hab ich da noch irgendwas vergessen?

    Guten Abend,


    da distributionsspezifische Sachen nicht in diesem Thread ausgebreitet werden sollen, hab ich mein Problem im Gentoo-Subforum gepostet.


    Bei mir wird die Karte (Cine S2, V6.5) zwar erkannt, allerdings bekomm ich kein Frontend-Device. Die yaVDR-spezifischen Pakete gibt's unter "Standard"-Gentoo logischerweise nicht. Und eine Kernelconfig bzw. einen Patch für die Unterstützung der 6.5, falls noch nicht im Kernel enthalten, hab ich leider nicht finden können.

    Hallo, seit ein paar Tagen bin ich Besitzer eine Cine S2 V6.5, die aber unter Gentoo nicht so richtig laufen will. Genauer gesagt bekomm ich kein Frontend im /dev.


    Kernelconfig (Multimedia) gentoo-sources-3.9.3:



    lspci -nn

    Code
    03:00.0 Multimedia controller [0480]: Digital Devices GmbH Octopus LE DVB adapter [dd01:0003]


    lspci -vv


    Und dmesg gibt mir dann:

    Code
    [    0.954639] Digital Devices PCIE bridge driver, Copyright (C) 2010-11 Digital Devices GmbH
    [    0.955084] DDBridge driver detected: Digital Devices PCIe bridge
    [    0.955143] HW 0001000d FW 00010004


    Entsprechend hab ich in /dev:

    Code
    ls /dev/dvb
    ls: Zugriff auf /dev/dvb nicht möglich: Datei oder Verzeichnis nicht gefunden
    
    
     la /dev/ddbridge/card0 
    crw------- 1 root root 250, 0  8. Jun 16:23 /dev/ddbridge/card0


    Was hab ich da noch vergessen? Oder wird die 6.5 noch nicht im offiziellen Kernel unterstützt? Falls nicht, wo finde ich den Patch?

    Vor dem Abschrauben und Anschrauben von Sat-Kabeln an Receiver und PC-Tuner muss man die Geräte abschalten bzw. stromlos machen, weil es sonst zu Hardware-Defekten kommen kann.


    Nun ja, diese Erkenntnis hat sich bei mir inzwischen auch irgendwo durchgesetzt, hilft mir aber jetzt konkret nicht weiter.


    Kann man die Karte irgendwie testen / analyzieren / ressetten?

    Guten Morgen,


    vor ca. 1 Monat hatte ich mal an einem anderen Sat-Receiver gebastelt. Dazu hab ich das Antennenkabel von der TV-Karte in meinem HTPC abgezogen und später wieder angesteckt. Beim Anstecken gab's dann ein kleine "Buff"-Geräusch. War vermutlich noch Strom auf dem Kabel. Zumindest empfange ich seitdem nur noch 3sat HD und an manchen Tagen mal noch ein oder zwei Spartensender (z.B. RedeRecord). Bei allen restlichen Sendern (ARD, ZDF, Private) sowohl in HD als auch in SD bekomme ich nur noch:

    Code
    frontend 0/0 timed out while tuning to channel ...


    Die Antenne funktioniert mit meinem alten Sat-Receiver problemlos. Da krieg ich alle Sender ran.


    Ich weiß noch nicht genau, wie ich das Verhalten der Karte interpretieren soll.

    • Enweder ist die Karte hinüber. Aber warum funktioniert dann noch 1 Sender?
    • Oder die Karte kann die Sender nicht umschalten.


    Kann man das Teil irgendwie zurücksetzen? Hab mal die Karte etwas näher betrachtet. Die Kondensatoren sehen alle ok aus. Es ist nichts aufgequollen, und irgendwelche Kurzschluss- / Brandspuren sind auch nicht vorhanden.


    Konfiguration:

    • TeVii S471, S2-Karte, PCIe
    • Motherboard: Zotac IONITX U-E (hat einen PCIe-Slot, der lt. Herstellersupport auch nur mit x1 geschaltet ist)
    • Gentoo 64bit, VDR-2.0, XBMC als Frontend, Kernel 3.9.3


    Wie kann ich die Karte wieder zum Umschalten der Sender bewegen?

    Seahawk1986: Erstmal ganz herzlichen Dank. Es läuft noch nicht perfekt (mehr dazu unten). Aber zumindest hab ich durch Deine Hilfe, den vdr erst mal wieder zum Leben erweckt.



    Und damit auch unmöglich. Dein startx.service steht jedem anderen Displaymanager im Weg.


    Genau das ist der Sinn der Sache. Wozu sollte ich einen grafischen Login-Manager zwischenschalten? Der HTPC startet bei mir und lädt nach dem automatischen Start von X direkt XBMC. Ein Login-Manager und ein Window-Manager wären da nur unnötige Schritte, die den Systemstart verzögern und zusätzliche Komplexität ins System bringen. Sofern ich tatsächlich mal 'ne grafische Oberfläche brauch, starte ich über einen anderen User per startx einfach Enlightenment e16 ebenfalls ohne Login-Manager.


    So, und jetzt noch meine verbleibenden Probleme:

    • Ich musste das ck-launch-session aus dem Startx-Befehl rausnehmen, da das ja sowieso in Systemd enthalten ist. Das Runterfahren klappt dadurch nicht mehr. Vermutlich hab ich keine aktive lokale Session mehr. Das muss ich aber erst noch mal nachprüfen und testen. Ein paar Links habt ihr hier ja schon gepostet.
    • Xineliboutput will sich nicht mehr verbinden - weder auf dem HTPC selbst noch von anderen Rechnern aus. Welches Plugin ist dafür zuständig? streamdev-server?


    Fehlermeldungen kann ich vermutlich erst morgen oder übermorgen posten.

    Ist jetzt zwar schon wieder etwas her. Aber ich hab mich in den vergangenen Wochen auch mal in Systemd etwas anfänglich eingearbeitet. Bei meinem HTPC hab ich die Startzeit von ca. 1 Minute auf ca. 15 Sekunden verkürzen können, um bis ins XBMC zu booten.


    X-Server
    Also erst mal muss man den X-Server definitiv nicht starten lassen. Unter sysvinit hab ich das über die /etc/inittab hingebogen. Unter Systemd ist das viel einfacher:
    /etc/systemd/system/startx.service


    Danach noch einfach ein: systemctl enable startx.service. Und der X-Server startet direkt beim Rechnerstart. Ein grafischer Login-Manager wie KDM/GDM usw. ist nicht notwendig.


    In der /home/xbmc/.xinitrc lass ich dann bei mir xbmc starten:

    Code
    exec /usr/bin/ck-launch-session /usr/bin/dbus-launch --exit-with-session xbmc-standalone


    Ob der Start der Consolekit-Session und das dbus-launch noch notwendig sind, weiß ich nicht. Aber zumindest funktioniert es. Statt xbmc kann man da natürlich auch irgendein vdr-Frontend starten lassen.


    VDR
    Ich hab mir die vorige Diskussion mal etwas durchgelesen. Ich weiß nicht, was das runvdr-Script alles macht. Bei mir läuft ein Gentoo. Und da wurde die ganze Funktionalität ins Init-Script gepackt. Entsprechend ist das Ding elende lang. Dazu gibt's noch eine Unmenge an zusätzlichen Configdateien:


    • /etc/conf.d: vdr vdr.periodic.epgscan vdr.streamdev-server vdradmin vdr.periodic.general vdr.watchdogd vdr.cd-dvd vdr.plugins vdr.xineliboutput vdr.imonlcd vdr.shutdown - Für jedes Plugin werden halt irgendwelche Environment-Variablen festgelegt.
    • /usr/share/vdr/inc: Da stehen haufenweise Funktionen, z.B. für shutdown, Plugins, Sprache
    • Beim vdr-Start: Logging-Optionen, User, unter dem der vdr-Daemon läuft, Home-Dir.
    • Dann gibt's noch einen Watchdog, der zumindest nach dem Kommentar im Config-File alle 8 Sekunden checkt, ob VDR noch läuft.


    Weiß nicht, ob man das alles umsetzen muss. Ist aber haufenweise Zeug erst mal zu analysieren.


    Probleme mit Systemd
    Systemd soll ja die hochgelobte Distributionsunabhängigkeit bringen. Unter Gentoo wird Systemd noch sehr kritisch betrachtet, was wohl durchaus auch seine Berechtigung hat. Zumindest liefern die allerwenigsten Pakete überhaupt eine Systemd-Unit mit. Ich hab mir die meisten Unit-Files von Fedora gezogen, musste die meisten aber noch anpassen. So richtig distributionsunabhängig waren sie dann doch nicht.


    Ein großes Problem war das Einbinden der Environment-Files. Im Gegensatz zur Systemd-Doku scheinen Systemd die Variablen nicht oder nicht vollständig zu expandieren. Beispiel /etc/conf.d.distccd:

    Code
    DISTCCD_OPTS=""
    DISTCCD_EXEC="/usr/bin/distccd"
    DISTCCD_PIDFILE="/var/run/distccd/distccd.pid"
    DISTCCD_OPTS="${DISTCCD_OPTS} --port 3632"
    DISTCCD_OPTS="${DISTCCD_OPTS} --log-level critical"
    DISTCCD_OPTS="${DISTCCD_OPTS} --allow 192.168.0.0/16"
    DISTCCD_OPTS="${DISTCCD_OPTS} -N 15"


    Ich hab's nicht hinbekommen, dass Systemd irgendwie die DISTCCD_OPTS-Variable zu einer vollständigen Optionskette expandiert hat. Aber selbst wenn ich die ganzen Bestandteile in eine Zeile geschrieben hab, kam Systemd in der Unit nicht damit klar. Ich hab dann sämtliche Optionen in die Unit reingeschrieben. Damit ging's dann. Damit kommen wir gleich zum nächsten Punkt:


    Config-File vs. Unit
    Soweit wie ich das von heise.de in der Einführung Teil1 und Teil2 entnehmen wollte, meint der Lennart wohl:

    • Standard-Units stehen in /usr/lib/systemd/system/
    • Eigene Units stehen in /etc/systemd/system/


    Will man die Standard-Units überschreiben, kopiert man die Standard-Unit einfach von /usr/lib nach /etc. EnvironmentFiles wären demnach nicht notwendig, da man ja seine eigene angepasste Service-Datei sowieso bereits angelegt hat.


    Ich wollte zwar auch netterweise meine ganzen Config-Dateien aus /etc/conf.d verwenden. Aber nachdem ich mit distccd und pdnsd schon gescheitert bin, bin ich langsam dazu übergegangen, alle Configdaten direkt in die Service-Files reinzuschreiben. Das wird dann damit irgendwo zu meinem Config-Verzeichnis - praktisch die Zusammenlegung von /etc/conf.d und /etc/init.d. Ich gewöhn mich mittlerweile daran.


    Ich hätte also nicht unbedingt was dagegen, wenn sämtliche VDR-Optionen übersichtlich in der vdr.service landen würden.


    Liste der installierten Dateien siehe http://pastebin.com/gb61a9s8.


    Hmm, dann ist wohl irgendwas an meiner Systemkonfiguration kaputt. Komischerweise installiert sich die 1.7.27 in die richtigen Verzeichnisse.


    Bei den Sprachen hab ich in der make.conf

    Code
    LINGUAS="de pt_BR"


    Der Rest steht in /etc/env.d/03locale. Da ist bis auf LC_ALL alles auf de_DE.utf8 gesetzt, soweit ich mich erinnere (hab hier von der Arbeit keinen Zugriff).

    Wichtig:


    XBMC-PVR Eden 11.0 -> https://github.com/pipelka/xbmc-addon-xvdr/tree/eden (eden-Branch)
    XBMC-PVR Trunk (Frodo) -> https://github.com/pipelka/xbmc-addon-xvdr (master-Branch)


    "master" mit Eden funktioniert nicht, umgekehrt auch nicht.


    Muss ich dann erstmal nachprüfen, welche Pfade in den Ebuilds stehen. XBMC ist bei mir auf alle Fälle Eden. Mit Frodo hab ich noch nicht rumgespielt.


    Was ist denn mit dem ebuild unter http://forums.gentoo.org/viewtopic-p-6545338.html#6545338 ? Das hat mit dem VDR 1.7.28 ebuild aus dem vdr-devel Overlay zumindest einfach so kompiliert. ... Wichtig: Im vdr-devel-Overlay liegt bereits ein media-plugins/vdr-vnsiserver, welches nichts anderes macht, als "is dead upstream" per eerror auszuwerfen, das ebuild muss man overriden.


    Bei mir hatte er mit dem Overlay-Package den Pfad zum Github-Repository nicht gefunden. Werd auch das bei Gelegenheit noch mal testen, ob ich das hinbekomm. Im Moment läuft's aber erstmal mit dem manuell compilierten vnsi-server.


    Btw. teste mal bitte, wohin die vdr-Dateien bei Dir für vdr-1.7.28 installiert wurden.

    Code
    equery f vdr


    Bei mir landeten die komischerweise in /usr/share/locale/. Deswegen bin ich auch noch bei 1.7.27 geblieben.

    Auch wenn es Dich nicht weiterbringt. Flash ist mittlerweile zum Glück schon so obsolet, dass viele Videos auf Youtube jetzt schon in HTML5 laufen. Der Versuch, Silverlight als Flashersatz zu etablieren, wäre ein fataler Irrweg. Nicht mal Microsoft ist sich sicher, was sie mit diesem komischen Geschöpf anfangen sollen. Mal hieß es, Silverlight wird eingestampft, es würde nur noch Sicherheitsupdates geben. Ein anders Mal wurde die Weiterentwicklung konkret erwähnt.


    Ich weiß, das hilft Dir nicht weiter. Aber wenn Sky halt auf so eine Technik setzt, solltest du nicht auf Sky setzen und denen das auch ausdrücklich sagen.

    Wenn das VNSI jetzt gepflegt wird und stabil ist, brauchts xvdr nicht und vice versa. Das ist einfach nur Irrsinn weil ein Developer sich mit (einem?) anderen in den Haaren hatte. VNSI war dann effektiv eine längere Zeit ungepflegt. Wenn FernetMenta das jetzt inklusive vdr plugin pflege übernommen hat bin ich da zuversichtlich.


    Jein, so ist das Ganze auch nicht zu sehen.


    http://forum.xbmc.org/showthread.php?tid=135164&pid=1143031#pid1143031

    Zitat von &quot;FernetMenta&quot;

    There is a reason why we keep maintaining VNSI in this branch. It's not that we like the duplicate work or say VNSI is better than XVDR. We have expected exactly those things to happen.
    Your crashlog states that it segfaults in XVDR.


    So wie ich das verstanden hab, wird schon auf die Weiterentwicklung in XBMC-PVR und damit auf Xvdr gesetzt. Nur solange das noch nicht stabil ist, bleibt eben VNSI erstmal im Hauptbranch vorhanden. Das VNSI-Plugin muss man in XBMC ja auch nicht gesondert installieren, ist ja bei der XBMC-Installation schon dabei im Gegensatz zu Xvdr.


    Ist dann halt nur Mist, dass das Ebuild im Gentoo-Overlay nicht mehr funktioniert und VNSI damit als obsolet erklärt wird. Wir haben somit derzeit die folgende Situation:


    VDR -> vdr-xvdr (funktioniert) --> XBMC-Addon-xvdr (crasht XBMC) -> XBMC-PVR (unbrauchbar)
    VDR -> vdr-vnsiserver (kein Ebuild mehr vorhanden, damit nicht installierbar) ---> VNSI-Addon inXBMC (funktioniert tadellos) -> XBMC-PVR (unbrauchbar)


    Ausgangspunkt und Endergebnis sind dasselbe. Damit ist XBMC-PVR wieder konsistent. Toll, oder?


    Ich würde das Ebuild ja selbst umschreiben. Nur leider hab ich kaum Ahnung von der Ebuildsyntax und noch weniger Ahnung von Git. Evtl. schreib ich die Typen vom vdr-devel-Overlay mal an.

    Ok, hab gestern Abend mal den vnsiserver manuell compiliert. Und was soll ich sagen, das Ding läuft schneller und zuverlässiger als das bei Xvdr jemals der Fall war.


    Ich bleib jetzt erstmal solange bei VNSI, bis XVDR mal einen gewissen Reifegrad erlangt hat.

    Vnsi ist Tod, lass die Leichen in ihren Gräbern.


    Der Nachfolger ist xvdr.


    Installier vdr-xvdr und dies ist sogar im normalen Gentoo Portage.



    Wäre schön, wenn das so wäre. Seit ca. 2 Wochen verursacht das Päckchen XBMC-Addon-xvdr einen sofortigen XBMC-Komplettabsturz. Nachzulesen auch hier. Mit anderen Worten: Seit ca. 2 Wochen verwende ich immer Xineliboutput als Notlösung, da XBMC halt für den TV-Betrieb nicht mehr funktioniert.



    Hatte da auch schon im XBMC-Forum einen Beitrag geschrieben. FernetMenta scheint wohl der aktuelle Maintainer des VNSI-Plugins zu sein. Nach seiner Auskunft ist halt XVDR noch nicht ganz ausgereift und kann diverse API-Änderungen erfahren, was dann halt genau zu diesen Inkompatibilitäten führt. Deswegen wird VNSI auch noch explizit in XBMC weitergepflegt.




    Von daher hätte ich halt gerne eine Fallback-Option, wenn Xvdr gerade mal wieder geändert wird und nichts mehr geht.




    PS: Wieso fügt das Forum hier eigentlich immer zusätzliche Leerzeilen ein?

    Hallo,




    nachdem das XBMC-Addon-xvdr XBMC direkt und zuverlässig zum Absturz bringt, dachte ich mir, könnte ich ja mal die Fallbackvariante VNSI-Server testen. Das Plugin auf XBMC-Seite ist ja bereits in XBMC integriert. Beim VDR sieht das leider anders aus.




    vdr-vnsiserver-9999-r1.ebuild:







    Und vdr-vnsiserver-9999.ebuild findet die Git-Repo nicht mehr:


    Code
    EGIT_REPO_URI="git://github.com/pipelka/vdr-plugin-vnsiserver.git"




    Den Fork findet man unter: https://github.com/FernetMenta/xbmc/tree/vnsi




    Nur leider hab ich's nicht hinbekommen, das Ebuild so zu ändern, dass ich das Plugin trotzdem irgendwie compiliert bekomm.


    /etc/portage/env/media-plugins/vdr-vnsiserver


    Code
    EGIT_REPO_URI="git://github.com/FernetMenta/xbmc.git"
    
    
    EGIT_BRANCH="vnsi"
    
    
    EGIT_PROJECT="vdr-vnsi"




    macht bei mir dann folgendes:





    Scheint so, als ob sich auch irgendwie die Verzeichnisstruktur im Plugin geändert hat. Sehr unschön das Ganze. Wie kriegt man das vnsiserver-Plugin zum Laufen?