Beiträge von heiko322

Das gleiche Problem trat bei mir hin und wieder auch auf. Aber erst seit einem Update vor ein paar Wochen. Ich konnte es darauf zurückführen, dass manchmal

/usr/local/bin/svdrpsend PLUG softhdodroid DETA

nicht richtig ausgeführt wird bzw. das Skript dann auch an dieser Stelle abbricht. Der Befehl manuell ausgeführt lieferte in dem Fall dann als Antwort nur die "220"-Zeile (ohne die folgenden 900 und 221). Habe mir dann mit einem umständlichen Workaround beholfen.

Da ich das Problem vor dem Update nicht hatte, gehe ich von einer Änderung in Softhdodroid (oder svdrpsend) aus, welche diese Fehleranfälligkeit verursacht.

Nach den ersten Tests scheint alles wie gewünscht zu laufen. Endlich geht auch der Wakeup.
"/sys/kernel/debug/wakeup_time" ist bei mir nicht vorhanden - keine Ahnung warum. Ich nutze stattdessen "/sys/class/rtc/rtc0/wakealarm".

Hallo,

vielen Dank für den Patch!

Ich hatte den Wakeup bereits vor ein paar Monaten ausprobiert und nachdem die Box immer nach ca. 1 Stunde statt zum Timer aufgewacht ist, war ich in der Annahme, dass meine Box das einfach nicht kann oder irgendeine Macke hat. Hatte das ganze dann umständlich über einen ESP8266 und WOL gelöst.

Sobald das nächste Release von VDR*ELEC erstellt wird, werde ich den Wakeup auch testen und gebe dann Rückmeldung.

Zitat von Zabrimus

Wenn alles gut geht, dann sollten bis morgen früh neue Images gebaut worden sein. Die Images mit "-s" am Ende beinhalten den softhdodroid patch. Aber das dauert halt ein paar Stunden.

Ich konnte ein Image mit den softhdodroid patch testen. Das Umschalten ist tatsächlich noch etwas flotter und liegt jetzt bei so etwa 1 Sek. Das Springen in Aufnahmen und der Vorlauf funktionieren auch einwandfrei. Ansonsten konnte ich keine Fehler feststellen.

Ein Problem habe ich noch bei Rückwärtsspulen in HD-Aufnahmen. Da bewegt sich nur der Anzeigebalken, aber das Bild bleibt stehen. Das ist aber unabhängig vom Patch und bereits zuvor aufgetreten. Ist das ein bekanntes Problem oder nur bei mir so?

Zitat von Dr. Seltsam

Kannst Du selbst kompilieren oder verwendest Du das image von Zabrimus? Vielleicht kann er ja meinen Patch mal einbauen, damit mehr Leute das Testen können.

Ich habe bisher nur die fertigen Images benutzt. Das Kompilieren hatte an zu vielen Stellen geklemmt. Muss ich bei Gelegenheit nochmal versuchen oder eben warten, bis es (optional) eingebaut ist.

Ich habe auch mal mit dem Parameter /sys/class/tsync/slowsync_enable herumgespielt. Beim Live-TV ist zwar ein Unterschied; aber dieser ist für mich subjektiv minimal. Was ich jedoch festgestellt habe ist, dass das Spulen und Springen in Aufnahmen mit auf "1" gesetzten Wert deutlich flüssiger funktioniert. Ohne den Wert ist die Navigation durch die Aufnahme durch die Verzögerung bis zum Bild stark erschwert.

Zitat von Frodo

Würde mich interessieren wie Du das hinbekommen hast. Kodi 18 kompiliert mit dem von Trusty verwendeten gcc 4.8 nicht mehr. Man kann lediglich eine 18.0-ALPHA1 Version von Kodi 18 nutzen.

Ich hab Kodi nicht selbst kompiliert, sonder ein Repo benutzt. Das war glaube ich dieses hier:

https://launchpad.net/~mango-vdr/+archive/ubuntu/kodi-build

Ist nicht ganz aktuell, aber es funktioniert gut.
Meine Kodi Version damit ist: 18.0-ALPHA1 Git:20180121

Python braucht noch ein update, wie hier bereits erwähnt.

Gruß Heiko

Hab zwar keine Anleitung mitgeschrieben, kann aber sagen, dass es nicht allzu schwer war unter yaVDR Kodi 18 mit den notwendigen Plugins zu installieren. Läuft hier ohne große Probleme mit Netflix, Amazon und SkyGo. Aber nicht vergessen, dass Kodi in dieser Version immer noch Alpha ist.

Gruß Heiko

Bei mir läuft epgd auf meinem Banana PI und dort hatte ich genau das gleiche Problem.
Folgendes hat bei mir Abhilfe geschaffen:

Unter ‚ /lib/systemd/system/epgd.service‘ den ‚Type‘ von ‚notify‘ auf
‚simple‘ ändern. Dann auf der Konsole ein ‚ systemctl daemon-reload‘. Jetzt sollte ein ‚systemctl start epgd‘
zu einem Start innerhalb weniger Sekunden (oder sofort) erfolgen.

Das gleiche dann gegebenfalls noch für epghttpd durchführen.

Gruß Heiko

Hallo,
unsere Rotex Heizung im Keller kommuniziert auch über RS485 mit ihrer Steuereinheit die im Wohnraum angebracht ist. Diese Kommunikation konnte ich per RS485 zu USB Adapter ohne Probleme anzapfen und auswerten (für fhem). Sollte bei dir also auch kein Problem sein. Einzig in den Datenverkehr einzugreifen und Befehle zu senden war zumindest bei mir nicht möglich.

Gruß Heiko

