Posts by chessplayer

Quote from patrick31698

Kannst Du mal möglichst Detailliert beschreiben, wie Du LE drauf gekriegt hast?
Ich habe es drei mal versucht und mir jedes Mal den Bootloader zerschossen....

Falls es noch jemanden interessiert: auf der Download-Seite von LibreELEC wird die Prozedur genau beschrieben. Mann muss halt nur aus der nicht gleich als solche erkennbaren Dropdown-Liste im Abschnitt "Direct Downloads" die Wetek Play auswählen und schon klappt die Sache. Ging bei mir sowohl für die Wetek Play als auch für die OpenELEC-Box im Wesentlichen problemlos. Dann noch die advancedsettings.xml mit den Hinweisen aus diesem Thread angepasst und alles läuft wunderbar (jedenfalls wesentlich besser als zuvor; die optimalen Werte für cache levels habe ich wohl noch nicht unbedingt gefunden, aber die Aussetzer sind jetzt kaum noch wahrnehmbar).

Cheers,

chessplayer

Gerald, danke für den Tipp mit LibreElec. Es sieht tatsächlich danach aus, dass die Wetek-Boxen damit und mit den Anpassungen in den advancedsettings wesentlich besser laufen. Für mich damit "case closed"

chessplayer

So, kaum mal hier im Forum nach LibreELEC gesucht, schon diesen Thread genau zu meinem Problem gefunden (den mir leider meine vorgestrige Google-Suche nicht geliefert hatte, da der Begriff "Ruckeln" dort wohl nicht vorkommt ...). Die advancedsettings könnten mein Problem vielleicht lösen, mal testen ...

chessplayer

Quote from gda

... aber seit dem LibreELEC geforkt ist ...

Gerald

Danke für die Antwort und wieder was Neues gelernt. Werde ich mir mal anschauen.

chessplayer

Hallo zusammen,

das würde ich gerne nochmal aus der Versenkung holen:

Quote from massi

Habe ich auch eben festgestellt, einige HD Sender ruckeln, bzw. haben "Zwischenstandbilder" mit Openelec/vdr.

Hat sich in dieser Hinsicht eigentlich etwas getan? Bei Openelec wird ja behauptet, dass mit 6.0.3 Fixes für den DVB-Treiber eingebaut wurden, aber zumindest bei mir ist es immer noch so, dass von Zeit zu Zeit die Bilder stehen bleiben (ca. 1 Sekunde), danach geht es gut weiter bis zum nächsten Stopper. Das gilt für die Wetek Play selbst mit OpenElec von der SD-Karte genau wie für die Openelec-Box. Ansonsten, wenn ich den Sundtek-Tuner verwenden will, dann ist mir der RPi gerade lieber (aber mit dem habe ich leider immer mal wieder relativ krasse Bildfehler ...).

Wäre natürlich toll, wenn es mittlerweile eine Lösung gäbe (bestimmte Einstellung??).

Cheers,

chessplayer

Hallo,

es geht eh nur um ein paar fehlende Logos, die er offenbar nicht selbst zuordnen kann. Da weiß ich ja zumindest jetzt mal den Pfad dank Deines Links (wobei man da natürlich auch allein hätte drauf kommen können), das hilft schon mal. Gandalfs Logos hatte ich eh runtergeladen für die Kodis (aber die muss man schon aussortieren, sonst braucht man ewig, um für die wenigen, die man von Hand angeben muss, immer wieder durch die Liste zu scrollen (bzw. man müsste sich mal genauer anschauen, in welcher SQLite DB die hinterlegt sind und die da per SQL eintragen)). Aber von Gandalf benötigt man ja ohnehin noch ein Repo .

Also, alles gut jetzt und nochmals danke für die ganzen Hinweise.

Gruß,

chessplayer

Super Sache, Danke!

Ich habe außerdem noch das "main" repository hinzugefügt und die skindesigner-fonts installiert, also

sudo add-apt-repository ppa:frodo-vdr/main
sudo apt-get update
sudo apt-get install skindesigner-fonts

Damit hat alles geklappt. Da die skindesigner-logos auch schon installiert waren, werde ich jetzt mal schauen, wie man die fehlenden Logos in der Kanalliste noch ergänzt, weil das ja einfach nur gut aussieht ...

Gruß,

chessplayer

Quote from Bert

Hi,

Warum nicht den skindesigner verwenden - da gibts auch den nopacity skin.

Gruss
Bert

Bert, danke für den Tipp . So funktioniert es! Damit hat es dann auch keinen Sinn, das Thema mit dem eigentlichen Plugin weiter zu verfolgen.

Allerdings ist mir eins aufgefallen: der shady-skin gefällt mir noch besser. Er lässt sich aber nicht installieren, weil die Version vom Skindesigner zu niedrig ist (0.8.3 wird mindestens benötigt). Wäre schön, wenn das yaVDR Team das vielleicht updaten könnte.

