[solved][epgd/tvsp] error: on line 1: '[' or '{' expected near 'GIF'

Hi,

ich bekomme seit 11.06. beim Verarbeiten der heruntergeladenen tvm Dateien den Fehler

Jun 18 17:43:41 vdr epgd[6890]: Downloaded 'ARD' for 2024-06-18 with (44) Bytes, changed since last load.
Jun 18 17:43:41 vdr epgd[6890]: error: on line 1: '[' or '{' expected near 'GIF'
...
Jun 18 17:51:03 vdr epgd[6890]: EPG Update finished, loaded 400 files (17,188 KB), 37 non-updates skipped, 400 rejected due to format error.
...

Damit phast mein EPG so langsam aus.

Hat Jemand einen Tip?

Danke und ciao.

Michael.

Hi,

Quote from hopsi

Hi,

Problem tritt hier nicht auf, zumindest wird kein Fehler geloggt.

also an epgd selber liegt das nicht. Die Version ist vom 26.05., außerdem habe ich eine Installation aus einer Sicherung vom 01.06. raus gezerrt. Auch bei der kommt der Fehler. Und er tritt - wie geschrieben - erst seit 11.06. auf.

Nachdem du den Fehler nicht hast, kann es auch nicht an den tvm-Daten liegen.

Was nutzt epgd denn zum Parsen der Files? Kann es evtl. ein Parser-Problem sein?

Aber auch das wäre komisch, weil der letzte Update des Systems hat gestern, der vorletzte am 30.05. stattgefunden. Dazwischen haben sich auch keine Programme/Libs geändert.

Danke und ciao.

Michael.

Hm, wenn ich das richtig sehe, kommt das aus tvsp.c:

            tell(0, "Downloaded '%s' for %s with (%d) Bytes%s", extid.c_str(), date.c_str(), (int) jsonData.length(),
                 inFileRef ? ", changed since last load." : "");

Und danach wird der Fehler gemeldet.

Ich habe jetzt mal die Files abspeichern lassen - und die abgespeicherten tvsp-XMLs sind alle leer.

Danach habe ich das tvsp Plugin mal gelöscht - und der Fehler ist weg.

Also ist offenbar erstens das im Eimer, was das Plugin runter lädt und zum zweiten dieser Fehler nicht angefangen in tvsp und in EPGD.

Keiner ne Idee, warum die Files leer sein könnten? Bzw. hat das keiner außer mir? Oder nutzt keiner EPGD mit tvsp?

Ok, ich hab jetzt auch noch das JSON-File abspeichern lassen - das sieht nicht gut aus:

GIF89a^A^@^A^@<90>^@^@ÿ^@^@^@^@^@!ù^D^E^P^@^@^@,^@^@^@^@^A^@^A^@^@^B^B^D^A^@;^@

Sieht aus wie ein GIF, aber warum?

Hat das evtl. was damit zu tun:

curl https://live.tvspielfilm.de/static/broadcast/list/ARD/2024-06-29
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

curl_easy_setopt(handle, CURLOPT_SSL_VERIFYPEER, 0);

in lib/curl.c im EPGD Verzeichnis hat jedenfalls nix verbessert 8-<

Es liegt aber ganz eindeutig an dem curl (curl-8.0.1-150400.5.44.1.x86_64) auf dieser Maschine. Auf einer anderen Kiste mit neuerer curl-Version (curl-8.8.0-2.1.x86_64) wird immerhin auf der Kommandozeile ein gzipptes JSON-File heruntergeladen:

curl -k -H "Accept: application/json" https://live.tvspielfilm.de/static/broadcast/list/ARD/2024-06-29 --output whatever

Quote from beinhart

weiss nicht, was bei dir anders, als bei meinem epg, hier klappt es

Naja, die curl-Version wahrscheinlich.

Oder auch nicht.

Ich habe es jetzt sowohl mit derselben curl-Version auf dem VDR-Server getestet, die auf dem Client funktioniert, als auch den Server von openSUSE Leap 15.5 auf 15.6 aktualisiert und mit deren curl-Version getestet.

Fazit: Auf diesem Server funktioniert es nicht 8-(

Aktuell bin ich mit meinem Latein am Ende.

Hat curl denn eigenen SSL Zertifikate?

Ich bin bisher davon ausgegangen, dass es die unter /etc/ssl nutzt - und die sind aktuell, gerade nach dem Update von Leap 15.5 auf 15.6.

Dann isses das wohl auch nicht - zumal es dieselben sind wie auf dem Client, auf dem es funktioniert.

Dazu kommt noch, dass "curl -k" die ssl-Prüfung ja komplett überspringt.

Und damit ist trotzdem das Ergebnis dieses seltsame Mini-GIF.

Aber jetzt - siehe unten.

Das ist meine eigene Firewall mit dem pfBlockerNG. Aus irgendeinem Grund ist d2jtdy150veg81.cloudfront.net in die Sperrliste geraten 8-(

Kaum hatte ich den gewhitelisted, klappte es wieder.

Ungeklärt ist noch, warum es auf dem Client geklappt hat. Der fragt den pfSense-DNS direkt ab, der Server fragt erst seinen eigenen named, der dann an den pfSense forwarded.

Sorry für die Aufregung.

host live.tvspielfilm.de
live.tvspielfilm.de is an alias for d2jtdy150veg81.cloudfront.net.
d2jtdy150veg81.cloudfront.net has address 172.16.42.42

curl -v -k  -H "Accept: application/json" https://live.tvspielfilm.de/static/broadcast/list/ARD/2024-06-29 --output x
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Host live.tvspielfilm.de:443 was resolved.
* IPv6: (none)
* IPv4: 172.16.42.42
*   Trying 172.16.42.42:443...
* Connected to live.tvspielfilm.de (172.16.42.42) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [70 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [1228 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
*  subject: O=pfBlockerNG DNSBL Self-Signed Certificate; CN=roadrunner-pfBNG-DNSBL-64a011434511f
*  start date: Jul  1 11:42:59 2023 GMT
*  expire date: Aug  2 11:42:59 2024 GMT
*  issuer: O=pfBlockerNG DNSBL Self-Signed Certificate; CN=roadrunner-pfBNG-DNSBL-64a011434511f
*  SSL certificate verify result: self-signed certificate (18), continuing anyway.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
{ [5 bytes data]
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://live.tvspielfilm.de/static/broadcast/list/ARD/2024-06-29
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: live.tvspielfilm.de]
* [HTTP/2] [1] [:path: /static/broadcast/list/ARD/2024-06-29]
* [HTTP/2] [1] [user-agent: curl/8.6.0]
* [HTTP/2] [1] [accept: application/json]
} [5 bytes data]
> GET /static/broadcast/list/ARD/2024-06-29 HTTP/2
> Host: live.tvspielfilm.de
> User-Agent: curl/8.6.0
> Accept: application/json
> 
{ [5 bytes data]
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0< HTTP/2 200 
< cache-control: private, no-store, no-cache, must-revalidate, max-age=0
< cache-control: post-check=0, pre-check=0
< pragma: no-cache
< expires: Sat, 26 Jul 2014 05:00:00 GMT
< content-type: image/gif
< accept-ranges: bytes
< content-length: 43
< date: Sun, 30 Jun 2024 12:37:08 GMT
< server: pfBlockerNG DNSBL
< 
{ [43 bytes data]
100    43  100    43    0     0     38      0  0:00:01  0:00:01 --:--:--    38
* Connection #0 to host live.tvspielfilm.de left intact