Beiträge von TheAlamo

    sicher, dass die Nova auf dem Server richtig läuft, was die Treiber angeht?
    Ist nur so ein Verdacht von mir, weil der vdr ja wahrscheinlich die Nova zum Streamen benutzt. Das hatte ich mal, da stimmte was nicht mit den Treibern, da hatte die Nova zwar ein Lock beim Tunen, EPG kam glaubich auch, aber weder Bild noch Ton.


    Hast Du das schon mal mit parallelen Aufnahmen mit unterschiedlichen Transpondern auf dem Server getestet?

    Unn?


    Schon mal nachgesehen, ob es sowas wie /dev/lirc/0 oder /dev/lirc0 gibt?
    Falls ja, dann müsste es doch im linvdr eine Stelle geben, wo dem lircd erzählt wird, dass dieses device benutzt werden soll. Und überhaupt, ist lirc_mceusb das einzige lirc-Modul, welches geladen wird? Schonmal kontrolliert? Ich mein, falls nicht, dann könnte es ja auch mehrere lirc-devices geben.

    Zitat

    Original von LinTV-Fan
    Hat mir jetzt noch jemand einen Tipp wie ich den USB Empfänger ...


    Naja, da waren sie wieder, meine drei Probleme ...


    Normalerweise hätte ich gesagt, da brauchst Du nur lirc mit der Option "--with-driver=mceusb" zu konfigurieren und neu zu übersetzen, dann entsteht das Modul lirc_mceusb. Dieses wird dann beim Booten geladen, die quick-and-dirty Methode wäre wohl, vor dem Start vom lircd (der ja wahrscheinlich aus irgendeinem script heraus erfolgt) einen "modprobe lirc_mceusb" abzusetzen.


    Aber wir befinden uns hier im LinVDR-Forum. Eine fertige Distri, da wird normalerweise nix neu übersetzt - es sei denn man bohrt die Distri entsprechend auf. Was weiss ich denn, was die "Erzeuger" dieser Distribution sich gedacht haben, als sie lirc mit eingebaut haben. Vielleicht haben sie obige Option gesetzt, vielleicht auch nicht. Wie soll ich da weiterhelfen?

    Oh, je, das ist schon eine zeit her, dass ich diese Geschichte eingerichtet habe - ob ich's nochmal zusammen kriege?


    Also, das ist ne Gentoo-Kiste noch mit 2.4er Kernel.


    Lirc ist installiert mit Version 0.7.0pre7.


    Das Laden von dem mceusb habe ich in das init-script vom lircd mit hinein geklimpert:


    wobei LIRCD_OPTS="-d /dev/lirc/0" ist.


    Die Fernbedienung ist - wie gesagt - nicht genau die gleiche. Die lircd.conf schaut so aus:


    die remote.conf dazu:


    Die FB schaut so aus (das ist der erstbeste Link im Netz, den ich gefunden habe, hoffentlich funktioniert er) - allerdings hat meine den garstigen MICROS~1-Schriftzug nicht: http://ruel.net/pc/pvrpix/mce-remote-control.jpg

    Zitat

    Original von SyncMaster
    Na ja, es wäre auch schön wenn mir mal jemand wirklich was sinnvolles antworten könnte.

    Hm, tja, ich kann nur soviel sagen, dass ich hier so eine ähnliche MCE-Fernbedienung zusammen mit passendem USB-Empfänger am laufen habe. Geht problemlos, bei LIRC gibts so ein Modul, heisst mceusb.

    Hi,


    mal ein kleiner Zwischenbericht:
    xine-0.7.4-netzwerk scheint soweit zu funktionieren. Allerdings hatte ich ein Problem mit der xine-lib. Nachdem ich sie installiert hatte, ging der zweite Aufruf von xine schief mit

    Code
    Dies ist xine (X11 gui) - Ein freier Video-Player v0.99.3cvs.
    (c) 2000-2004 Das xine Team.
    Inconsistency detected by ld.so: ../sysdeps/generic/dl-tls.c: 75: _dl_next_tls_modid: Assertion `result <= _rtld_local._dl_tls_max_dtv_idx' failed!

    Das liess sich reproduzieren - make uninstall, make clean, autogen, make, make install. xine liess sich immer nur einmal sauber aufrufen. Selbst nach einem reboot war dann Ende Gelände.
    Dann fiel mir ein, dass es bei einer der Vorversionen Probleme mit opengl gegeben hat.
    --disable-opengl hat den Fehler beseitigt. Jetzt läufts.


    Dummerweise habe ich jetzt ein Hardware-Problem mit meinem vdr-Server, sodass weiteres Testen erstmal ausfällt.

    no_expert


    Leider schreibst Du nichts darüber, was für Clients in Deinem Netz hängen. Falls da auch Windoofs-Maschinen dabei sind, liegt der Verdacht nahe, dass diese Deinen Server zur Einwahl veranlassen.


    Die schicken doch ab und zu so Suchanfragen nach irgendwelchen Domain- oder Workgroupservern raus.


    Edit: achso, nein, vergiss es, Du schreibst ja "auch wenn kein Client läuft".

    Zitat

    Original von gon
    Ich weiss nicht ob es interessiert, aber seit ich an meine Lorenzen eine Kathrein DVB-T Antenne angeschlossen habe, bekomme ich keine ARM- Crashes noch sonstige Fehler mehr! Hat zwar nichts mit den Patches hier zu tun, aber vielleicht hilfts jemand.


    Steffen

    Was denn für ein Modell genau? Habe hier auch so meine Probleme mit der Lorenzen.


    Edit: Die DVB-T-Indoor-Antenne BZD 30?

    Zitat

    Original von neumann2k
    Da ich diesen Check wieder entfernt habe, schaltet VDR jetzt ganz schnell um (weil er nicht wartet, bis das FE einen Lock hat) und nach einer Zeit sollte dann auch was auf dem Bildschirm kommen. Je nach Karte mal langsamer mal schneller.


    Ja, aber, aber, aber - Huch, das verwirrt mich jetzt doch. Diese ganze Sache, mit dem Warten auf das Lock, die ist doch erst mit vdr Vers. 1.3.5 oder so reingekommen, und zwar, um die UPT Errors zu vermeiden.
    Wenn ich es richtig verstanden habe, vertragen die DVB-S es nicht, wenn der vdr versucht, pid-Filter zu setzen, wenn das Frontend noch kein Lock hat.
    Und genau diese Mimik wird jetzt wieder abgeschaltet durch den Patch. Das würde ja bedeuten, dass jemand, der eine Kombination aus DVB-S und DVB-T hat, sich wieder potentielle Probleme auf der Sat-Seite einhandelt (wahrscheinlich bei schlechten Empangsbedingungen).

    Hi,


    hm, wenn ich das richtig verstehe, macht doch hotplug sowieso nichts Richtiges mehr, oder?


    Code
    start () {
            # just verify that people build their kernel with hotplug support.
            if [ ! -f /proc/sys/kernel/hotplug ] ; then
                    eerror "CONFIG_HOTPLUG not enabled for this kernel!"
                    return 1
            fi
    }

    /etc/init.d/hotplug

    So, dann brauchen wir natürlich ein laufendes Oxyl in der Version 2.0.
    Wie das geht, entnehme man bitte den Seiten auf www.oxyl.de .


    Wenn das alles sauber läuft - was mitunter Schweiss und Tränen kosten könnte - fügen wir unser kleines Plugin in das plugins-Verzeichnis der oxylbox ein:


    oxyl_vdr.tar


    Wie es bei der oxylbox üblich ist, kann man das Ding über einen normalen Webbrowser konfigurieren. Es wird die IP des Servers eingetragen, der SVDRP-Port (2001) und der Streaming-Port (3000).


    Ich stelle es jedem frei, dieses Stückchen Software weiter zu entwickeln, auf seine Bedürfnisse anzupassen, wasauchimmer ...


    Have fun with it, but use it at your own risk.

    sooo,


    als näxtes müssen wir ein bissel das streamdev-plugin patchen. Keine Angst, das ist nicht schlimm, tut nicht weh, macht auch nix kaputt und hat schon viele Versionen des plugins überlebt.


    in dem File common.c fügen wir ein:

    Code
    cChannel *ChannelFromString(char *String) {
            cChannel *channel = NULL;
    
    
            // Cut everything after a dot.mpg
            char *dot = strstr(String, ".mpg");
            if (dot != NULL) *dot = '\0';
    
    
            if (isnumber(String)) {


    also in der Funktion ChannelFromString einfach die drei Zeilen (beginnend mit //Cut everything...) einfügen.


    Dann den ganzen Schlamassel neu maken.


    später kommt dann das Plugin für Oxyl ...