Beiträge von whocares02

    Mit diesem Problem hat das aber nichts zu tun, oder?:


    Zitat

    Card only rarely locks onto any transponder


    This is a known issue, and there is a patch available for it. First you have to get v4l-dvb source, instructions to do this can be found at How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers. Next, you need to apply this patch: Patchwork V4L/DVB: faster DVB-S lock for mantis cards using stb0899 demod


    Quelle: https://www.linuxtv.org/wiki/i…end_TT-budget_S2-3200</a>


    ...ich Frage, weil es dagegen wohl einen Patch gibt, wobei ich eigentlich keine Lust habe zusätzlich rumpatchen zu müssen - und dann auch noch bei zwei Karten, die baugleich sind und die das System auseinanderhalten soll.

    Danke! Sowas habe ich gesucht! Auch die 3200 poppt hier auf, wenn ich auf Ebay Suche. Laut LinuxTV-Wiki läuft die ebenfalls einwandfrei unter Linux. Bei 20-40€ pro Karte wäre ich dann bei etwa 40-80€ für meinen gewünschten Dual-Input. Das ist schon deutlich günstiger als 160-200€ für eine DD. Weitere Vorschläge?


    Edit: Sehe hier gerade, dass die 3200 baugleich ist zur TechniSAT Skystar HD...und die ist teilweise noch günstiger. Das gefällt mir.

    Alles klar. Daraus schließe ich mal, dass die vielen aktuellen, teureren DVB-S2-Karten mit CI-Slot für die rechtliche Grauzone sind...oder...(man weiß ja nie, was morgen erlaubt sein wird) um in Zukunft ein updatefähiges System zu haben.


    Bleibt die Frage nach Linux-Tauglichkeit. Ich will natürlich nicht bei jedem Kernel-Update den Treiber neu kompilieren müssen. Bei den TBS-Karten ist das wohl der Fall. Wie ist denn das bei den DigitalDevice-Karten? Gibt's villeicht doch was günstigeres, mit zwei Tunern, CI-Slot und Linux-Support? Grundsätzlich könnte ich ja auch einfach zwei alte PCI-Karten mit je einem Tuner verbauen. Wäre weniger elegant, aber evtl. billiger, wenn die Kernel mitmachen.

    Aaah...DigitalDevices...das sind diese Cine-S2-Dinger, die man auch noch erweitern kann. Ja, die sind mir gleich in's Auge gefallen. Das waren die "sauteuren" Karten, die aber alles können.


    Dabei crackt sich keiner etwas zusammen, das ist eine böswillige Unterstellung eines Unwissenden.


    soso :D


    Meine Frage zu CI zielt auf die Notwendigkeit eines solchen Moduls ab. Der MediaPC ist für die ganze Familie...und bestimmt kommt irgendwann die Beschwerde "ich will aber HD gucken". Geht das nun oder nicht? Jaja, öffentlich-rechtliches HD ist immer frei. Ich ging davon aus, dass man einfach in den Laden geht, Geld auf die Theke legt und so'ne Privatsender-Smartcard einfach in dieses CI-Modul steckt. Offenbar ist das wohl nicht so. Wofür ist dieses CI also dann gut? Karten und Receiver mit der Schnittstelle sind ja auch wesentlich teurer.

    Für den Media-PC werden mindestens zwei Tuner benötigt. Mehr ist natürlich besser, aber wahrscheinlich auch teurer. In dem HTPC sind noch zwei PCIe-Slots frei (eigentlich sogar drei, doch der dritte wird vom Grafikkartenlüfter verdeckt). Sollte ich die beiden DVB-C-Tuner entfernen stünden zwei PCI-Slots zur Verfügung.


    Die Antwort zu CI verwirrt mich jetzt zusätzlich: Kann CI+ doch mit CI geguckt werden? Ich dachte das wären zwei völlig unterschiedliche Standards. Ist es das, was die Leute sich da alle zusammencracken? Was ist DD? Gibt es irgendwelche Sender, die mit normalem CI geguckt werden können?


    Edit:


    Achso, der MediaPC ist ein 2,66 Ghz Intel mit 4 Kernen und einer nVidia-Grafikkarte. Irgendein Budget-Ding, das ein bißchen beschleunigen kann, aber nur einen Slot belegt (theoretisch, der Lüfter ragt trotzdem über). Ach hier: nVidia GT 440. Weiß nicht, ob das wichtig ist. Auf dem Ding Läuft Ubuntu 14.04 (Trusty) und Kodi als Frontend.

    Hallo VDR-Portal,


    in unserem Haus gibt es laute Überlegungen auf Satellit umzusteigen und nun möchte ich mich ein wenig über DVB-S2 informieren. Meine Hauptsorge: Im Wohnzimmer steht ein selbstgebauter MediaPC, in dem zwei DVB-C-Karten verbaut sind, der dann umzurüsten wäre.


    Konnte zwar per Suchmaschine schon einiges rausfinden, doch einige Fragen bleiben immernoch offen:


    -Brauche ich ein CI-Modul? Wenn ja, wofür? Die privaten HD-Sender laufen ja wohl alle nur mit diesem CI+ und das ist nicht nur indiskutabel sondern mit PCs auch inkompatibel.


    - Sind besondere Konfigurationen im Linux nötig, um CI-Karten zu nutzen?


    -Es gibt wohl auch externe Kartenleser für den USB-Anschluss die billiger wären, was ist damit?


    -Irgendwas lässt sich mit den externen Kartenlesern wohl auch Hacken/Cracken/Schwarzgucken. Was ist denn da jetzt so verboten? Die reden da alle immer um den heißen Brei...von irgendwelchen Plugins und Bibliotheken. Wozu sollte ich die suchen? Schwer zu finden ist sowas ja nie. Bestimmt muss man dafür wieder ganz viel Installieren und konfigurieren. Lohnt sich der Aufwand?


    -Sind die Cine-S2-Karten tatsächlich die beste Wahl? Die haben Doppel- und sogar Quaddro-Tuner und sind aber sauteuer. Laut VDR-Wiki werden sie vom Kernel unterstützt, andere Quellen sprechen ausschließlich von proprietären Treibern. In einem Threat dieses Forums wird behauptet, dass Closed-Source-Treiber für TBS-Karten bei jedem Kernel-Update neu kompiliert werden müssen. Wäre das mit den Cine-S2-Karten auch so?


    -Für DVB-C wurde mir in diesem Forum vor einigen Jahren die KNC-One empfohlen, die unter diversen Namen fast baugleich auch von anderen Herstellern verkauft wurde und unter Linux einwandfrei funktioniert. Gibt es was ähnliches für DVB-S2? Evtl. diese TeVii-Karten?


    Das sind so meine Fragen zum Mediapc. Mit dem ganzen Drumherum, z.B. der SAT-Anlage selbst, habe ich mich noch kaum befasst.

    Naja, danke erstmal. Bei openwrt hab ich natürlich auch einen Threat offen. Aber wie schon gesagt ist der Support da nicht so toll. Die meinen da auch, ich müsse das irgendwie umschreiben. Dass mir das da jemand coded glaub ich ehrlich gesagt nicht. Ich hab den Begriff buildroot überhaupt zum ersten mal jetzt in Verbindung mit Openwrt gehört. Wusste nicht, dass das was allgemeineres ist. Ich werd' mir die Dateien noch mal in Ruhe angucken und schauen, ob ich irgendwelche Gemeinsamkeiten mit den Dateien anderer Pakete erkennen kann.

    Ähhm...das ist doch ein Link auf git - und der Inhalt ist doch aktuell oder nicht? Wieso wissen die Entwickler von dem Patch denn nicht, dass sich das openwrt-buildroot geändert hat? Läuft der selbe Patch denn noch irgendwo anders?
    Eigentlich ist das openwrt-buildroot sogar stark vereinfacht. Für gewöhnlich läuft alles per Menü und die nötigen patches werden als .patch-dateien im Unterordner der zu kompilierenden Programme abgelegt. Wenn die Verzeichnisstruktur stimmt, erscheint ein so zu patchendes Programm sogar im Menü. Ich glaube da liegt immer noch eine Datei bei, wo dann die Menüeinträge und alle Abhängigkeiten aufgeführt sind. Also eigentlich müsste das nur irgendwie in diese Standardform, um die Automatik anzuschmeißen.

    Wie verwende ich die Dateien in dem Link? Da steht:



    Soll der Ordner wirklich so "nackig" in den Stammordner? Muss der nicht in 'nen bestimmten Unterordner? Zu Punkt 2: Die Datei package/Config.in existiert nicht. Überhaupt sind da nirgends Config.in-Dateien in den Unterordnern von /package.


    Die Unterordner sehen immer so aus wie zum Beispiel dieser hier (von e2fsprogs):



    Im Ordner .files sind immer Skripte und im Ordner .patches spezielle Anpassungen für Opoenwrt.

    Weiß jemand wie cross-compiling geht? Weil mein anderer Threat schon so lang ist, hab ich jetzt diesen hier aufgemacht. Es geht um dvb-c an einem openwrt-router. Weil es von tvheadend mittlerweile eine Version 3.9 gibt will ich die für openwrt kompilieren. Leider findet er die Bibliotheken aber nicht.



    Ganz bestimmt muss ich irgendeine Umgebungsvariable setzen. Hab schon ganz viele gesetzt:



    Weiß jemand welche ich vergessen haben könnte oder welche eventuell falsch ist? Hab noch nie cross-kompiliert. Natürlich hab ich im openwrt-Forum gefragt. Aber wie üblich antwortet da niemand. Einzig das dortige Wiki gibt hinweise wie das Buildroot benutzt wird. Hab auch alles so gemacht wie es da steht. Hab aber leider trotzdem Probleme. OpenSSL ist in diesem Buildroot vorhanden (und SSL bestimmt auch). Wenn ich die komplette Firmware mittels Menüführung kompilieren will, wird auch alles gefunden. Ich weiß halt nicht wie deren Automatik funktioniert. Ich will ja diesmal ein einziges Programm manuell kompilieren.

    Mmm..ob der Stick will oder nicht, scheint doch eher zufällig zu sein.


    Ich komm aber irgendwie nicht weiter. Zwar tut er jetzt generell öfter. Die Wiederhabe bleibt aber miserabel stotternd. Dabei ist immer der Speicher voll ausgelastet und Swap schwer in Benutzung. An der Kommandozeile regnet es Framedrop-Meldungen.


    Hat jemand 'ne Ahnung wie ich das Problem eingrenzen kann? Normal sollte der Speicher doch gar nicht beansprucht werden, weil der Mpeg-Stream doch direkt vom TV-Kabel in's Netzwerk durchgestellt wird. Wenn ich von 'nem normalen PC streame beansprucht das den Router doch auch nicht.

    Dann machste dort "who". Dann siehst Du die, was der 192.168.0.x PC denkst, eg: von welcher IP-adresse Du kommst.


    Krass, da steht echt 'ne falsche Adresse: 192.168.0.100. Hab nie sowas eingestellt.


    Machste "ifconfig -a". Wenn Du da auf dem Interface eine Maske von 255.255.255.0 siehst, dann macht dein Router routing (mit oder ohne NAT). D.h.: der routed dann zu 192.168.0.x, und UPnP multicast pakete muessten dann eenso durch spezialsoftware geroutet werden.


    Ja das steht da natürlich. Hab aber ehrlich gesagt noch nie was anderes gesehn - also auch nicht bei andern PCs. Diese Netzwerkmaske benutzt man doch sogar bei Direktverbindungen, also per Switch und ohne Router - oder irre ich mich? Heißt das denn, dass wenn ich mit dem kleinen Router verbunden bin und da ne Aufnahme runterkopiere, dass das erstmal per Funk über den großen Router läuft? Das könnte ich aber mal gar nicht brauchen. Dafür mach ich ja keinen Access-Point.


    Ich will auf jeden Fall so'n flaches Netz im Haus, wenn das geht. Mit Routing-Tabellen und so...das muss nicht unbedingt sein. Wenn dann mal irgendwann irgendwas nicht läuft, muss man sich wieder voll da reindenken, um das verändern zu können. Wie ich das jetzt einrichte, hab ich doch in 'n paar Wochen wieder vergessen.

    Hab grad wenig Zeit, deshalb nur kurze Antwort: Ich guck mir das alles auf jeden Fall an. Anschluss per Kabel ist hier im Haus leider schwierig. Deshalb tendier ich (noch ) zu dieser Pseudo-Brücken-Lösung. Hab mir gestern damit aber wieder den Zugang zum kleinen Router gekappt, weil ich der neuen Anleitung gefolgt bin und ganz am Ende die vorkonfigurierte Brücke zwischen WAN und LAN entfernt habe. Jetzt komm ich nicht mehr an das Webfrontend - weder per WLAN noch per LAN-Kabel.

    Ja...äääh...danke. Ich nehme mal an das heißt jetzt, ich hab doch irgendwie zwei Netze und gar nicht bloß eins? In meinem Setup ist also ein zusätzliches NAT drin? Powerline-Adapter haben wir hier auch mal ausprobiert. War scheißteuer und hat schlicht nicht funktioniert. Hab auch gehört das soll gar nicht gut sein wegen den Funkstörungen, die das verursacht. Das soll ähnlich schlimm sein wie Plasma-Fernseher. Da haben sich wohl schon Amateurfunker aufgeregt, weil die die teuer bezahlten Frequenzen stören können. Jedenfalls hauen die elektrosmogmäßig alle richtig was raus.


    Das hat jetzt nur alles gar nichts mit meinem Problem zu tun. Zwei Router mit gleichen Chips hab ich natürlich nicht. Openwrt ist angeblich ja das tollste und beste was man seinem Gerät verpassen kann und dieser Client-Mode lässt sich auch gegen was anderes wechseln. Ich raff das nie


    mit diesen Netzwerkbrücken. Kann ich bei dem kleinen Router nicht einfach das Client-Netz mit dem neuen WLAN-Netz bridgen und hab dann ein großen Netz wo alles drin ist?


    Ich seh grade: Für die WLAN-Verbindung zum großen Router kann ich beim kleinen Router folgende Modi wählen: Access-Point, Client, Ad-Hoc, 802.11s, Pseudo Ad-Hoc (ahdemo), Monitor, Acess Point (WDS) und Client (WDS).


    Hilft das irgendwie weiter?


    Edit:


    Ich les' mir grad die Seiten hinter Deinem Link durch. Das scheint wohl ein grundlegendes Problem zu sein, dass WLAN und LAN nicht einfach so gebridged werden können. Angeblich können das nur Broadcom-Router mit kommerzieller Firmware. Alle anderen bekommen genau die Probleme, die ich jetzt habe: Rechner sind zwar per IP erreichbar, können aber etwa in der Windows-Netzwerkumgebung nicht gefunden werden, und ähnliche Ungereimtheiten. Genau hab ich das jetzt immernoch nicht verstanden (zB:...gibt es jetzt doch Subnetze? Warum sieht man das nicht an den IPs? Sind für sowas nicht sonst Subnetzmasken da? Wieso geht das jetzt auch ohne?).
    Jedenfalls gibt es einen Workaround per relayd. Damit kann man wohl dieses Verhalten der Broadcom-Router simulieren, sodass es nur ein großes Netzwerk gibt. Ein gutes Tutorial (für openWRT) scheint mir das hier zu sein. Werd's posten, wenn ich mehr weiß.

    Oh toll, so viele Antworten. Ja zum Setup kann ich direkt auf diesen Link hier verweisen: Router als Repeater nutzen mit openwrt.
    Nach der Anleitung hab ich den kleinen nämlich eingerichtet. Da sind jetzt also zwei so genannte Schnittstellen drauf: WAN und LAN, wobei LAN eine Brücke zwischen dem neu angebotenen WLAN und dem eth0-Port an der Dose ist. Hatte in die Brücke zwischenzeitlich auch noch das Drahtlosnetzwerk zum großen Router reingenommen und gleichzeitig den dhcp abgeschaltet. Das war ganz schön Fummelei, das wieder in die Ausgangskonfiguration zu kriegen: Ich konnte ja nicht mehr einfach so verbinden und hatte vergessen wie es vorher war. Vom WLAN-Netz des großen Routers komm ich ja außerdem nicht in das Webfrontend des kleinen (hatte ich ja geschrieben). Hab dann im PC 'ne feste IP festgelegt und dann ging's aber wieder.


    Also um es kurz zu machen: Der kleine Router bietet ein WLAN an und loggt sich außerdem als Client in das bestehende WLAN ein. Wir haben hier im Haus jetzt also zwei SSIDs.
    Da fällt mir ein, ich hatte doch schon für's letzte mal ein Bild "gezeichnet", ganz vergessen, es zu posten:


    Code
    DHCP                   DHCP
    Wand------DSL-Modem/Router.(....(...(..(.((.WLAN-Router....(...(..(.(( irgendwelche Geräte (Handy, Laptop, etc)
                  	|      | 
                  	|      | 
              	PC1    PC2




    Der DHCP vom großen Router vergibt von 192.168.0.[100-150] und der DHCP des kleinen von 192.168.1.[2-50]. Die sollten sich also gar nicht stören. Hab jetzt zusätzlich in's Openwrt eine MiniUPnP genannte Software installiert. Über die Weboberfläche lässt sich da ganz viel einrichten. Nur versteh ich da bloß Bahnhof. Irgendwelche High-, External- und internal-Ports können da bestimmt werden. Ich kenn' das nur so, dass das von selbst läuft.


    Dass es zwei SSIDS gibt soll ruhig so sein. Der kleine Router soll nämlich DVB-C streamen, wie hier beschrieben. Um keine langsame Übertragung zu bekommen, sollen sich Geräte gezielt mit dem kleinen verbinden können. Letztendlich landet man immer im selben Netz. Eine Verbindung mit dem großen Router wäre aber langsamer, weil der Mpeg-Stream dann ja zweimal durch die Luft geschickt wird (kleine Dose mit DVB-Stick -> Wlan -> großer Router -> WLAN-Endgerät) und Funk ja langsamer ist als Kabel.

    Hi,
    bin nicht so fit mit Netzwerkkram deshalb bitte um schnelle Hilfe:


    Hab im Haus-Netzwerk einen großen Router mit WLAN und DSL-Modem drin, der die dhcp-Adressen vergibt und Internet bereitstellt.
    Der hat die Adresse 192.168.0.1. Jetzt soll ein zweiter (kleiner) Router im 1. Stock als WLAN Access-Point dienen und verbindet per WLAN mit
    dem großen Router. Natürlich hat der kleine auch 'nen dhcp-server, weil er ja seine WLAN-Clients mit IP-Adressen versorgen muss,
    genau wie der große. Die Adresse des kleinen ist 192.168.1.1. Beide sollten sich also nicht in die Quere kommen.


    Geräte, die sich mit dem kleinen verbinden, können in's Internet und auch Geräte des großen Routers kontaktieren.
    Leider funktioniert unpnp aber nicht über dieses System. Ein XBMC-upnp-server am großen Router ist nicht über Geräte des kleinen Routers
    auffindbar. Auch gibt's Probleme, das Webinterface des kleinen Routers (192.168.1.1) über eine WLAN-Verbindung mit dem großen Router aufzurufen.
    Erst scheint Kontakt hergestellt zu werden ("loading webinterface"...kommt eindeutig vom kleinen Router), dann aber kann die Willkommensseite
    nicht angezeigt werden. Bei Direktverbindung zum kleinen Router klappt das natürlich.


    Wie muss ich das WLAN konfigurieren, damit da jeder jeden erreichen kann und auch das unpnp funktioniert?


    Hab per google schon rausgefunden, dass zwei dhcp-server im gleichen Netzwerk eigentlich gar kein Problem sind. Geht auch nicht anders (hab's ausprobiert): Schalte ich das dhcp vom kleinen Router ab, vergibt der große keine IP-Adressen an WLAN-Clienten des kleinen (irgendwie klar, denn der große sieht ja die WLAN-Verbindungen des kleinen nicht).


    Edit:


    Hab grad rausgefunden, dass WLAN-Geräte am kleinen Router auf die Weboberfläche des großen (192.168.0.1) zugreifen können. Umgekehrt war das ja nicht möglich. Bestimmt hat das ja irgendeine Aussage. Muss ich vielleicht an den Einstellungen des großen was ändern?

    Danke. Hab mir schon gedacht, dass ich hier ein bißchen an-ecke wegen dem TVHeadend. Aber das hat nunmal die meiste Client-Software (meines Wissens). Außerdem ist das vergleichsweise einfach einzurichten. Das TVHeadend-eigene HTSP-Protokoll kann per VLC-Plugin, XBMC, Showtime und TVHClient empfangen werden. Es läuft also auf PC, PS3 und Iphone (!). Bin für eine VDR-Lösung natürlich grundsätzlich offen. Es ist allerdings nicht in den Paketquellen und würde ein erneutes Cross-Compiling nötig machen. Damit tu ich mich schwer...und eingerichtet werden muss das dann auch noch.
    Wie sieht es denn bei VDR mit Client-Software aus? Gibt's da auch 'ne Iphone-App? Die ist eigentlich das Wichtigste für mich. Leider kann dieser TVHClient nämlich nicht "zappen", also einfach die Sender durchschalten. Man muss jeden Stream aus einer Liste wählen und dann extra die Wiedergabe starten. Das Telefon als Fernseher - ganz ohne Gebühren und Datensammelei...geil!


    Jetzt im Moment läuft der Stick gerade wieder nicht. Bekomme mit dmesg dabei folgende Meldung:



    Das ist das Ende von einer sehr langen dmesg-Ausgabe. Wenn ich das richtig verstehe, gibt's da ein Problem mit der xc5000-Firmware...nur welches?
    TVHeadend spielt dabei den Stream angeblich ab - ich empfang nur auf dem PC nichts. Dabei geht im Router auch die Speichernutzung hoch. Was jetzt die Fehlermeldung heißt, verrät Google mir nicht. "urb" könnte aber wohl was mit USB zu tun haben. Ich habe den Stick ausgestöpselt und in einen anderen Port des Hubs wieder eingestöpselt. Vielleicht hat es etwas damit zu tun?!


    Edit:


    Nee...doch nicht. Hab neu gebootet und die Ausgabe bleibt die selbe.


    Ich hatte noch vergessen zu erwähnen, dass ich vor diesem Ausfall noch das hier ausprobiert habe: Angeblich gibt'S bei TVHeadend ein bekanntes Puffer-Problem, das sich per Netzwerk(!)-Einstellung lösen lässt:

    Weil der Router nur 32 MB RAM hat, hab ich die Zahlen mal auf 10MB (also 10485760) geändert.


    Edit:


    Hab grad mal

    Code
    modprobe videobuf-dvb

    eingegeben und siehe da: TV funktioniert plötzlich wieder. Gut möglich, dass ich das auch vorher aufgerufen hatte. Hab soviele Module schon durchprobiert, da war das bestimmt schon 'n paar mal dabei. Natürlich ist das Fernsehn immernoch sehr ruckelig - auch mit dem neuen /etc/sysctl.conf-Eintrag. Kann mir vielleicht jetzt aber doch jemand weiterhelfen. Gibt's da vielleicht noch mehr so Wundermodule?

    Sooo, bin um Einiges weitergekommen.


    Dass mit dem Cross-Compiling war ziemlicher Blödsinn, weil es fast unmöglich ist, die Zielgröße für das Flash-Image auf unter 4MB zu drücken. Selbst wenn man alles Unwichtige abschaltet und als Modul auslagert (für später auf'n Stick) kam ich von 9MB auf gerade mal 8MB. Einen Vorteil hatte das Cross-Compiling aber: Ich hab ein neues TVHeadend3.4-Paket bekommen, das später noch nützlich wurde. Anders als Kernel-Pakete sind normale Software-Pakete nämlich nicht vom Kernel abhängig.



    Erstmal müssen alle Dateien von hier nach

    Zitat

    /lib/modules/3.10.49

    Das geht nur, wenn man vorher extroot installiert hat, also das Dateisystems eines Sticks über dem Root-Dateisystem liegt. Der Speicherplatz des internen Flash-Chips ist mit 4MB nämlich viel zu klein. Extroot wird mit einem einfachen Befehl in der

    Zitat

    /etc/config/fstab

    eingeschaltet. Wie das geht, steht genau im Wiki: Hier und hier (konkret am Beispiel). Man muss irgendwie block-mount installieren und einen ganz "normalen" Eintrag in die fstab machen.


    Jedenfalls musste danach noch die Firmware des DVB-C-Sticks (2 Dateien) in

    Zitat

    /lib/firmware

    kopiert werden (gibt's zum Download im Internet). Außerdem sicherheitshalber alles was mit v4l zu tun hat. v4l selbst gibt's nicht in den Paketquellen, aber einige Tools und Treiber.
    Die beiden angeblich wichtigen Kernel-Pakete

    Zitat

    kmod-video-core und kmod-input-core

    sind zwar in den Paketquellen, aber dummerweise inkompatibel mit dem offiziellen Openwrt Barrier-Braker. Da haben die Entwickler wohl Mist gebaut. Normalerweise werden bei jedem Cross-Compile-Vorgang auch alle passenden Kernelmodule rausgehauen. Die passen dann immer nur zu dem Kernel von genau diesem Cross-Compile-Vorgang. Deshalb kann man die auch nicht selbst nach-kompilieren. Bislang bin ich aber ohne diese beiden Module ausgekommen.


    Die Kernel-Module, die per modprobe für den TVB-C-Stick geladen werden mussten waren:

    Zitat

    drxk.ko
    xc5000.ko
    em28xx-dvb

    Beim Laden werden automatisch auch alle anderen Pakete geladen, die benötigt werden. Deshalb musste der ganze Ordner media von der Webseite zuvor heruntergeladen werden.



    Jetzt kommt der spannende Teil: TVHeadend liegt mir hier in drei Versionen vor, die alle drei schlimme Bugs haben, aber in Kombination funktionieren:


    1.) TVHeadend 3.2: Keine Ahnung wo ich das her habe. Das kann jedenfalls die Muxes finden. Das Programm verfügt über Listen ganz vieler Kabelanbieter auf der ganzen Welt. In Version 3.4 ist diese Funktion defekt. Leider versagt Version 3.2 aber beim Suchen nach Services und Sendern. Außerdem hat es viele Fehler bei der Darstellung der Weboberfläche. Deshalb muss es nach dem Finden aller Muxes mit

    Zitat

    opkg remove tvheadend

    wieder entfernt werden. Die Einstellungen unter

    Zitat

    /root/.hts

    werden dadurch nicht mitgelöscht.


    Dann kommt die selbst-kompilierte 3.4er-Version drauf. Anders als bei der offiziellen 3.4er-version fehlt dort nicht der Tab "DVB-Inputs" in den Einstellungen der Weboberfläche. Damit lassen sich jetzt also Services und Sender finden. Das Finden der Sender wird nach dem Suchdurchlauf für die Services mit dem Button "Map DVB Services to channels..." manuell angestoßen. Tja und dann gibt's auch irgendwann TV.


    Wichtig ist noch zu erwähnen, dass die Datei

    Zitat

    /etc/init.d/tvheadend

    abgeändert werden muss. TVHeadend kann unter openwrt keinen Benutzer hts anlegen, weil es nur einen Nutzer gibt, nämlich root. Folglich lautet die Zeile zum Starten des TV-Headend-Service:

    Zitat

    tvheadend -f -u root -g root

    -f lädt TVHeadend im Hintergrund (ein sogenannter "fork"), -u ist der Nutzername und -g der Gruppennname. Auch die Option -c /etc/tvheadend, die in der Voreinstellung hinter dem Befehl hängt, kann weg. Schließlich sollen die Einstellungen ganz normal aus dem Nutzerordner (bei openwrt also /root/) gelesen (und auch dorthin geschrieben) werden.


    Auch wichtig ist die Einrichtung einer Swap-Partition, weil der Speicher mit 32MB schlicht zu klein ist. Dafür muss das Paket zram-swap installiert werden.

    Zitat

    swapon /dev/sdaXY

    schaltet swap manuell ein. Automamtisch soll es wohl mit /etc/config/fstab gehen. Das hat bei mir aber nicht geklappt. Daher habe ich dem Upstart-Script über die Luci-Oberfläche von Openwrt einfach den swapon-Befehl hinzugefügt.


    Mein Problem jetzt: Die Performance ist unbefriedigend. Grund ist wahrscheinlich die Speicherauslastung. Die CPU-Werte sind während der TV-Wiedergabe in Ordnung. Hab Swappiness schon auf 90 gestellt (/proc/sys/vm/swappiness ...glaub ich) und einen schnellen USB-Stick benutzt. Außerdem hab ich einen Hub angeschlossen, der 'ne externe Stromversorgung hat.


    Trotzdem hakt das Bild sehr und TVHeadend gibt sehr viele Fehlermeldungen raus:

    Zitat

    Continuity counter error

    erscheint unzählige male im Log. Die Speicherauslastung liegt laut Luci-Weboberfläche dabei immer bei über 200%. Mit

    Zitat

    free -m

    kann ich sehen, dass auch fleißig Swap benutzt wird. Der Stick hat Schreibraten zwischen 6MB/s und 20MB/s - das sollte also für ein flüssiges Bild reichen. Hab's mit rsync getestet.


    Hat jemand Ideen, wie ich die Performance weiter steigern kann? Hintergrund-Sender-Suche und ähnliches hab ich schon abgeschaltet.


    Außerdem funktioniert das automatische Laden der drei Kernel-Module beim Booten nicht. Nur zwei werden geladen. Das dritte muss ich immer manuell nachladen und danach TVHeadend neu starten, weil es den Stick sonst nicht findet. Hab's mit

    Zitat

    modprobe em28xx-dvb

    im Upstart-Script unter Luci versucht. Leider kein Erfolg. Auch hab ich den Bugfix angewandt, der hier zu finden ist. Eigentlich gilt das Problem schon als behoben, doch vor der aktuellen Openwrt-Version 14.07, wurde bekannt, dass der Pfad für die Kernel-Module in

    Zitat

    /lib/functions.sh

    falsch ist (auf der verlinkten Seite befindet sich functions.sh noch in einem anderen Ordner). Durch den Bugfix laden jetzt die beiden anderen Module automatisch, das dritte fehlt aber immernoch :(