Page 1 of 1

[FIXED] MythTV grabber not functional.

PostPosted: Jun 28th, '21, 09:49
by bittwister
Any MythTV users getting
Movie grabber not functional
in /var/log/mythtv logs

grep 'not functional' /var/log/mythtv/*

Snippet from mythfilldatabase -v system
Code: Select all
# tv_grab_zz_sdjson --config-file '/root/.mythtv/Antenna.xmltv'
# --output /tmp/mythUK3YVx
Initializing...
 ** POST https://json.schedulesdirect.org/20141201/token ==> 500 Can't
connect to json.schedulesdirect.org:443 (certificate verify failed)
Can't connect to json.schedulesdirect.org:443 (certificate verify
failed) 

Re: MythTV grabber not functional.

PostPosted: Jun 28th, '21, 17:08
by doktor5000
What Mageia version is that? And when did you last update your rootcerts ?

I don't see any issue when checking the certificates here via
Code: Select all
[doktor5000@Mageia8]─[17:06:34]─[~] echo | openssl s_client -connect json.schedulesdirect.org:443 | openssl x509 -noout -dates
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = *.json.schedulesdirect.org
verify return:1
DONE
notBefore=Dec  1 00:00:00 2020 GMT
notAfter=Dec 30 23:59:59 2021 GMT

Re: MythTV grabber not functional.

PostPosted: Jun 28th, '21, 19:07
by bittwister
Sorry. clean install release 8 and grabber had been working till around 23 Jun last kernel updates. Tried your command and am seeing error num 20.

Code: Select all
$ echo | openssl s_client -connect json.schedulesdirect.org:443 | openssl x509 -noout -dates
depth=3 C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
    snip snip


How do I update my rootcerts?

Re: MythTV grabber not functional.

PostPosted: Jun 28th, '21, 20:10
by bittwister
64 bit only install.

Code: Select all
#  urpmi.update -a
medium "Core_Release" is up-to-date
medium "Core_Updates" is up-to-date
medium "Nonfree_Release" is up-to-date
medium "Nonfree_Updates" is up-to-date
medium "Tainted_Release" is up-to-date
medium "Tainted_Updates" is up-to-date

#   rpm -qa --last | grep rootcerts
rootcerts-java-20210525.00-1.mga8.noarch      Mon 07 Jun 2021 05:50:25 PM CDT
rootcerts-20210525.00-1.mga8.noarch           Mon 07 Jun 2021 05:50:24 PM CDT

Re: MythTV grabber not functional.

PostPosted: Jun 28th, '21, 22:27
by doktor5000
FWIW urpmi.update only updates repo metadata, which is not really relevant here. You already have the latest rootcerts.

But it seems you get a different certificate chain, although even that one from the Starfield CA is trusted here:

Code: Select all
[doktor5000@Mageia8]─[22:25:18]─[~] openssl crl2pkcs7 -nocrl -certfile /usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit | openssl pkcs7 -print_certs -noout | grep -i starfield
subject=C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
issuer=C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
subject=C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
issuer=C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Root Certificate Authority - G2
subject=C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
issuer=C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2

Re: [FIXED] MythTV grabber not functional.

PostPosted: Jul 5th, '21, 13:42
by bittwister
It was not a rootcerts rpm problem but running "urpmi --replacefiles --replacepkgs rootcerts" fixed it.

I introduced the problem when updating certs that had expiration dates greater than 398 days.
Chopped down output from my check certs script follows:

Code: Select all
# ch_4_expired_certs
  /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem validity period, 7180 days,
  /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem validity period, 7180 days,
  /etc/pki/tls/cert.pem validity period, 7180 days, is greater than 398
  /usr/lib64/python3.8/site-packages/twisted/test/cert.pem. no_trailing_newline,
     validity period, 36500 days,
  /usr/share/linphone/rootca.pem validity period, 10741 days,
  /usr/share/phpmyadmin/libraries/certs/cacert.pem validity period, 7305 days,