Danke mini fürs fixen. War in der Tat ein blöder Fehler. Ich habe es comited.
Posts by _Martin_
-
-
Hallo,
ich habe gerade in https://projects.vdr-developer.org/issues/2576 geantwortet. Das Problem liegt an ImageMagic 7.
Problem ist bei mir bekannt. Hatte bisher aber keine Zeit das an ImageMagic 7 anzupassen.
Martin
-
Sorry vergessen die Patches nochmal zu erwähnen, hatte ich weiter oben im Thread bereits getan:
Mittlerweile ja, läuft es stabil. Hat aber auch bissel gedauert.
Wenn ich in meinem src Ordner schaue habe ich folgende Patches aktiv:
-
Hi,
sorry das ich jetzt erst antworte.
Leider fällt mir auch anhand des Logs nichts weiter ein was hier schief läuft.
Ich nutze auch einen standard Raspian welcher ständig aktuell gehalten wird.
VDR habe ich 2.4.0 mit rpihddevice 1.0.3 und skinflatplus aus dem git der letzte Stand. Damit läuft bei mir alles fluffig
Grüße
Martin
-
Hallo,
ich selbst nutze das OPENGLOSD nicht und kann dazu auch nicht wirklich etwas sagen. Ich wüsste auch nicht was der Skin hier extra unterstützen muss.
Laut der Ankündigung von Louis damals soll auch jeder Skin funktionieren:
softhddevice mit High Level OSD
Wird denn ein Backtrace geschrieben der vielleicht etwas mehr aufschluss gibt?
Grüße
Maritn
-
-l 3 reicht. --userdump brauchst du nur wenn du wirklich abstrze hast und einen core-dump benötigst.
-
Bitte starte den vdr mit Debug Logging. Eine Ansicht öffnen wo das Problem auftritt und dann das Log hier einmal posten.
Wenn möglich mit so wenig Plugins wie nötig.
-
Wie startest du denn dein VDR?
Einfach
siehe z.B. auch hier http://www.vdr-wiki.de/wiki/index.php/VDR_Optionen
Grüße
Martin
-
Was heißt Server, ich nutze nur den RPI standalone mit einer USB Sat Karte.
Ich bin auch der Meinung streamdev lief nicht mit vdr 2.4.0. Aber vielleicht gibt es ja mittlerweile patches oder so.
-
Mittlerweile ja, läuft es stabil. Hat aber auch bissel gedauert.
Wenn ich in meinem src Ordner schaue habe ich folgende Patches aktiv:
Codevdr-2.4.0-01-fix-svdrp-modt-recflag.diff vdr-2.4.0-02-fix-invalid-locking-sequence.diff vdr-2.4.0-03-fix-locking-channel-display.diff vdr-2.4.0-04-fix-locking-channel-display-2.diff
Aber es kommt auch stark auf die Plugins an. Am besten ohne alles probieren und dann nach und nach Plugins aktivieren und testen.
-
Hmm laut deiner Config ist der TextScroller schon disabled:
Das wollte ich jetzt empfehlen.
Ich selbst nutze einen RPi 2B, vdr 2.4.0, rpihddevice 1.0.3 und latest git von skin flatPlus.
Das Problem bei Langtexten beim RPI ist die MaxPixmapSize von 2048x2048, siehe auch hier MaxPixmapSize per default auf 2048x2048?
Bitte VDR nochmal im Debug-Modus starten und das log posten.
Grüße
Martin
-
Hallo,
kannst du mir mal bitte deine config posten. Irgendwelche Meldungen im Log? Welches Ausgabedevice?
Das beschriebene Verhalten ist mir erstmal nicht bekannt. Wenn die Langbeschreibung fehlt, könnte es am scrolling liegen und evtl. mit MaxPixmapSize. Sonst nochmal Debuging anschalten und nochmal die Logs posten.
Grüße
Martin
-
Hallo,
MaxPixmapSize gibt es erst seit vdr Version 2.3.1. Also entweder neue VDR Version oder ältere Skin flatPlus Version nehmen.
Grüße
Martin
-
Das heißt, wenn wir den Defaultwert vergrößern, dann könnte man zwar mit softhddevice vielleicht größere Pixmaps anlegen, aber auf dem RasPi würde das dann nicht funktionieren (damit wären die RasPi-Benutzer die "angearschten" ;-).
Aber das rpihddevice überschreibt doch MaxPixmapSize mit 2048x2048 und dann währe doch alles gut. Also wenn im vdr core meinetwegen 9999x9999 eingestellt ist dann haben alle Ausgabedevices diesen Wert. Rpihddevice (und in Zukunft vielleicht andere) überschreiben den Wert mit ihrer tatsächlichen Grenze.
Mal angenommen, der Defaultwert wäre "unendlich", was würdest du denn dann in deiner Skin flatPlus machen, wenn auf dem RasPi 2048x2048 als Maximum angegeben wird?
Ich hatte jetzt vor MaxPixmapSize abzufragen und bei CreatePixmap diesen als maximale Größe zu verwenden. Wenn ich also eigentlich ein größeres Pixmap anfordern würde für scrolling oder so, wird es halt abgeschnitten und Scrolling funktioniert dann nicht. Aber zumindest stürzt der VDR nicht mehr ab. Ist jetzt die schnellste und einfachste Lösung für mich
Grüße
Martin
-
Hallo,
ich verstehe worauf Du hienaus möchtest und gebe dir in Prinzip auch Recht.
Aber bis letztes Jahr musste sich kein Skin gedanken über die max Größe der Pixmap machen und dementsprechend nutzen die Skins dies auch aus. Das ist nicht nur bei Skin flatPlus der Fall und bei anderen Ausgabedevices hat man derzeit auch keine Probleme.
Ich wollte jetzt für rpihddevice das MaxPixmapSize implementieren damit der VDR nicht mehr abstürzt. Wenn ich dies aber so umsetze sind alle anderen Nutzer die softhddevice oder ähnliches verwenden die angearschten weil bei denen die Pixmaps auch auf 2048x2048 abgeschnitten werden und dann Funktionen wie Scrollende Texte (bei langen Texten) nicht mehr funktionieren.
Dies wollte ich nur vermeiden aber dann schiebe ich das Problem auf das Ausgabedevice und die müssen halt irgendwelche Werte für MaxPixmapSize eintragen oder es findet sich doch noch ein kompromiss den default Wert im vdr core zu erhöhen
Ich weiß ich könnte auch eine "richtige" Lösung implementieren die dann mehrere Pixmaps hintereinander verwendet oder so, dafür habe ich derzeit aber leider keine Zeit ...
Grüße
Martin
-
Und in softhddevice und Abarten einfach die entsprechende Funktion implementieren. Muss ja sowieso gemacht werden...
Da bin ich auch für aber hier stellt sich die Frage auf welchen Wert? Soweit ich das in einem anderen Thread mitbekommen habe gibt es keine wirkliche Grenze sondern wird vom RAM begrenzt. Also auf welchen Wert stellen?
Und wenn wir dort irgendeinen fiktiven Wert nehmen warum dann nicht auch als default im VDR Core?
Wenn man sich auf einen Wert ala "unendlich" einigt, könnte dieser der default im VDR Core werden und nur wenn ein Ausgabeplugin eine "echte" Grenze hat kann das Plugin diesen Wert überschreiben.
Grüße
Martin
-
So oder so sollten sich Skin-Entwickler darum kümmern.
1. Ich möchte mich gerade darum kümmern
2. Braucht der Skin nunmal die max. Grenze wenn es denn eine gibt. Und wenn es eine Grenze gibt, wird die nicht vom Skin vorgegeben sondern vom Ausgabedevice.
Also die Verantwortung einzig auf den Skin abzugeben kann nicht die Lösung sein.
Grüße
Martin
-
Danke für die Antwort, eEine Diskussion ist ja genau das was ich anstoßen möchte. Wie gesagt das jetzige Verhalten finde ich nicht richtig da 2048x2048 per default nicht die Realität wiederspiegelt. Wie du schon sagst ist es (außer beim rpi) vom RAM abhängig und dort ist in der deutlich mehr möglich.
Vielleicht kann man sich auch auf 9999x9999 Pixel einigen. Vielleicht übersehe ich auch noch etwas. Deswegen würde ich gerne noch mehr Meinungen und insbesondere Klaus hierzu hören.
Grüße
Martin
-
Hallo,
da ich seit neuem auch mit einem RPI TV schaue ist mir folgendes Problem aufgefallen.
In meinem Skin flatPlus verwende ich Pixmaps. Bei großen Pixmaps ist ein Scrolling möglich und diese Pixmaps werden gerne mal größer als 2048x2048 Pixel. Der RPI unterstützt aber nur max. 2048x2048 Pixel. Wenn ich ein größeres Pixmap anfordere schmiert gleich der ganze VDR ab.
Dieses Problem wurde ja schon von Klaus erkannt und es gibt die Funktion MaxPixmapSize seit vdr 2.4.
Nun wollte ich mich daran machen und mein Skin RPI safe machen. Nun ist mir aber aufgefallen das im Default MaxPixmapSize 2048x2048 zurückgibt. Ist dies wirklich so klug gewählt? Softhddevice z.b. hat die Funktion noch nicht implementiert also wird bei Softhdddevice 2048x2048 zurück gegeben. Wenn ich das jetzt einbaue dann wird nicht nur beim RPI das Pixmap begrenzt sondern auch bei allen anderen Ausgabedevices die die Funktion noch nicht implementiert haben (wie softhddevice).
Wäre es nicht z.B. besser per default 0x0 zurückzugeben und das bedeutet halt unendlich weil das Ausgabedevice es nicht implementiert hat?
Grüße
Martin
-