Cheers,

chessplayer

Ok, was kann ich tun, um das zu backtracen?

Mein Vorschlag:

• yavdr-plugin-skinnopacity installieren und aktivieren
• syslog löschen
• reboot
• syslog posten

Kommt das ungefähr hin?

Gruß,

chessplayer

Hallo zusammen,

nach einigen Neuinstallationen bin ich einem Fehler auf die Spur gekommen: installiert man das yavdr-plugin-skinnopacity und aktiviert dieses, so bleibt nach einem reboot der Bildschirm schwarz. Im syslog findet man dann eine Zeile mit dem Hinweis auf einen segfault. Deinstallation behebt das Problem, aber natürlich kann man den Skin dann nicht nutzen.

Zusatzinfo: das Problem hatte ich bei [0.6] zunächst nicht, aber es trat dann vermutlich nach dem dist-upgrade auch auf, was mich zur Neu-Installation von 0.6.1 veranlasst hat, da ich dem nicht wirklich auf den Grund gegangen war.

Ich weiß zwar nicht, ob dies die korrekte Methode ist, um das Problem zu melden, aber es kann ja nicht schaden ...

Schönen Gruß und danke an alle, die yaVDR zu dem machen, was es ist (nämlich einfach klasse),

chessplayer

Danke für den Hinweis. Ich habe die Version genommen, die auch Stand heute (22.06.2015) im Playstore zu haben ist (Isengard Beta2) und mich mit meinem VDR 2.2 auf meinem Cubietruck verbunden --> läuft super mit den verlinkten advancedsettings!

Zu den Einstellungen (Deinterlace/Videoskalierung): das stellt man bei einem einzelnen Video ein (also, wenn gestartet) und kann das dann als Standard für alle Videos setzen. Allerdings stand alles schon auf den genannten Werten.

Super Sache!

Nur eine Kleinigkeit noch: Man muss unbedingt bei der Konfiguration des PVR-Clients die Priorität auf eine vernünftige Größe setzen (jedenfalls nicht bei -1 lassen ... ). Das hat mich viel Zeit gekostet, denn ich hatte nur EPG Infos, aber die Streams starteten nicht, bis ich mal die Prio auf 25 gesetzt habe

Quote from BooStar

NA.. die GoFlex taugt aber nicht als epgd-server...

Sorry,

das hatte ich nicht realisiert. Ich verwende immer nur live+ epgsearch, also das, was von den Sendern kommt, und das funktioniert gut. MySQL auf der Dockstar/GoFlexNet/Home dürfte in der Tat schwierig werden. Mit den PogoE02 könnte es aber schon klappen, da die ja 256MB RAM haben; das Zyxel-Gerät mit den 512MB sollte in jedem Fall gehen. Und mir ist bewusst, dass nur die NSA325 auch USB 3.0 hat, aber die Notwendigkeit dafür sehe ich (noch) nicht unbedingt; USB 2.0 sollte eigentlich immer reichen.

Gruß,

chessplayer

Quote from niedi_74

Zyxel nsa 325v2

Gesendet von meinem GT-I9100 mit Tapatalk

So sieht's aus! Noch weniger verbraucht ein Pogoplug oder eine Dockstar bzw. GoFlexNet oder GoFlexHome. Mit Sundtek Stick, genial!

Schönen Gruß,

Chessplayer

Hallo,

nun habe ich also alles nochmal gebaut, wobei zuerst die default locale auf de_DE.UTF-8 gesetzt wurde: Situation bleibt wie zuvor.

Als nächstes habe ich dann live mit Lars' Patch gebaut wie folgt:

apt-get source vdr-plugin-live
cd vdr-plugin-live-*
cat ../live-osd-encoding-v1.diff | patch -p1
dpkg-source --commit # --> live-osd-encoding-v1.patch
dpkg-buildpackage -us -uc

(mag sein, dass das doof ist und man die diff-Datei einfach nach debian/patches hätte kopieren können, aber so hat es mit dem Übersetzen funktioniert).

Leider ist das Resultat, dass jetzt auf der Fernbedienungsseite von live der Bildschirm komplett schwarz bleibt. Noch dazu kommt sofort in der Statusbox "ERROR - Der Server antwortet nicht!". Insofern hat der Patch die Sache leider noch verschlimmert ...

Die ganze Sache ist ja auch nur etwas lästig und nicht wirklich so dramatisch. Insofern breche ich die Untersuchungen an dieser Stelle ab und danke Euch beiden, rechner und Lars, für die Hilfestellung!

chessplayer

Hallo zusammen,

momentan lasse ich alles nochmal neu bauen, da auf meiner Entwicklungsmaschine die Default-Locale nicht gesetzt war (was jetzt mit "dpkg-reconfigure locales" behoben wurde). Dies nur zur Sicherheit.

