Posts by tehlers

    Wichtig zu dem Thema noch: Die SD-Karte geht auch keinesfalls kaputt, nur das Filesystem ist kaputt. Man kann sie dann wieder formatieren oder mit dd beschreiben, bis zum nächsten Filesystem-Crash.

    Das Problem, dass mir die Raspis in unregelmäßigen Abständen die Filesysteme auf den SD-Karten kaputt geschrieben haben, hatte ich auch immer. Ich bin deshalb auf NFS-Root gewechselt (mit Raspi 2) und hatte (natürlich) seither keine Probleme mehr. Beim Raspi 2 musste man zum Booten aber immer noch eine SD-Karte für den Kernel, config.txt und cmdline.txt (also /boot) haben. Seit Raspi 3 geht auch PXE Boot und inzwischen kann man auch per USB booten (wie Argus ja schon geschrieben hat), was die Probleme mit kaputten Filesystemen nicht mehr haben soll. Und gerade USB-Boot mit ner SSD in nem USB Gehäuse ist ja super als Basis für eine schnelles System.


    Also eigentlich braucht man keine SD Karte mehr...

    Also ich benutze kein MLD, nur selbst gepatchten VDR (deshalb habe ich auch nix gepostet, weil ich vermutet habe, dass es an irgendwas von mir liegt). :)

    Ich benutze allerdings auch kein streamdev und epg2vdr, sondern satip plugin und Inverto IDL-400s mit satip-axe (minisatip). Vielleicht liegt es ja an der Empfangsmethode?

    Ja, ich habe das auch schon seit Ewigkeiten (fand es jetzt aber nicht so schlimm, dass ich dem nachgegangen bin). Ich benutze auch den Classic-Skin. Ich habe allerdings das Gefühl, dass es nicht senderspezifisch ist, sondern mal beim einen Sender, mal beim anderen Sender nicht funktioniert (vielleicht abhängig von den EPGs für die aktuelle und nächste Sendung). Und es ist bei mir auch so, dass die EPGs in der Senderübersicht ok sind, nur die Ansicht mit "OK"-Taste, oder beim Umschalten, wo man die laufende Sendung und die Sendung danach sieht, ist dann einfach ein grauer Kasten. Ich habe allerdings einen RPI2.


    Viele Grüße

    Hallo nochmal,


    die Erfolgsmeldung war wohl doch etwas voreilig. Es kommt sehr häufig beim Suspendversuch:


    Code
    1. vdr: [2714] ERROR: Channel locked (recording)!


    was dann dazu führt, dass suspendoutput nicht suspendiert. Ich vermute, dass es am Permashift patch und plugin liegt, da sonst keine Recording läuft. Aber ich komme dem nicht auf die Spur. Es ist jedenfalls der "cControl::Attach()" aus vdr.c in der main loop... Mehr checke ich nicht...


    Ich gebe erstmal wieder auf und schalte wieder klassisch mit stop des VDRs um. :(


    Viele Grüße

    Wird denn dann überhaupt noch das suspendoutput Plugin benötigt?


    sehr gute Frage, habe ich mir auch gestellt. In meinem Fall hat das dann zumindest noch den Vorteil, dass der SAT/IP Client disconnectet. Das würde ja sonst nicht passieren. Wenn man nur "kurz" umschalten will, könnte das aber auch einen Geschwindigkeitsvorteil bringen, wenn man connected bleibt...


    Viele Grüße

    Hi Thomas,


    Ich habe im verlinkten Thread den Patch aktualisiert. Damit wird der OSD-Provider auch gelöscht, wenn das neue Primary-Device keinen eigenen mitbringt. Damit sollte es nun möglich sein, ein beliebiges Device (z.B. Streamdev-Client) als neues Ausgabedevice zu wählen, womit die Notwendigkeit des dummydevice-Plugins entfällt.


    ich verstehe, also könnte ich in meinem Fall den SAT/IP Client ("1") als Ausgabedevice wählen (auch wenn das gar kein Ausgabedevice ist) und bräuchte deshalb das dummydevice ("3") nicht. Ok, bringt vermutlich aber keinen Vorteil (ausser dass ich das Plugin "dummydevice" nicht benötige), oder?


    Jedenfalls vielen Dank nochmal für den Pointer zu dem Thread, gestern stand ich da auf dem Schlauch.


    Viele Grüße


    Tim

    Hallo Reufer,


    vielen Dank für die Antwort. Dieser Thread war mir gestern beim Lesen wohl durch die Lappen gegangen (oder ich habe den Zusammenhang nicht begriffen).


    Jedenfalls mit dem Patch von Dir aus dem Thread funktioniert es jetzt wohl! Ich habe erstmal nur wieder sleep und tvservice probiert, aber das klappt (wenn auch etwas langsamer als erhofft). Es ist doch richtig, dass man noch immer das dummydevice als primary definieren muss, wenn man rpihddevice in den Hintergrund schieben möchte, oder? Mit dbus2vdr wollte ich jetzt nicht anfangen...


    So sieht das LSTD bei mir (vdr-2.2.0) mit dummydevice aus:


    Code
    1. LSTD
    2. 250-1 [--] SAT>IP 0 192.168.1.3|DVBS2-1|DIGIBIT
    3. 250-2 [DP] rpihddevice
    4. 250 3 [D-]


    Also würde ich das dann so machen:



    Viele Grüße und Danke!


    Tim

    Hallo an alle,


    ich habe vor auf einem rpi2 möglichst schnell zwischen vdr und kodi zu wechseln. Daher habe ich mir überlegt auch das supendoutput plugin zu verwenden. Ich habe die Version von 3PO verwendet (aus diesem Thread), es scheint ja sonst nichts neueres zu geben.


    Den Umschaltcode habe ich mir "zusammengeklaut":



    Jetzt zum Problem: Suspendieren etc funktioniert einwandfrei und ein "startapp /bin/sleep 9999" auch. Aber sobald man die Auflösung oder Refreshrate beim Raspi neu setzt, steigt der vdr aus, z.B.:


    Code
    1. root@raspberrypi:~# tvservice -e "CEA 31"
    2. Powering on HDMI with explicit settings (CEA mode 31)


    Dann steht im Log:


    Code
    1. Jun 8 15:52:09 raspberrypi vdr: [3885] rpihddevice: cOvgThread() thread reset
    2. Jun 8 15:52:09 raspberrypi vdr: [3877] OSD size changed to 1920x1080 @ 1


    Nun macht der kodi das halt auch, sogar beim Starten, sodass dann der vdr aussteigt und in meiner Shell-skript-loop neu startet, sodass dann kodi und vdr parallel laufen. Da scheint doch aber ein Problem mit dem rpihddevice zu sein, dass es nicht mitbekommt, dass der output suspendet ist, oder muss ich noch irgendwas in rpihddevice einstellen/patchen?


    Viele Grüße


    Tim

    Ist ja nicht eilig. Es wäre schön, wenn Du das Problem bei den Treiberprogrammierern (ich gehe mal davon aus, dass Du Kontakte zu Wetek hast) mal thematisieren könntest. Meine Vermutung ist nach wie vor, dass vielen diese "kurzen" Fehler nicht auffallen und daher wenig Beschwerden dazu kommen. Ich hätte aber gerne ein System, was fehlerfreie Aufnahmen macht, gerade als Aufnahmeserver wäre mir das wichtig. Ich vermute einen Treiberfehler oder ein Hardwarefehler im Tuner.


    Danke


    Tim

    Hallo an alle,


    Hi tehler,


    Kannst du mir win video senden wo ich sehen kann was nicht klappt.


    Ich hab alles am klappen bei mir


    so, ich habe mir jetzt die Mühe gemacht und ein Video zusammengestellt. Ich habe heute 20 Minuten Sportschau Live auf "Das Erste HD" aufgenommen und es gab 2 Streamfehler bei der Wetek in dieser Aufnahme. Dann habe ich ein ca. 40 Sekundenvideo um einen der Streamfehler herum geschnitten. Danach habe ich noch eine Schnittmarke exakt um die Stelle des Fehlers gesetzt, damit man ihn leicht im VDR finden kann (ca. Sekunde 35 oder 36). Hier ist das Video (60 MB):


    https://www.dropbox.com/s/rsdk…/Sportschau_live.zip?dl=0


    Viele Grüße


    Tim


    EDIT: Noch ein Hinweis: Wie stark sich solche Fehler auswirken ist auch vom Player abhängig. Ich schaue mit Raspi und rpihddevice, da ist so ein Fehler am nervigsten. Das Bild wird im unteren Teil grün und ist meistens erst beim nächsten Keyframe wieder ok.


    Was meinst du denn damit? Die Weteks funktionieren doch auch ganz wunderbar ohne Tuner. Wenn du sie wegschmeißen willst, dann bitte in meine Richtung.


    hehe, ja gut, war etwas provokativ formuliert. Aber ich habe die Teile halt zum Aufnehmen gekauft und bin unzufrieden, dass man keine fehlerfreien Aufnahmen machen kann. Ich wäre ja bereit neue Tuner zu kaufen, wenn da der Designfehler steckt...

    Hallo,


    ich muss es leider auch nochmal wiederholen: Die Tuner (wohl nur DVB-S2) bei der Wetek haben ne Macke und machen sporadische Fehler. Das ist entweder (hoffentlich) der Treiber oder es ist Hardware. Ich warte mit meinen Weteks seit einem 3/4 Jahr darauf, dass das gefixt wird (habe ich hier schon öfter mal angesprochen). Mit Kernel-Einstellungen-Tuning kann man am Symptom herumdocktern und die Fehler werden weniger, aber sie sind immer noch da. Die Ursache wurde bisher nicht gefixt...


    Wenn die Tuner 100%ig laufen würden, wäre das eine super Plattform aber ich fürchte, dass der Nachfolger den gleichen Fehler haben wird...


    Viele Grüße

    Hi Ollo,


    inzwischen hatte ich die Möglichkeit Deine Einstellungen zu testen. Es kommt mir auch so vor, als ob es etwas besser wird, die Störungen weniger werden, aber sie sind weiter da, getestet mit dem Kernel 3.10.76 und dem wetekdvb-Modul vom Mai.


    Ich vermute noch immer einen grundsätzlichen Bug im Kernel-Modul oder in der Hardware...


    Hast Du inzwischen auch mal wieder Fehler bemerkt, oder läuft es bei Dir wirklich über Stunden ohne Fehler?


    Viele Grüße


    Tim