Version 31 install disabling Python bindings

For discussion related to MythTV which doesn't belong in another forum.

Moderator: Forum Moderators

Post Reply
rocknrobin72
Junior
Posts: 17
Joined: Thu Mar 26, 2020 8:07 pm
United States of America

Version 31 install disabling Python bindings

Post by rocknrobin72 » Tue Mar 31, 2020 9:53 pm

I am installing MythTV v31 from source. I have followed all the guidelines for installing dependencies and the package seemed to install successfully. I can run Myth-setup and start both the backend and front end, but I am getting strange things that happen when I try to watch LiveTV, i.e. database, Mariadb in my case, can't run queries and keeps disconnecting and reconnecting. When I ran configure I got warnings that Python bindings have been disabled. My first question is, are the python bindings necessary for proper operation? Secondly, the warnings point to missing MySQLdb, requests, and simplejson. I have previously installed these dependencies and installed them again. I have python2.7 installed. In my /usr/lib64/python2.7/site-packages/ directory I see:
drwxr-xr-x 3 root root 4096 Mar 31 14:29 MySQLdb/
drwxr-xr-x 2 root root 4096 Mar 31 12:48 requests/
drwxr-xr-x 3 root root 4096 Mar 31 12:46 simplejson/
these directories installed. Where does the configure script look to see that these dependencies are available? Can I copy them or ln them somewhere else so that the configure script picks them up?

User avatar
bill6502
Developer
Posts: 1533
Joined: Fri Feb 07, 2014 5:28 pm
United States of America

Re: Version 31 install disabling Python bindings

Post by bill6502 » Tue Mar 31, 2020 10:10 pm

1st question, not for Live TV. assuming your viewing with mythfrontend.
Unless you've configured some System Event for Live TV that calls a
Python script.

2nd question, ./configure has a --python switch that defaults to python3. If you want
python2, specify it there. Tests are made using the version specified (or defaulted).
Additional checks are made to see if packages exist, which sounds like what you're
seeing.

Code: Select all

    check_python               || disable_bindings_python "Python 2.6 or greater"
    check_py_lib MySQLdb       || disable_bindings_python "MySQLdb"
    check_py_lib lxml          || disable_bindings_python "lxml"
    check_py_lib requests      || disable_bindings_python "requests"
    check_py_lib simplejson    || disable_bindings_python "simplejson"
    check_py_lib future        || disable_bindings_python "future"
check_py_lib just attempts to import the package using the Python version specified
and fails if it can't.

User avatar
paulh
Developer
Posts: 509
Joined: Thu Feb 06, 2014 6:09 pm
Great Britain

Re: Version 31 install disabling Python bindings

Post by paulh » Tue Mar 31, 2020 11:50 pm

What version of MariaDB are you running? 10.4 has a nasty bug affecting MythTV
https://jira.mariadb.org/browse/MDEV-20261 and https://jira.mariadb.org/browse/MDEV-21629

rocknrobin72
Junior
Posts: 17
Joined: Thu Mar 26, 2020 8:07 pm
United States of America

Re: Version 31 install disabling Python bindings

Post by rocknrobin72 » Wed Apr 01, 2020 7:45 pm

Thanks for the update. I switched to Python 3.7 and installed MySQLdb, lxml, requests, simplejson, and future with pip and those dependencies were satisfied. Configure ran without disabling any bindings and appears to be a clean install now. I was able to run mythtv-setup for the initial configuration and the backend along with the frontend launch ok. I am using an HDHR-us two tuner hdhomerun which I was able to configure and scan with no problem. When the backend is launched it shows connecting to the HDHR. When I try to watch live tv either with the WATCHTV button or via the guide the database problems start:
TVRec[1]: Changing from None to WatchingLiveTV
2020-04-01 10:33:21.825459 I TVRec[1]: TuningFrequency
2020-04-01 10:33:21.858165 I HDHRSH[1](1019344C): Added 2 devices from 1019344C
2020-04-01 10:33:21.896278 I HDHRSH[1](1019344C): Connected to device(1019344C-0)
2020-04-01 10:33:21.908749 I MySQL reconnected successfully
2020-04-01 10:33:21.913881 W LoadFromProgram(): SQL contains LIMIT clause, caller should be updated to use limit parameter instead
QMYSQLResult::cleanup: unable to free statement handle
2020-04-01 10:33:22.058656 E DB Error (LoadByTemplate):
Query was:
SELECT recordid, category, (category = ?) AS catmatch, (category = ?) AS typematch FROM record WHERE type = ? AND (category = ? OR category = ? OR category = 'Default') ORDER BY catmatch DESC, typematch DESC
Bindings were:
:CAT1="", :CAT2="", :CATTYPE1="", :CATTYPE2="", :TEMPLATE=11
Driver error was [2/2006]:
QMYSQL3: Unable to execute statement
Database error was:
MySQL server has gone away

2020-04-01 10:33:22.058878 E Error preparing query: SELECT name FROM playgroup WHERE name = :TITLE1 OR name = :CATEGORY OR (titlematch <> '' AND :TITLE2 REGEXP titlematch)
2020-04-01 10:33:22.058885 E Driver error was [2/2006]:
QMYSQL3: Unable to prepare statement
Database error was:
MySQL server has gone away

2020-04-01 10:33:22.058922 I MySQL server disconnected
2020-04-01 10:33:22.058942 E DB Error (GetInitialName):
Query was:
SELECT name FROM playgroup WHERE name = ? OR name = ? OR (titlematch <> '' AND ? REGEXP titlematch)
Bindings were:
:CATEGORY=NULL, :TITLE1="", :TITLE2=""
Driver error was [2/2006]:
QMYSQL3: Unable to prepare statement
Database error was:
MySQL server has gone away

Then the database keeps disconnecting and connecting dozens of times. I am running Distrib 10.4.12-MariaDB. Evidently, as can be seen here I am running into the same issues that the links in the previous post describe. I am using MariaDB for some other web aps I wrote and it is working just fine. Anybody seeing anything from MariaDB folks for a fix.

User avatar
paulh
Developer
Posts: 509
Joined: Thu Feb 06, 2014 6:09 pm
Great Britain

Re: Version 31 install disabling Python bindings

Post by paulh » Wed Apr 01, 2020 11:33 pm

Only what you see in the those MariaDB bug reports. They've known about the bug since August last year and there doesn't seem to be any urgency to fix it. You'd think a bug that causes an SQL server to crash on a simple query would be top priority :evil:. If you can roll back to 10.3 which works fine then do that but if you have many DB's that may be a big headache :cry: .

Post Reply