[gelöst][epghttpd] bei Zugriff auf das WebIF des epgd startet der Service epghttpd immer wieder neu

  • Hallo zusammen,


    ich habe hier eine neu aufgesetzte epgd/epghttpd-Kombi, die mir Probleme bereitet:


    bei jedem Zugriff auf das WebIF startet selbiges neu.


    Der Daemon ist selbst compiliert und der aktuelle Stand aus dem GIT

    commit 449dda4ec3a0333538ba9e83a8066ae5ed10ca92 (HEAD -> master, tag: 1.1.163, origin/master, origin/HEAD)


    Als Anbieter habe ich TVSP im Einsatz, kann es sein, dass dieser hier Müll liefert?


    Cheers,

    Ole

  • epghttpd[27009]: Not a JPEG file: starts with 0x3c 0x3f

    Klingt nach einer korrupten JPEG-Datei. Sieht man im Log vorher vielleicht einen Dateinamen oder wenigstens ein Verzeichnis?

    Wär aber komisch, wenn das WebIF davon so aus dem Tritt kommen würde.


    Ich tippe eher darauf, dass irgendwelche Versionen nicht zusammenpassen.

    Bei mir arbeiten diese Versionen zusammen:

    vdr-epg-daemon 1.1.163 (selber kompiliert)

    vdr-plugin-epg2vdr 1.1.117 (aus yavdr/experimental-vdr)

    MyVDR: yaVDR-Ansible (Ubuntu 18) - softhddevice-openglosd (ffmpeg 2.8) - epgd/epg2vdr - skindesigner estuary4vdr (adaptiert) - 1920x1080@50 Hz | kodi 18 - inputstream + amazon vod
    Aerocube M40 | 300W | ASRock H61M-GE | Intel G530 | Asus ENGT520 | 2 x TT-budget S2-3200 | ASRock Smart Remote (CIR) | 4 GB RAM | 120 GB SSD | 3 TB HDD

  • Aug 22 10:50:50 sundalon epghttpd[27009]: Not a JPEG file: starts with 0x3c 0x3f

    Das würde z.B. zu einer HTML-Fehlerseite passen, die statt dem Bild gespeichert wurde - 0x3c 0x3f entspricht <? - eventuell einfach mal mit grep schauen, welche heruntergeladenen "Bilder" davon betroffen sind.


    Soweit ich das sehen kann schaut der curl-Code in der libhorchi beim Datei-Download nur nach einem 404 Fehler (https://projects.vdr-developer….git/tree/lib/curl.c#n470), aber bei anderen Fehlern würden er die Antwort des Servers einfach gespeichert.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    The post was edited 2 times, last by seahawk1986 ().

  • Das würde z.B. zu einer HTML-Fehlerseite passen, die statt dem Bild gespeichert wurde

    Genau das war es: im FS lagen diverse gespeicherte HTTP 500er Seiten. Anscheinend habe ich da einen schlechten Tag zum initialen

    Abholen erwischt. Der Einfachheit halber habe ich den FS-Cache gelöscht, die DB geputzt und neu angefangen.


    Jetzt passt es wieder, vielen Dank seahawk1986 ! Eventuell sollte man die libhorchi um diverse gängige HTTP Fehler erweitern,

    oder den epghttpd etwas robuster aufstellen?


    Cheers,

    Ole

  • Eventuell sollte man die libhorchi um diverse gängige HTTP Fehler erweitern

    Ja, ich denke es wäre einfacher alles außer 200 als Zeichen zu werten, dass etwas nicht wie erwartet funktioniert hat.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • oder den epghttpd etwas robuster aufstellen?

    Ich hatte das gleiche Problem.


    epghttpd verwendet intern die jpeglib. Bei defekten bzw. komplett anderen Formaten als JPG wirft diese eine Fehler und beendet das Program mit exit()

    Anbei ein Patch für epghttpd welcher die Error-Behandlung so erweitert das das Programm/epghttpd nicht mehr beendet wird

  • Danke für den Patch, habe ihn übernommen. Die Anpassung ist jetzt im git


    Viele Grüße Jörg

  • die Version aus dem git wirft hier leider einen segfault im epgd


    Oct 31 12:37:15 PowerEdge kernel: [4399194.145129] epgd[15515]: segfault at 20 ip 000000000047aa10 sp 00007ffe68751ba0 error 4 in epgd[400000+ef000]


    zurück auf 1.1.163 und er startet wieder


    bauen epgd und epghttpd aufeinander auf, sonst könnte ich nur den 1.1.164er epghttpd nehmen, der startet ja?

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5

  • der Patch hier aus diesem Thread funktioniert hier, nur der aktuelle git Stand wirft den core

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5

  • versuche es nochmal mit make Clean, wichtig, alle Plugins des epgd dabei auch neu bauen und tauschen.

    Wenn es dann noch crashed bitte einen BT.

  • Baur bei mir und startet auch, allerdings bekomme ich folgendes im LOG, wenn der epghttpd startet bzw. das WebIF verwendet wird:



    Ist das gewollt?



    Cheers,

    Ole

    The post was edited 3 times, last by OleS ().

  • zumindest solange das Problem nicht schon beim Download abgefangen wird, und selbst dann noch solange die 'nicht' Bilder noch auf deinem System vorhanden sind.

    Ggf. kann Christian sich das im tvsp Plugin ansehen und den HTTP Code auswerten.

    Ich kann von epgd Seite mal schauen das ich die Codes 400 und 500 direkt abfange. Dennoch sollten auch die anderen HTTP Codes in den Plugin ausgewertet werden.

  • Kann es sein, dass da die return 0 Statements in fromJpeg im Fehlerfall unpassend sind? success = 0, fail = -1

    Und dann wird in https://projects.vdr-developer…/tree/lib/imgtools.c#n216 der Rückgabewert von fromJpeg auch nicht ausgewertet und das selbe Problem gibt es für die Aufrufe von scaleJpegBuffer in webdo.c

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • ja da hast du absolut recht, ich gehe da an einigen Stellen einfach davon aus das die Bilder valide sind und alles klappt. Bislang ging das ja auch gut :o


    Wobei das mit dem return 0 kommt glaube aus dem Patch, ich schaue mir das nochmal an.

  • Habe den Download um eine Prüfung auf 400 und 500 erweitert und den prüfe nun de result von fromJpeg/scaleJpegBuffer.

    Ist im git

  • versuche es nochmal mit make Clean, wichtig, alle Plugins des epgd dabei auch neu bauen und tauschen.

    Wenn es dann noch crashed bitte einen BT.

    ich war nicht davon ausgegangen das ich die Plugins neu bauen muss :o

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5

  • aber mit frischen Plugins gehts

    CKone: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G540, 2x 2GB Kingston DDR3, Zotac GT630 1GB, S2-1600, Ocz Agility 3 60GB, LG GH24NS DVD, 15.6" Selbstbau TFT, Harmony 665, CIR Selbstbau - das Ganze im Silverstone SST-SG03B
    CKtwo: yavdr-ansible/18.04 LTS/2.4.1/kodi18 auf Intel DH67BL, Intel Celeron G1610, 2x 2GB Corsair DDR3, Zotac GT630 1GB, TT S2-1600, Ocz Vertex 2 50 GB, 92 Kanal Seduatmo, Harmony 665, atric USB
    PowerEdge: Ubuntu Server 16.04 LTS / VDR 2.4.1 auf Dell PowerEdge T20, Xeon E3-1225 v3, 16GB ECC DDR3, 2x Cine S2 V6 mit Duoflex, Samsung 840 EVO 120GB, 3x WD White WD80EZAZ 8TB in SW Raid5