Installation eines VDR+Plugins nativ auf CoreELEC Boxen

Zitat von Paulaner

Mir ist jetzt aufgefallen, dass die Undelete-Funktion im Recordingsmenü nicht vorhanden ist.

Vor einiger Zeit hatte kamel5 mal einen Patch für den vdr-2.4.x geschrieben, siehe hier: VDR-2.4.X und Undelete

Ich bin dran.

Zitat von jojo61

Zabrimus Leider baut dein aktuelles GIT nicht mehr.

Sch****. Ich habe das gelesen, aber nicht daran gedacht, daß es mein Repository direkt betrifft.

Jetzt muss ich erstmal die neuen URLs suchen gehen, falls es diese überhaupt gibt.

Die Änderungen sind alle committed und der Build nahezu abgeschlossen.

Neu sind:

- undelete patch

- Die URLs der Pakete wurden korrigiert und verweisen jetzt auf Repositories von kamel5 und https://github.com/vdr-projects.

Zitat von stegro

Bei mir hat ein ./build-local -i -0 bei nss gescheppert.

Ich habe den 19er und 20er aktualisiert, sprich die letzten Änderungen von CoreELEC gefetched.

Jetzt baut der 20er Branch immer noch nicht

<<< nss:host seq 44 <<<
BUILD      nss (host)
    TOOLCHAIN      manual

....

/usr/bin/ld: Linux5.16_x86_64_gcc_glibc_PTH_64_OPT.OBJ/tstclnt.o: in function `own_CompleteClientAuthData':
tstclnt.c:(.text.own_CompleteClientAuthData+0x4c): undefined reference to `SSL_ClientCertCallbackComplete'

Ich kann dazu aber weder etwas im Forum noch in Github finden. Das könnte jetzt schwierig werden.

edit:

Hmmmm. nss (host), Linux5.16. Das hängt vom Host ab.

Zitat von rell

Sollte wieder bauen, wenn ihr diesen commit https://github.com/CoreELEC/Co…2ba6baff120e875f811e18fef wieder zurücksetzt.

Wunderbar. Das funktioniert. Ich ändere nur sehr ungern die CoreELEC Packages, um Merge Konflikte beim upstream fetch zu vermeiden.

Aber um die Hoffnung auf nicht aufflammen zu lassen: Es baut immer noch nicht

Jetzt macht zaphistory Probleme.