Ich bin zwar auch nicht in der Lage etwas aus dem Backtrace heraus zu lesen. Da ich aber die gleiche Grafikkarte habe, kann ich zumindest meine xorg.yavdr.conf mit deiner vergleichen. Hier fällt auf, dass einige Optionen bei dir fehlen, die bei mir eingetragen sind, wie z. B. die korrekte Auflösung, Anschlusseinstellungen und die zu verwendete edid.conf. Hast du denn über das yaVDR-Webfrontend deinen Fernseher erkennen lassen und dort Auflösung und mögliche Bildwiederholraten eingestellt? Damit sollte dann die korrekte xorg.conf.yavdr mit den nötigen Optionen erstellt werden. Keine Ahnung, ob das zur Lösung führt, aber es scheinen da wohl Einstellungen zu fehlen. Hier zum Vergleich den Inhalt von meiner Datei: http://pastebin.com/8N2RcGuQ .

Gruß Heiko

Ich würde dir auch raten, es nochmal mit dem 304er Treiber zu versuchen. Ich habe hier auch die Asus GT520 Passiv unter der neuesten yaVDR Version und es läuft ohne jede Probleme. Ich meine mich zu erinnern, dass der 352er Treiber zwar auch funktioniert hatte, es dort aber irgendwelche kleineren Anzeigeschwierigkeiten gab, so dass ich auf 304 gewechselt bin.

Gruß Heiko

Zitat von Franzose

Ist euch aufgefallen, dass ihr exakt die FB empfiehlt, die der OP als billig bezeichnet und nach nur 4 Monaten ausgefallen ist?

Nein habe ich nicht, da musst du mal genauer lesen. Der OP bezieht sich auf die URC 7962, einem Nachfolgemodell mit Beschleunigungssensor. Zu dem kann ich nichts sagen. Klar, es ist der gleiche Hersteller, aber deshalb müssen nicht alle Fernbedienungen von diesem gleich schlecht sein. Das von mir referenzierte Modell ist hier bereits sehr etlichen Jahren im Einsatz und funktioniert technisch wie am ersten Tag. Nur die Tasten sind nun langsam leicht abgegriffen.

Dem kann ich nur zustimmen. Habe die URC 7960 bei mir mir und bei 3 weiteren VDR's von Familie/Bekannten im Einsatz und finde diese sehr gut geeignet für VDR und optional der Bedienung weiterer Geräte. Ich hatte schon einige Fernbedienungen im Einsatz, aber die Tastenbelegung der 7960 ist einfach gut gelöst, so dass ohne große Fingerakrobatik die wichtigsten Tasten per Daumen bedient werden können. Dazu ist sie vom Preis her recht günstig.

Das ist der Code 1195. Einzustellen für STB.

Gruß Heiko

seahawk1986: Ja, das Paket passt. Danke.

Gruß Heiko

Ich habe bereits sämtliche Skindesigner-Skins durch und diese zum Teil auch mal mehrere Tage laufen lassen, um sich daran "zu gewöhnen". Wirklich alle sehr schick und schöne Features, weshalb ich diese Skins auch gerne bei der Verwandschaft installiere.
Für mich jedoch, der sagen wir mal gerne eine möglichst große geordnete Informationsdichte auf dem Schirm hat, haben die klassischen Skins klar Vorrang und von denen gefällt mir eben der Anthra FSE am besten.

Gruß Heiko

Nachdem ich nun auch endlich dazu gekommen bin die neue yaVDR 0.6 auszuprobieren, fiel mir nach Installation der Anthra Skins auf, dass diese irgendwie komisch aussahen. Statt in anthrazit waren einige Elemente in einem schlecht abgestuften Grauton. Schwer zu beschreiben, deshalb im Anhang ein paar Bilder.
Ich hatte erst den Skin im Fokus, habe dort aber keinen Unterschied zu der Version in yaVDR 0.5 feststellen können. Das Problem liegt hingegen im Text2Skin-Plugin. Ich habe dieses mit folgenden Optionen neu kompiliert:
IMAGELIB = graphicsmagick
DEVELOPMENT_FEATURES = 1

Nun sieht wieder alles so aus, wie es soll.

Gruß Heiko

Hi,
den Start über "vdrtranscode_server.pl" hatte ich nur erwähnt, falls man (wie ich) nicht das Init-Skript für den automatischen Start verwendet. In beiden Fällen aber wartet vdrtranscode darauf im Video-Verzeichniss (bzw. im "Indir") ein Verzeichniss mit "[cut-...]..." zu erkennen und startet dann dessen Konvertierung. Manuell lässt sich über "vdrtranscode_server.pl" nicht direkt eine Aufnahme auswählen. Dennoch könnte man statt über das Aufnahmemenü/reccmds des VDR natürlich auch einfach über die Konsole oder Dateiexplorer ein Video-Verzeichniss entsprechend umbenennen, worauf vdrtranscode dann mit dessen Umwandlung startet.

Alles klar, habe die Dateien zusammen gesucht und in das angehängte Archiv gepackt.
Kurzanleitung:
- Handbrake installieren
- Die Zeilen aus der reccmds.custom.conf in die eigene Datei übertragen
- vdrtranscode.conf nach /etc und darin die Verzeichnisse anpassen. Die Zahlen hinter UVHQ, HQ etc. entsprechen hier dem Qualitätsfaktor.
- vdrtranscode_server.pl und vdrtranscode_touch_cuted_flag.pl nach /usr/local/bin (oder /usr/bin) und natürlich die Rechte setzen.
- Ob die Init-Skripte funktionieren, kann ich nicht sagen, da ich die Konvertierung immer manuell mit "vdrtransocde_server.pl" starte.

Gruß Heiko