Beiträge von tehlers

Ich habe leider die Übersicht verloren: Gibt es inzwischen eine Lösung für VDR auf Raspi 4B? Soweit ich das überblicken kann, geht das rpihddevice damit bisher nicht, oder?

Danke

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...

Danke auch von mir!

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

Ich bin begeistert. Schöne Idee, tolle Umsetzung! Danke

Hi,

Zitat von clausmuus

es ging um den von der MLD verwendeten Kernel.

achso, sorry. Dann nehme ich alles zurück.

Hi,

da musst Du Dich irren, der 4.4er Kernel wird schon seit einiger Zeit ausgeliefert, wenn man das "rpi-update" Skript benutzt. Ich habe 4.4.11-v7+ auf dem Rpi2.

Viele Grüße

Hallo nochmal,

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

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

Zitat von clausmuus

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,

Zitat von reufer

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:

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

Also würde ich das dann so machen:

dummydev=$(svdrpsend -p 2001 "LSTD" | grep ^250 | grep -v rpihddevice | grep -v "SAT>IP" | sed "s/250-/250 /g" | tail -1 | cut -f 2 -d " ")
rpidev=$(svdrpsend -p 2001 "LSTD" | grep ^250 | grep "rpihddevice" | sed "s/250-/250 /g" | tail -1 | cut -f 2 -d " ")
svdrpsend -p 2001 "PRIM ${dummydev}"
svdrpsend -p 2001 "PLUG suspendoutput SUSP"
svdrpsend -p 2001 "PLUG cecremote DISC"
svdrpsend -p 2001 "REMO off"
/etc/init.d/lirc stop
$@
/etc/init.d/lirc start
svdrpsend -p 2001 "REMO on"
svdrpsend -p 2001 "PLUG cecremote CONN"
svdrpsend -p 2001 "PLUG suspendoutput RESU"
svdrpsend -p 2001 "PRIM ${rpidev}"

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":

#!/bin/sh
#
# run application from the VDR OSD


if [ -z "$1" ]; then
        echo "Usage $0 PROG"
        echo "      switch to PROG until PROG exited"
        echo "  -r  resume rpihddevice frontend"
        exit 1
fi


if [ "$1" = "-r" ]; then
        svdrpsend -p 2001 "PLUG suspendoutput SUSP"
        svdrpsend -p 2001 "REMO off"
        svdrpsend -p 2001 "REMO on"
        svdrpsend -p 2001 "PLUG suspendoutput RESU"
        exit
fi


if [ "$1" = "start" ]; then
        shift
        export DISPLAY=:0
        svdrpsend -p 2001 "PLUG suspendoutput SUSP"
        svdrpsend -p 2001 "PLUG cecremote DISC"
        svdrpsend -p 2001 "REMO off"
        /etc/init.d/lirc stop
        $@
        /etc/init.d/lirc start
        svdrpsend -p 2001 "REMO on"
        svdrpsend -p 2001 "PLUG cecremote CONN"
        svdrpsend -p 2001 "PLUG suspendoutput RESU"
        exit
fi


echo "$0 start $@" | at now 2>/dev/null

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.:

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

Dann steht im Log:

Jun  8 15:52:09 raspberrypi vdr: [3885] rpihddevice: cOvgThread() thread reset
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,

Zitat von Techfreak84

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.

Zitat von Techfreak84

noch kann ich nicht sagen ob die neuen Tuner auf der alten funktionieren wird aber wir arbeiten daran.

Was klappt den bei deiner alten nicht?

Suche Empfehlung für VDR mit 2xDVB-S2, headless wäre ok, stromsparend (am Besten arm Architektur)
Suche Empfehlung für VDR mit 2xDVB-S2, headless wäre ok, stromsparend (am Besten arm Architektur)

Und:

Wetek Play Erfahrungen

bis:

Wetek Play Erfahrungen

Zitat von gda

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...

Zitat von Techfreak84

Ich weiss 100 % das die nachsten Tuner besser werden.

Es wird neue tuners geben

Und weißt Du auch, ob die neuen Tuner dann in der "alten" Wetek funktionieren, oder muss man die alten Teile wegschmeißen?

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