Das gibt bei mir überhaupt keine Ausgabe. Das Startlogo (intern im Display) bleibt stehen.
Setze ich 'black'/'white' anstelle der Tokens dann gehts. Ich lösche jetzt nochmal Plugin und Base und checke komplett neu aus, aber ich denke nicht das es daran liegt.
Edit: Beides gelöscht und neu ausgescheckt, trotzdem das selbe, mit Token wird überhaupt nix ausgegeben, mit 'black' als fgcolor und 'white' als bgcolor geht der Skin.
Natürlich am richtigen Display per serdispllib Treiber getestet.
cu
Oben sind 6 Nullen.
Das hatte ich ja auch schon probiert. Nehme ich die angezeigten HEX Werte gehts auch nicht, lasse ich den Alpha Wert weg dann gehen auch die Hex Werte. Ich glaube das geht einfach was beim Parsen der Werte schief, oder der Treiber mag bei Monocrom keinen Alphaanteil.
cu
Jup, das wars, jetzt gehts.
cu
Ich möchte nochmal an den i18n Patch erinnern, der ist vermutlich einfach untergegangen. Ist zwar jetzt nichts wichtiges... Aber son DE/EN Mischmasch sieht immer blöd aus.
Abgesehen davon muss man eh irgendwann mal, besser es fällt einem VDR < 1.6er Nutzer gleich auf das da noch für VDR < 1.6 nen Pseudo trNOOP/trVDR definiert werden muss (weil AFAIK müsste es eh generell mal getestet werden ob das noch so unter < 1.6 Kompiliert, vermutlich nicht, der Master Zweig vermutlich auch nicht).
cu
Passt schon, ist ja nicht gerade die hohe Programmierkunst was da drin steckt 
Aber wie gesagt, für < 1.6 passt das nicht, aber wenn sich jemand meldet das mal zu probieren kümmere ich mich gerne drum das es dort auch passt.
cu
Ich habe keine Ahnung ob du da jetzt so spontan was mit anfangen kannst, aber für den Fall das dir dazu spontan was einfällt...
#0 0xffffe424 in __kernel_vsyscall ()
#1 0xb7437751 in raise () from /lib/i686/cmov/libc.so.6
#2 0xb743ab82 in abort () from /lib/i686/cmov/libc.so.6
#3 0xb6871318 in ?? () from /usr/lib/libdirect-1.2.so.9
#4 <signal handler called>
#5 0xb747fe38 in strcmp () from /lib/i686/cmov/libc.so.6
#6 0xb6675c91 in cGraphLCDService::NeedsUpdate (this=0x9c55e80, CurrentTime=580364) at service.c:251
#7 0xb6664d42 in cGraphLCDDisplay::Action (this=0x829b540) at display.c:276
#8 0x0812844c in cThread::StartThread (Thread=0x829b540) at thread.c:245
#9 0xb7749955 in start_thread () from /lib/i686/cmov/libpthread.so.0
#10 0xb74d8e7e in clone () from /lib/i686/cmov/libc.so.6Die Situation war das der VDR wegen nem Bug in nem anderen Plugin abgeschmiert ist, und der nächste Startversucht (wegen, das init Script startet ihn sofort neu wenn er abstürzt) brachte diesen Absturz, der nächste Startversuch danach lief durch.
Ist nicht so wichtig, nur für den Fall das dir beim Blick auf die Codezeile was auffällt.
Edit: So wie ich das sehe wäre es für die Robustheit evtl. allgm. gut wenn man die Rückgabewerte der Serviceaufrufe auf != NULL prüft bevor man sie verwendet, evtl. lag hier das Problem ja im Radio Plugin. Oder wie siehst du das?
cu
OK, nochmal etwas sortierter, war gestern schon einwenig verwirrt
Ich habe mal meine Logs durchwühlt und ferstgestellt das das generell ein Problem ist, der VDR schmiert hier öfter mal beim Start ab, mit ist es bissher nur nicht aufgefallen. Die Problemstelle ist
---
strcmp(currRTSData.rds_text, checkRTSData.rds_text)
---
Hast du ne Idee wie man das Debuggen kann? Ist ja nen Pointer, wie findet man raus ob nen Ponter gültig ist, und zwar so das der nicht gleich abschmiert und noch ne Logausgabe hinbekommt. Weil ich weiss hier gerade nicht im geringsten wie ich dem Problem hier auf die Spur kommen könnnte.
cu
Ah, fein.
Edit: Zu früh gefreut, ist gerade wieder mit dem selben Problem (in strcmp) abgeschmiert. Ist irgendein Timingproblem, weil das ist ja nicht immer. Wenn du mir sagt worauf ich prüfen könnte dann könnte ich mal Debugausgaben einbauen und das verfolgen.
Das mit der Compilerwarnung hatte ich auch schon bemerkt (war bei dir ne andere als das signed/unsignet?), aber dazu viel mit nix ein (auf die Lösung bin ich nicht gekommen, ich habe in Richtung "Warnung für diese Zeile deaktivieren geschaut"). Allerdings mekert er bei mir immer noch zwischen einen Vergleich zwischen signed und unsigned. Ein mutiges (unsigned long) lässt bei mir den Compiler verstummen)
--
if (currMailboxUnseenData > (unsigned long)std::numeric_limits<int>::max()) {
--
Mache Sachen sind sooo mühselig
Desweiteren, weil ich da gerade wieder drauf reingefallen bin, ein diff fürs Makefile. Damit kann man GRAPHLCD_SERVICE_FEMON_VALID im make.global des VDR setzen und muss nicht jedesmal dran denken wenn man das Plugin komplett neu auscheckt.
cu
habe mal meinen alten VDR (vdr 1.4.7, fedora core 5) angeworfen um zu testen, ob das ganze graphlcd-zeug dort noch laeuft, siehe da, bis auf eine kleine aenderung in einem Makefile gab es genau keine probleme!
Schön zu hören, das hört sich bei dir ja so leicht an. Ich hatte schon schwierigkeiten den 1.6er zu installieren Dann kannst du ja auch evtl. mal den i18n Patch testen wenn du da noch Lust hast.
Ich vermute da muss dann einfach nur ein
#if APIVERSNUM < 10503
#define trNOOP(s) (s)
#define trVDR(s) tr(s)
#endif #
an passender Stelle rein, und nen Script was aus den gettext Language Files nen i18n.c generiert fliegt auch noch irgendwo rum.
BTW: Der Bug mit der Radio Service Schnittstelle ist auch wieder augetreten, aber das beobachte ich in Ruhe weiter, ich bin gerade dabei meine Installation endlich mal richtig aufzuräumen, da war der VDR mehr in Absturzschleifen als im lauffähigen Zustand
cu
Irgendwie mag meiner das
---
static const char *DESCRIPTION = tr("Output to graphic LCD");
---
nicht. Ich sehe bei mit weiterhin den Englischen Text. Keine Ahnung warum, aber ich vermute es hat nen Grund warum der VDR die umständliche Methode mit trNOOP vorschlägt.
cu
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!