zaphistorychannel.c:47:8: error: no declaration matches 'time_t cZapHistoryChannel::GetWatchTime()'
   47 | time_t cZapHistoryChannel::GetWatchTime() {
      |        ^~~~~~~~~~~~~~~~~~
In file included from zaplist.h:16,
                 from zaphistorychannel.c:11:
zaphistorychannel.h:32:14: note: candidate is: 'long int cZapHistoryChannel::GetWatchTime()'
   32 |         long GetWatchTime();
      |              ^~~~~~~~~~~~
zaphistorychannel.h:17:7: note: 'class cZapHistoryChannel' defined here
   17 | class cZapHistoryChannel : public cListObject {
      |       ^~~~~~~~~~~~~~~~~~
zaphistorychannel.c: In member function 'bool cZapHistoryChannel::Parse(char*)':
zaphistorychannel.c:110:23: warning: format '%a' expects argument of type 'float*', but argument 3 has type 'char**' [-Wformat=]
  110 |     if ( sscanf( s, "%a[^:]:%d:%ld:%ld", &channelbuffer, &historyPos, &zapCount, &watchTime) == 4) {
      |                      ~^                  ~~~~~~~~~~~~~~
      |                       |                  |
      |                       float*             char**
zaphistorychannel.c:110:38: warning: format '%ld' expects argument of type 'long int*', but argument 6 has type 'time_t*' {aka 'long long int*'} [-Wformat=]
  110 |     if ( sscanf( s, "%a[^:]:%d:%ld:%ld", &channelbuffer, &historyPos, &zapCount, &watchTime) == 4) {
      |                                    ~~^                                           ~~~~~~~~~~
      |                                      |                                           |
      |                                      long int*                                   time_t* {aka long long int*}
      |                                    %lld
make[1]: *** [Makefile:65: zaphistorychannel.o] Error 1

Okay. Das liegt nicht nur an zaphistory. Nehme ich das Plugin aus dem Build, baut epg2vdr nicht mehr.

Mein erster Verdacht war ein Compiler Upgrade, aber das letzte gcc Update stammt wohl aus April. Aber irgendwas ist restriktiver geworden.

Zitat von rell

aphistory baut, wenn man hier statt "long" "time_t" nimmt: https://github.com/vdr-project…r/zaphistorychannel.h#L32

epg2vdr meckert auch time_t an, hier wirds ähnlich sein. Das Problem scheint, dass time_t im Code mit "long int" etc. vermischt wird.

zaphistory habe ich entsprechend geändert und damit baut das Ganze.

Das größere Problem ist epg2vdr, da Änderungen an /lib notwendig sind und da kommen wir dann in den Bereich der Mysql Datentypen und die Fehlermeldungen sind auch nicht schön. Ich fürchte, ich kann die Auswirkungen möglicher Änderungen nicht mehr einschätzen. Das ist nur ein Beispiel:

update.c: In member function 'int cUpdate::refreshEpg(const char*, int)':
update.c:1482:16: error: no matching function for call to 'getParameter(const char [5], const char [19], time_t&)'
 1482 |    getParameter("uuid", "lastEventsUpdateAt", lastEventsUpdateAt);
      |    ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
parameters.h:45:11: note: candidate: 'int cParameters::getParameter(const char*, const char*, char*)' (near match)
   45 |       int getParameter(const char* owner, const char* name, char* value = 0);
      |           ^~~~~~~~~~~~
parameters.h:45:11: note:   conversion of argument 3 would be ill-formed:
update.c:1482:47: error: invalid conversion from 'time_t' {aka 'long long int'} to 'char*' [-fpermissive]
 1482 |    getParameter("uuid", "lastEventsUpdateAt", lastEventsUpdateAt);
      |                                               ^~~~~~~~~~~~~~~~~~
      |                                               |
      |                                               time_t {aka long long int}

Ich habe einen Downgrade des GCC auf 11.3.0 versucht - allerdings ohne Erfolg. Die glibc ist auf einem Stand der mal funktioniert hat.

Bisher betrifft es die beiden Plugins epg2vdr und scraper2vdr. Nehme ich beide aus dem Build, fängt aber das Packet lirc mit Installationsproblemen an. Ich werde mal alles wegwerfen und ganz neu bauen lassen müssen. Es könnte sein, daß durch die vielen Up-/Down-/Upgrades da irgendwas durcheinander gekommen ist.

So gerade mit ich mit dem 20er Branch sehr unzufrieden..

Zitat von rell

Ich bin ziemlich sicher, das Problem ist, dass für TARGET_ARCH=arm nun time_t auf 64bit gesetzt ist und jetzt die Unsauberkeiten auffallen. time_t ist jetzt nicht mehr zufällig so groß wie long int oder pointer ist...

Der Versuch, das temp. wieder auf 32 Bit zu setzen funktionierte nicht.

Offensichtlich wollte man nicht bis 2038 auf einen Überlauf bei time_t (long int) warten.

Ich wollte mir die Fehlermeldungen von epg2vdr mal genauer anschauen und habe einen Debian Unstable Container erstellt - mit gcc 12.1 und glibc 2.33.

Und was soll ich sagen? Es läuft einfach durch. Keine Fehlermeldungen...

Also müssen irgendwelche globalen CFlags oder Compiler Direktiven für die Fehlermeldungen verantwortlich sein. Oder es liegt am Cross-Compiler oder ... an irgendwas anderem.

Zitat von rell

was ist der Grund, warum du die time64 patches für lirc und eventlircd wieder rausgenommen hast?

Ich versuche noch irgendwie, den 20er Branch zu kompilieren. lirc und eventlircd liesen sich bei mir lokal mit dem Patches nicht kompilieren.

Da es aber wohl aber offizielle Builds gibt, kann es eigentlich nur am Host liegen. Aber einer Lösung bin ich noch keinen Schritt weiter gekommen.

Das live-Plugin schlägt fehl mit "Cross Compiler Badness", weil Includes vom Host verwendet werden. Ursache noch unbekannt. Der Kodi Build schlägt fehl. Ursache auch unbekannt.

Mein nächster Versuch ist der Build unter Ubuntu Focal in einer sauberen Maschine. Aber da gibt es jetzt wohl ein Problem mit einem Paket bzw. den Sourcen, die nicht mehr gefunden werden (cxxtools).

Ich habe aber auch nirgends gefunden, daß CoreELEC auf z.B. neueren Ubuntu Versionen (22.04) offiziell gebaut werden soll. Oder das eine ganz andere Distribution offiziell unterstützt wird.

Es ist einfach zu Haare raufen. Der 20er Branch ist im Moment ein Experimentierfeld, daß ich irgendwie durchbringen will.

Es sollte jetzt wieder alles bauen. Allerdings musste ich für den 20er Branch live und restfulapi deaktivieren.

Zitat von rell

Da habe ich einen Patch für live drin. Das Problem bei mir ist, dass tntnet-config nicht 3.0.0 sonder 2.2.1 zurückliefert, dann fehlt das typedef.

Oh danke!!

Den Patch habe ich einfach mal für den 20er Branch übernommen. Eine ähnliche Lösung könnte dann das Problem für restfulapi lösen. Wenn die Hitze vorbei ist, schaue ich mal nach.

Zitat von rell

Die Sourcen von tntnet und cxxtools kann ich dir geben, wenn du willst, ich hatte sie gezogen, bevor der Server down ging.

Auf Github (https://github.com/maekitalo/) findet man die wohl offiziellen Repositories zu tntnet und cxxtools. Allerdings muss der Build leicht umgebaut werden, damit das configure Script direkt nach dem entpacken erstellt wird.

Zitat von rell

Ich baue auf einem selfhosted Debian Bullseye über github actions. Das ist eigentlich ziemlich cool. Der lokale build hat mit dem live patch gestern funktioniert.

Kann die workflows mal wo veröffentlichen, wenn du magst. Derzeit liegt das in einem privaten repo...

Das mache ich auch Im 19.4-Matrix-VDR Branch finden sich die Workflows. Ich habe gerade eine neue Version getagged und die Workflows getriggert. Ich will sehen, ob der Build durchläuft.

Zitat von rell

Nur ein Hinweis: Wenn sich die Toolchain geändert hat, musst du komplett neu bauen...

Mein lokales Repository war dermaßen strubbelig, da habe ich alles gelöscht und neu von Github geholt. Und damit ging es dann viel weiter, als vorher.

Aktuelle Probleme sind noch:

- cxxtools / tntnet im 20er Branch

- live und restfulapi im 20er Branch

Jetzt warte ich noch auf etwas kühleres Wetter. Es ist mir gerade viel zu warm und ich fange an unnötige Fehler zu machen.