Beiträge von real_schorsch

    Ah, da isser ja wieder, unser lieber Himmelskörper. Hab ihn schon vermisst. Wie liebevoll er sich doch um alles kümmert, was mit RMM zu tun hat... Und selbst wenn das Thema gar nichts mit RMM zu tun hat, sorgt er oft für kostenlose Werbung, soviel könnte ich hier gar nicht posten. Und damit man ihn besser versteht, baut er auch noch immer so hypsche Smilies in seine kompetenten Posts ein.


    @Mods:
    Er sollte dringend im Forum einen besonderen Status geniessen, gebt ihm doch bitte ein eigenes Subtopic, wo es nur um RMM geht.

    Da ein kaputter TS den h264-Decoder gern langfristig (bis zum Re-Zap) verwirrt, ist im hdplayer was drin, das bei TS-Continuity-Fehlern einen Decoder-Reset auslöst. Wenn der Empfang halbwegs vernünftig ist, sollte das aber eigentlich nur selten auftauchen.

    > Wichtig wäre mir ein HighCap-Kondensator als Spannungsquelle


    Sehr seltsame Anforderung. Diese Kondensatoren sind nicht für langfristige Energiespeicherung geeignet und werden immer dann leer sein, wenn du das Gerät mal brauchst...


    Kauf ein normales Multimeter und steck da eine GUTE Alkalimanganbatterie rein. Sowas hält bei Nicht-Benutzung >5 Jahre.

    > aber beim PID Wechsel legt er eine neue Datei an


    "er" ist der vdr, der NetCeiver macht nur, was ihm gesagt wird ;)


    > Machen die das bei Sky eigentlich absichtlich?


    Ja. Der Rest ist der automatische Kanalupdate vom vdr, kann man sicher abschalten... Beim Wechsel der PIDs oder SIDs bekommt das CAM eine neue CA-PMT, das verursacht die Klötzchen.


    BTW: Dass der Realtek das Problem ist, kann ich nicht nachvollziehen. In der Reelbox ist auch der 8111 (PCIe) drinnen, die PCI-Version habe ich auch schon öfter benutzt, da fehlt sich nix. Geht sogar mit dem ollen 8139C+ (100Mbit) in meinem Notebook...

    Zitat

    Originally posted by Mreimer
    AFAIK bauen die von Reel wegen der etwas starren Deviceverwaltung eine Abstraktionsebene zwischen VDR und Netceiver. Im mcli-Plugin kann Reel die Devices dann dynamisch verwalten und auf die statisch im VDR registrierten Devices mappen.


    Das mcli-PI macht *genau* das, was das dynamite-Ding macht, aber noch etwas mehr. Es reserviert eine bestimmte Anzahl von Devices und ändert deren Eigenschaften (verfügbare Satelliten, S/C/T) on-demand. "Echte" DVB-Devices könnte man da auch mit wenig Änderungen anflanschen, von daher war das durchaus die Neuerfindung des Rades ;) Es gibt zB. aber auch noch Timeouts, damit Tuner nicht von unwichtigen Services (osdteletext etc) blockiert werden.

    Ach je, wieder mal device_create. Diese Funktion ist in nahezu jeder Kernelversion irgendwie anders, daher sind da im hdshm-Code in dem Bereich auch die meisten #ifdefs. Da wir nicht jede Kernelversion durchprobieren, kann es schon sein, dass da eine mit den falschen ifdefs läuft. Meistens fällt das wegen zuwenig/zuviel Parametern gleich beim Compilieren auf die Nase, aber da wohl nicht. 2.6.26 ist auch AFAIK auch kein typischer Distri-Kernel. Kannst du den Kernel updaten oder ist das schmerzhaft?

    Hast du das hdshm-Modul nicht geladen?


    Aber warum es jetzt geht, verstehe ich trotzdem nicht. Denn


    > Decypher PCI BAR1: d0000000 (jetzt)
    vs.
    > Decypher PCI BAR1: 50000000 (vorher)


    kann eigentlich durchs Modul nicht passieren. Da war irgendein (Re)Boot oder andere Veränderungen dazwischen. Schau nochmal, ob es funktioniert, wenn du den Rechner wirklich hart ausschaltest und wieder einschaltest.

    > sieht eigentlich gut aus


    Öh, nein. disabled ist ganz schlecht, und die Basisadresse für den zweiten Bereich sieht eigentlich auch irgendwie komisch aus. Normalerweise sollte die etwas grösser sein und in der Gegend wie die Bereiche der anderen Karten liegen.


    Wenn sich beim Booten an den LEDs nichts rührt, kann das auch von zu geringer Spannung auf der 3.3V-Leitung herkommen. Der Resetbaustein auf der HDE hat seine Schwelle bei ~3.1V. Wenn das NT schon zuwenig liefert und noch die diversen Spannungsabfälle am Mainboard und der HDE dazukommen, könnte das unterschritten werden. Dann komt die HDE nie aus dem Reset, was anhand deiner LED-Beschreibung wohl der Fall ist. Der "zu langsame" Reset mit dem C-Tausch würde beim EInschalten des MBs trotzdem die LEDs abwechseln lassen.


    Die 3.3V der HDE selber sind zB. gut an folgendem Ort zu finden: Auf der Bestückungseite, oberhalb des Quarzes sind Löcher für einen 2*7poligen Stecker. Der linke obere Pin ist quadratisch, auf dem Pin drunter sind die 3.3V. Falls möglich, miss das bitte mal nach.

    Der C-Tausch ist nur notwendig, wenn die Karte nach dem Booten nicht korrekt erkannt wurde. Nachdem aber scheinbar eine PCI-Basisadresse da ist, ist es das wohl nicht. Poste trotzdem mal den Ausgabeteil von lspci -v mit der HDE (Micronas/Vendor 1905). Was machen die LEDs auf der Karte beim Booten?

    Auch nett, aber "Alternative" würde ich das im vdr-Umfeld nicht nennen. Insb. der Teil mit "...und somit das gleichzeitige Streamen von zwei verschiedenen Sendern ermöglichen" wäre für einen vdr immer noch mager ;) Im Prinzip wird das "nur" ein kleiner SOC sein (vermutlich irgendwas aus dem STB-Umfeld, CX25*, ST7* oder so), der eh schon TS-Eingänge, interne PID-Filter und Ethernet hat. Dann noch etwas Streaming-SW dazu. Aufgrund der doch recht begrenzten CPU und des fast immer recht "fern" angebundenen Netzwerks geht dann halt nicht mehr, als 1-2 Sender zu streamen. Ähnliche Ideen hatten wir am Anfang der NetCeiver-Entwicklung Ende 2006 auch schon, haben sie dann aber verworfen, weil man damit dem vdr nicht vernünftig vorgaukeln kann, dass er einen vollständigen lokalen Tuner hätte, wo er nach Belieben PIDs an und ausknipsen kann.


    Aber die Sache mit der Windows/Mac-Anwendung hat natürlich einen gewissen Charme ;)