Posts by hsteinhaus

    Nachdem meine klassischen VDRs nun seit Jahren nahezu ohne Mucken liefen, kommen sie so langsam in den Bereich, wo die Hardware offensichlich ihr Lebensende ankündigt: Netzteil-Tode, CMOS-Batterien, Lüfterschaden und letztens ein totes (Atom-) Mainboard. Nun schaue ich mich gerade nach Alternativen um und habe in dem Zusammenhang gerade mal MLD auf einem Raspi 3 ausprobiert - ziemlich cool was da inzwischen geht und schick ist es auch noch...

    Eine Sache gibt mir aber zu denken: es scheint, als würden alle Partitionen von der Micro-SD RW-gemounted - oder sehe ich das falsch? Falls ja, gibts da (einfache) Abhilfe? Denn meine drei sonstigen im Haus verteilten Raspis haben über die Jahre gezeigt, dass man für Geld keine SD-Karte kaufen kann, die in ein, zwei, drei Jahren nicht den sicheren Schreibtod stirbt...

    Hier ein Beispiel für einen Ansatz im Debian-Umfeld: http://wiki.glidernet.org/wiki:prevent-sd-card-corruption

    Edit: ich beziehe mich natürlich nur auf das OS, nicht auf eventuelle Aufnahmen. Die landen bei mir sowieso nur auf dem NAS

    Das das böse Plugin mit mcli nicht geht, m.E. liegt weder am Netceiver noch am mcli-Plugn. Der VDR bietet eine saubere Schnittstelle, um alles mögliche mit dem DVB-Gerät zu machen. Das böse Plugin (und einige andere auch) umgeht diese Schnittstelle und macht stattdessen wilde ioctls auf irgendwelche /dev/dvb/-Dateien. Portables und sauberes Programmieren funktioniert jedenfalls anders. Wie dem auch sei, Abhilfe ist hier sicher mit wenig Aufwand machbar. Es muss sich halt mal jemand hinsetzen und die ganzen ioctls auf die cDevice-Methoden umbiegen. Hier sind aber die Nutzer des bösen Plugins gefragt..

    Zum Netceiver selbst: einer meiner Netceiver hat gerade eine Uptime von 407 Tagen, und vor gut einem Jahr hat es hier heftig gewittert mit folgendem Stromausfall. Ich möchte den Streamdev-Server-VDR mit eingebauten Karten sehen, der nur 1% davon ohne Ausfall, Neustart, Segfault oder ählichem schafft.

    Bei den Umschaltzeiten bin ich als Nutzer in einem großen System mit vielen Clients wahrscheinlich etwas verwöhnt, da die Standard-Transponder ohne Retuning quasi immer laufen. So sehe ich üblicherweise eine Umschaltzeit von deutlich unter 1s, zumindest seit ich softhddevice einsetze. Beim echten Retuning dauert es auch mal 2 Sekunden, länger habe ich soweit ich mich erinnere noch nie gehabt (mcli-Plugin, yavdr 0.5). Richtig langsames Tuning ist nach meiner Erfahrung ein direkter Hinweis auf eine falsch konfigurierte maximale Tunerzahl in den Optionen des Plugins.

    Grüße
    Holger

    Habe gerade mal etwas mit dem IPTV-Plugin herumgespielt. Dabei habe ich festgestellt, dass dieses mit minimalen Konfigurationsaufwand in der Lage ist, Streams vom Netceiver zu empfangen. Da ich hier im Forum noch nichts dazu gefunden habe, hier mal ein kleines Kochrezept, vielleicht hilft es ja dem einen oder anderen Netceiver-User.

    Zutaten:
    - ein Netceiver ;)
    - das Tool netcv2dvbip-static (Bestandteil der mcli-Plugin-Sourcen, kompilieren gemäß README)
    - eine aktuelle channels.conf
    - ein VDR-Client mit angepasster channels.conf

    Zunächst starten wir auf einem beliebigen Rechner im Netz mit Zugriff auf das Netceiver-VLAN (bei mir eth0) und auf das Netz der VDR-Clients (eth0.3) das Tool netcv2dvbip.

    Code
    ~/netcv2dvbip-static -e -b eth0.3 -i eth0 -c /etc/vdr/channels.conf

    Das Programm spuckt eine Liste der erkannten Kanaleinträge aus, zusammen mit je einer IPV4-Multicastadresse.

    Aus dieser Adresse und dem Eintrag des gewünschten Kanals schmieden wir jetzt einen neuen channels.conf-Eintrag:

    Code
    NC_Sat1;IPTV:20:S=1|P=0|F=UDP|U=239.255.0.1|A=12345:I:22000:255=2:256=deu@3;259=deu@106:32:0:17500:1:1107:0
    NC_RTL2;IPTV:30:S=1|P=0|F=UDP|U=239.255.0.2|A=12345:I:27500:166=2:128=deu@3:68:0:12020:1:1089:0
    NC_ProSieben;IPTV:40:S=1|P=0|F=UDP|U=239.255.0.3|A=12345:I:22000:511=2:512=deu@3;515=deu@106:33:0:17501:1:1107:0

    Die Zeilen enstehen dabei aus dem Präfix "<name>;IPTV:20: S=1|P=0|F=UDP|U=", der Multicastadresse (siehe oben) und dem Rest des alten Eintrag des Kanals (hinter :I: ).

    Nach dem Start des VDR steht dem Fernsehvergnügen mit Netceiver, aber ohne mcli/dvbloop nichts mehr im Wege, wenn auch das ganze aufgrund der zweiten channels.conf nocht nicht wirklich praxistauglich ist. Das Umschaltverhalten sowie die Stabilität sehen auf jeden fall vielversprechend aus.

    Grüße
    Holger

    Habe das gute Teil mittlerweile auch hier stehen - läuft recht passabel und beeindruckend performant (zumindest wenn man nur Atom gewöhnt ist). Die Lautstärke ist in der Tat etwas höher, aber zumindest ist es nur ein Rauschen ohne Toninhalt und damit nicht besonders nervig.

    Zur Fernbedienung: die ID42 hat zwei (!) RC-Receiver. Einer (CIR) ist eingebaut und wird out-of-the box vom Kernel als Input-Device erkannt. Eine kleine Zeile in die rc.cfg und eine zur FB passende keymap und yavdr kommt damit klar. Erfreulicherweise ist er ein Sprachtalent und versteht neben RC6 auch das RC5 der alten Hauppauge-FB (angeblich auch noch andere Codes). Das ersparte mir das Umprogrammieren unzähliger im Haus herumfliegenden FBs. Mit der beiligenden RC6-FB ist auch ein Start aus S5 problemlos möglich. Weiterhin liegt noch das übliche USB-Teil bei, bei mir liegts aufgrund des genialen CIR-Emfängers noch verpackt in der Kiste...

    Hier mal ein paar Details zum eingebauten Empfänger:

    Grüße
    Holger

    Leider (oder besser zum Glück) habe ich keinen Streamdev mehr im Einsatz, bei mir ist einfach jeder VDR auf zwei S2-Devices konfiguriert (im Setup des MCLI-Plugins), im Netceiver stecken 6 Tuner. Diese werden definitiv alle benutzt, und jeder VDR kann gleichzeitig aufnehmen (1. Transponder) und beliebig umschalten (2. transponder). Sollten mal mehr VDRs in Betrieb sein, als Devices frei, wird es leider hässlich, denn der Netceiver kann nicht ohne weiteres priorisieren. Da könnte der zuletzt gestartete VDR in die Röhre schauen ("Kanal nicht verfügbar").

    Eventuell konkurriert das XVDR-Plugin irgendwie mit dem streamdev-Plugin um das zweite Device?
    Hat der Apple-TV auch einen VDR mit mcli laufen und könnte damit selbst Tuner belegen?

    Muss mir bei Gelegenheit mal ein Streamdev-Setup basteln.

    Grüße
    Holger

    Quote


    dieses ist leider Fehl geschlagen; im Log von Wirbelscan kommt immer, das es kein DVB Gerät findet.
    Ich habe Manuell ein paar Channels eingetragen, diese laufen jedoch..
    Woran könnte das liegen, das Wirbelscan kein Gerät findent?


    Wirbelscan habe ich noch nie benutzt - kann ich nicht genau sagen. Ich vermute jedoch, dass es am VDR vorbei auf die /dev/dvb-Devices zugreift, die gibts mit dem Netceiver natürlich nicht. Dank automatischer Kanalaktualisierung habe ich einen solchen Scan allerdings auch noch nicht vermisst. Also Kanalaktualisierung auf "neue transponder hinufügen" stellen und den VDR etwas laufen lassen, dann sollten um die 2000 Kanäle da sein.

    Grüße
    Holger

    Hallo Rocki,

    es gibt grundsätzlich zwei Wege, mit dem Netceiver zu reden. Der erste emuliert eine DVB-Karte (dvbloop) und benötigt keinerlei Plugins im VDR. Das dazu nötige Kernelmodul ist m.W. nicht mehr übersetzbar auf Linux 3.x-basierenden Systemen und zumindest auf yavdr 0.4 und 0.5 nicht verwendbar. Durchaus möglich, dass sich das beheben lässt, aber an der Front kenne ich mich nicht aus (ich mag diesen Ansatz auch nicht).

    Der zweite Weg besteht im mcli-Plugin. Dieses implementiert ein VDR-Device, braucht dafür aber kein /dev/dvb/irgendwas und ist damit vom Linux-Kernel komplett unabhängig. Bis zu VDR 1.7.21 funktionierte das out of the box. Mit der 1.7.22 gab es Änderungen im VDR, die (alte) Bugs im mcli-Plugin triggern. Hier kommen die Patches aus diesem Thread ins Spiel. Sofern Du aber einfach ein aktuelles yavdr 0.5 installierst, kannst Du eigentlich alles in diesem Thread geschriebene vergessen, denn die PAtches sind in den aktuellen yavdr-0.5-Paketen schon drin. Ich habe hier die originalen Pakete laufen, bis auf ganz kleine Schönheitsfehler problemlos.

    Grüße
    Holger

    Die Ausgaben des LCDd sollten sich unter /var/log/upstart/LCDd.log finden. Bei mir terminiert er definitiv nicht, ich habe aber auch nur ein ganz simples IMON-VFD ohne RC-Funktionen.

    Die Optionen sind 1:1 aus dem Initscript geklaut, sollte eigentlich genau so häufig oder selten knallen wie mit dem Originalskript.

    Grüße
    Holger

    Quote


    Sind die Auslöser, die musst du erstmal abstellen.
    Die Puffer vom Plugin sind fast leer "17+3 v-buf", das Plugin würde mehr abholen wenn
    mehr da ist.


    Das kann m.E. nicht der Auslöser sein. Die MCLI-Meldung kam es erst, als schon mehr als 20 Sekunden lang der Stream nur noch stolperte und hopste. Ansonsten ist der Log vollständig, davor war nichts außer EPG-Scan und Kanalwechseln.

    Quote


    Wenn die Fehler jede Sekunde passieren, da hat man wenig Chancen


    Das ist nicht der Fall, eher 0.1-1 pro Stunde. Das passiert aber bei vielen direkt PCI-Karten enbenfalls, wie viele hier im Forum geposteten Logs zeigen.

    Nein, offenbar wird das Device aufgrund der stehenden Widergabe seine Daten nicht mehr so recht los, sodass dort dann Buffer überlaufen. Halte ich eigentlich für einen Folgefehler, da das Problem zu dem Zeitpunkt schon seit > 20 sec besteht.

    Was natürlich gut möglich ist, dass das Problem durch ein kaputtes TS-Paket getriggert wird, wie es im Netceiver-Betrieb alle paar Stunden durch ein verlorengegangenes Paket durchaus mal vorkommt. Aber Robustheit gegen TS-Fehler wäre ja sicherlich grundsätzlich anzustreben.

    Grüße
    Holger

    Hallo,

    seit meinem gestrigen dist-upgrade hat sich leider ein neues Problem eingeschlichen: Die Bildwiedergabe über softhddevice scheint insbesondere auf ARD/ZDF HD hin und wieder zu entgleisen: erst beginnt ein Ruckeln, dann kommen starke Block-Artefakte dazu, letztendlich stehend Bild und Ton komplett. Der VDR ist dabei noch in Ordnung, kurzer Senderwechsel reicht zum sofortigen Wiederbeleben. Das Problem tritt auf den besagten Sendern alle 1-2 Stunden auf. Mit der Vorgängerversion ist das in vielen hundert Betriebsstunden nicht einmal passiert. Wenn ich das upgrade noch richtig in Erinnerung habe, war softhddevice das einzige von Belang, was aktualisiert wurde.

    Im Log sieht das ganze so aus:

    Zur Hardware: Zotac ZBox ID-HD80

    Code
    CPU0: Intel(R) Atom(TM) CPU D2700   @ 2.13GHz stepping 01
    02:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 520M] (rev a1)

    Grüße
    Holger

    Folgender upstart-Script funktioniert bei mir soweit ganz gut (inkl. S3):

    Weiterhin muss natürlich der Original-Skript sowie alle Symlinks darauf entsorgt werden und im VDR-Skript ein "and started LCDd" eingefügt werden. Leider sind meine Debian/Ubuntu-Paketierungsfähigkeiten gering entwicklet bis nicht vorhanden...

    Gegen den Server-screen nach dem Start des LCDd habe ich allerdings noch kein wirksames Mittel gefunden.

    Grüße
    Holger

    So ähnlich waren meine Anforderungen seinerzeit auch. Das Problem: damit gehören wir zu einer völlig uninteressanten Zielgruppe.
    Eher wird herstellerseitig an einem vernünftigen Display oder einem ordentlichen Backlight gespart als an irgendwelchen nur halb funktionierenden Hochglanzfeatures.

    Gute (Bild-)Qualität wirst Du daher bei "gut" ausgestatteten Geräten finden, bei denen mit wenig Ausstattung ist die Qualität unter aller Kanone...
    Was lohnen kann: Blick auf völlig veraltete High-End-Modelle (aus dem letzten Jahr ;) )

    Grüße
    Holger

    dito hier.

    Die Sleeps sind m.E. keine gute Lösung, da immer noch timing-abhängig. Ich mounte beispielsweise in der fstab ein GlusterFS, je nach Last ist mal der VDR eher oben, mal der LCDd.
    Der einfachste und sauberste Weg sollte wohl ein upstart-Skript für den LCDd sein.

    Frage ans Team: Hatte ein solches eine Chance, in ein yavdr-Paket zu wandern, das den Ubuntu-LCDd ersetzt?

    Grüße
    Holger

    Hallo,

    ich stell die Frage mal in die Runde, da hier möglicherweise einige den oben genannten Rechner im Einsatz haben.

    Folgendes sind die Symptome:
    - Der Lüfter läuft beim Power-On für eine Sekunde an, ist also elektrisch und mechanisch höchstwahrscheinlich i.O.
    - der PWM-Output liefert eine sehr niedrige Spannung per Multimeter, ist also wahrscheinlich von Controller auf 0 gesetzt. Versorgungsspannung (12V) liegt an
    - unabhängig von der Temperatur läuft der Lüfter nicht wieder an, egal ob im BIOS oder unter Linux. Die CPU wird ohne Gnade bis über 100° gegrilt
    - der "Ausfall" passierte mitten im Fernseh-Betrieb, ohne irgendeine SW-Änderung

    Erfolglose Ideen:
    - sämtliche denkbare BIOS-Einstellungen zur Lüfterregelung
    - BIOS-Update, Reset auf Werkseinstellungen

    Hat jemand eine Idee, was hier passiert sein könnte und wie man den Rechner ggf. retten könnte? "Normale" Lüfter passen aufgrund der Mechanik kaum rein, ein neuer Originallüfter dürfte mit hoher Wahrscheinlichkeit auch nix bringen, da vermutlich Ansteuerproblem.

    Grüße
    Holger

    Habe die Sache mit der Signalqualität mal zurückverfolgt: das text2skin-Plugin nutzt nicht die VDR-Schnittstellen, sondern führt selbst ioctl() auf die Device-Files des DVB-Gerätes durch. Ohne Device-File ist das natürlich schwierig. Ich habe einen entsprechenden Patch als Feature-Request zum text2skin-Projekt gestellt, dass stattdessen das offizielle VDR-Interface benutzt. Damit funktioniert die Signalstärke auch in allen Text2Skin-Skins. Auch wenn das nicht für den yaVDR interessant ist, findet sich auch dieser Patch fürs text2skin-Plugin im Attachment (urspünglich gegen das GIT vom Text2Skin-Pluigin erstellt, passt mit Offset aber auch auf die yavdr-Version).

    Es wäre schön, wenn aber zumindest der Bugfix (temp_disable.patch) Eingang in yaVDR finden würde, denn gestern abend hab ich mir mit einem unbedachten dist-upgrade meinen 0.5er yaVDR wieder verbuggt ;) Ansonsten wäre ich mit den geplanten Änderungen fürs mcli-Plugin erst mal durch, es sei denn jemand findet noch irgendwelche krummen Dinger oder die VDR-Version ändert sich im 0.5 vor dem Release nochmal.

    Grüße
    Holger