Dann ist mir noch etwas aufgefallen: bei irgendwelchen Diskussionen im Forum wurde immer mal wieder erwähnt, dass auch das yaVDR/main PPA eingebunden werden müsse. Dort werden z.B. auch cxxtools bereit gestellt, die ja vom live-Plugin benötigt werden. Ich verwende jedoch durch

apt-get build-dep vdr-plugin-live

die libcxxtools8 und libcxxtools-dev aus dem Debian Repo, die laut apt-cache policy allerdings neuer sind, als die im main PPA bereitgestellten (die ich ja ohnehin sonst übersetzen müsste).

Da aber Lars oben davon sprach, dass er mal schauen wolle, ob es gerade in den cxxtools vielleicht Kodierungsroutinen gibt, frage ich mich, ob da ggf. der Hund begraben sein könnte.

Wenn die Übersetzung durch ist und der VDR neu aufgesetzt gebe ich Bescheid, ob sich etwas geändert hat.

chessplayer

Quote from rechner

Es gibt das Verzeichnis /var/lib/vdr/plugins/live/img (kann bei dir ggf. anders sein). Wenn du dort ein xml reinlegst, kannst du das mit http://server:xxx/img/datei.xml aufrufen.

Rechner

Hallo Rechner,

der Pfad stimmt so nicht mehr. Er ist jetzt

/usr/share/vdr-plugin-live/

Außerdem ist es so, dass eine xml-Datei dann (zumindest bei Firefox) nicht über das HTTP-Protokoll angezeigt wird, sondern nach /tmp heruntergeladen und per file-Protokoll angezeigt, was ja auch einen Unterschied macht. In Chrome will er die Datei dann einfach nur runterladen.

Gruß,

chessplayer

Hallo,

ja, in meiner Ubuntu-VM klappt auch alles bestens. Der einzige Unterschied ist da ja, dass ich direkt Euer Binary Package installiert habe, während ich auf der Dockstar eben Eure Source-Packages nehme und übersetze ...

Habe gerade noch eine Idee. Die teste ich mal und melde mich dann wieder ...

Gruß,

chessplayer

Quote from mini73

Probiere mal folgenden Patch. Die extra Zeile mit dem xml-Header hab ich da auch drin.
Letztendlich wird jetzt geprüft, ob der vdr mit UTF-8 läuft und dann werden nur noch die Sonderzeichen <, >, & und " codiert. Alles andere wird 1:1 durchgereicht.

Lars.

Das hat sich mit meinem Post überschnitten. Ich teste mal, danke.

chessplayer

Hallo,

der VDR läuft in UTF-8, wie man ja an meinem syslog-Auszug oben sieht.

Nochmals zur nicht-realen XML-Datei: der tnt-Webserver hat also nicht so etwas wie ein "htdocs"-Verzeichnis, so dass man dort die auszuliefernden Dateien anschauen könnte?

Ich habe im übrigen auch mal meine M$ Windoofs VM hochgefahren und geschaut: Sowohl Firefox als auch IE haben den Darstellungsfehler (was natürlich bei dem Quelltext auch zu erwarten ist).

Lars: aus dem kleinen "ä", welches vermutlich mit zwei Bytes codiert ist, nehme ich an, werden also zwei einzelne numerische Unicode HTML-Codes, richtig? Fraglich ist in jedem Fall, warum das bei Dir klappt und bei mir nicht.

Ich suche mal ein wenig weiter ...

Schönen Gruß,

chessplayer

Hallo Rechner, Lars,

die Änderung in osd_status.cpp habe ich gemacht, schön mit dpkg-source --commit den Patch erzeugt und das Paket neu gebaut. Der String ist dann im Seitenquelltext drin, er bewirkt aber leider nichts (außer, natürlich, dass der String tatsächlich im Seitenquelltext zu finden ist). Alles andere, inklusive der Meldung über die fehlenden Style-Informationen, bleibt gleich.

Habe dann mal den Seitenquelltext gespeichert und aus einer anderen xml-Datei den Vorspann inkl. DOCTYPE und xmlns in die Datei in die Datei kopiert. Damit sind die Style-Informationen dann vorhanden, aber die numeriche Unicode-Notation bleibt (natürlich) erhalten. Nun ist mir nur nicht klar, ob die erst im Browser entsteht oder eben bereits in den GetXYZHtml() Methoden (die ich noch nicht angeschaut habe). Eigentlich vermute ich eher letzeres... Dazu wäre es natürlich gut, wenn ich wüsste, wo genau die Datei osd.xml auf dem Server zu finden ist, damit man da mal direkt mit einem Texteditor reinschauen kann.

Wie dem auch sei, jetzt ist es definitiv zu spät, um weiter darüber nachzudenken. Vielleicht hilft etwas Schlaf ja weiter ...

Bis morgen,

chessplayer