epgdata.com ceases operations

[malvinas2]

egpData discontinues its service. It is no longer possible to purchase a new annual subscription. According to their website existing subscriptions remain valid until the PIN expires :-( (Source: epgdata.com)

Regarding "existing subscriptions", I get the following error message (still using xmltv 0.5.69 on Ubuntu 16.04):

Downloading include zip file
Unable to retrieve data from URL http://www.epgdata.com/index.php?action=sendPackage&iOEM=&pin=yzZaumsHFCI2DfH6ZFblablablabla&dayOffset=0&dataType=xml:
Can't connect to www.epgdata.com:443 (certificate verify failed) (500) at /usr/bin/tv_grab_eu_epgdata
line 313.
Couldn't open /tmp/wl2WehSxob/genre.xml:
No such file or directory at /usr/bin/tv_grab_eu_epgdata line 373.
 at /usr/bin/tv_grab_eu_epgdata line 373.

Any alternatives?

[honir]

Can't connect to www.epgdata.com:443 (certificate verify failed)

Have you tried updating the certificate chain on your Ubuntu 16.04 box?

[pmhahn]

gnutls-cli --verbose --port 443 www.epgdata.com

    Issuer: CN=Thawte RSA CA 2018,OU=www.digicert.com,O=DigiCert Inc,C=US

The issuer in the intermediate CA and not the root CA. The Web-Server is supposed to include it within the data it is sending to the client, as clients only have the root certificates. The intermediate certificate is required to build the complete trust chain from the server CA over the intermediate CAs up to a root CA.

This is a upstream bug: www.epgdata.com must include the intermediate CA. I'll try to contact them.

[malvinas2]

I am using Ubuntu 16.04.7 LTS with ESM enabled and up to date. But even the latest version of ca-certificates (20210119\~16.04.1ubuntu0.1\~esm1) throws the error mentioned above.

[pmhahn]

ca-certificates only includes the ~129 root CA certificates, but not the many more intermediate CA certificates. As www.epgdata.com does not include them into their SSL/TLS answer, any client can no longer validate the chain of trust from the server certificate via the intermediate CA certificates up to the trusted root CA certificates.

It's a upstream bug, not a bug in XMLTV, OS component or browser. They must fix their web server.

If you need a work-around, you can install the intermediate CA manually on your host:

# You must be user root:
suod -s
# Download the intermediate CA from the official Web-Site of DigiCert
wget -O /usr/local/share/ca-certificates/xmltv.crt https://cacerts.digicert.com/ThawteRSACA2018.crt.pem
# Verify the certificate against the Root CA shipped by the trusted `ca-certificates` package
openssl verify -trusted /etc/ssl/certs/DigiCert_Global_Root_CA.pem /usr/local/share/ca-certificates/xmltv.crt
# Update the CA trust store
update-ca-certificates
# Become normal user again
exit
# Verify download works again:
wget -O/dev/null https://www.epgdata.com/

Afterwards you should be able to update your schedule again by running mythfilldatabase --only-update-guide -- --days 14 (or your equivalent) as the right user (probably mythtv).

[hirschmich]

Is there also a workaround using the windows binaries from http://alpha-exe.xmltv.org/? I've installed the intermediate certificate into the windows certificate store but xmltv.exe does not seem to respect it. It still gives the error message: Can't connect to www.epgdata.com:443 (500)

[pmhahn]

Is there also a workaround using the windows binaries from http://alpha-exe.xmltv.org/?

Sorry, I'm Linux only since 25 years and do not know how Windows or Perl their works regarding to CA certificates.

epgdata.com claimed to have fixed the problem by private mail to me, but the certificate chain is still incomplete as of today; I have contacted them again.

[hirschmich]

I finally decided to recompile the Windows binaries and make the https request ignore all certificate errors. Maybe not the best solution but works.

[rmeden]

@witesbk Good to know someone else can make binaries.. I assume you followed the procedure I put on xmltv.org? I tried to replicate the problem with tv_grab_eu_epgdata, but I didn't have an account.

[hirschmich]

@rmeden Yes, I've used these instructions. But I found a few tripping hazards in it:

1. In http://wiki.xmltv.org/index.php/XMLTVWindowsBuild it says that one could use version xmltv-0.5.65.tar.bz2 for example. But the makefile does not use PAR::Packer as stated here: http://wiki.xmltv.org/index.php/XMLTVexeBuild. With version 1.1.1 of the source code I works.
2. Quite a few directory names in the makefile have to be changed (at least for the windows build), for example: $(DESTDIR)/./$(PREFIX)/share/doc/xmltv-1.1.1 -> $(DESTDIR)$(PREFIX)/share/doc/xmltv-1.1.1. $(DESTDIR) is empty so the directories start with "/./" what makes them invalid.
3. The packer module is "PAR::Packer" not "Par::Packer". So it has to be installed with "cpan PAR::Packer".
4. "gmake xmltv.exe" also requires Params::Validate which has to be installed by "cpan Params::Validate".

[rmeden]

On 3/7/2022 1:50 AM, witesbk wrote:

@rmeden https://github.com/rmeden Yes, I've used these instructions. But I found a few tripping hazards in it:

1. In http://wiki.xmltv.org/index.php/XMLTVWindowsBuild it says that one could use version xmltv-0.5.65.tar.bz2 for example. But the makefile does not use PAR::Packer as stated here: http://wiki.xmltv.org/index.php/XMLTVexeBuild . With version 1.1.1 of the source code I works.
2. Quite a few directory names in the makefile have to be changed (at least for the windows build), for example: $(DESTDIR)/./$(PREFIX)/share/doc/xmltv-1.1.1 -> $(DESTDIR)$(PREFIX)/share/doc/xmltv-1.1.1. $(DESTDIR) is empty so the directories start with "/./" what makes them invalid.
3. The packer module is "PAR::Packer" not "Par::Packer". So it has to be installed with "cpan PAR::Packer".
4. "gmake xmltv.exe" also requires Params::Validate which has to be installed by "cpan Params::Validate".

Par::Packer shouldn't be needed for "XMLTVWindowsBuild" only the EXE build.  (just don't do a "gmake xmltv.exe"  "gmake install" should install all the grabbers in native perl.

I didn't need to make any file changes, but my directories don't have spaces or version numbers in them ( C:\xmltv )

I haven't tried it from a tar distribution, just from a git pull... I'll have a new work laptop, I'll try to follow the instructions there and see if it needs updating.

Robert