Linux cmyth (MythTV) plugin and mysql flush hosts required at every startup [SOLVED]
#1
Thumbs Up 
Hi!

I have a problem with the cmyth plugin - which has surfaced sometime recently; previously it worked, but I've been using mythtvs own frontend, which does not have this issue, so I'm not exactly sure when.

The problem: I need to run 'mysqladmin flush-hosts' every time XBMC cmyth plugin connects to the MythTV backend.

About my Setup:
  • It's one single computer (so no separate backend / frontend)
  • OS: Linux (Gentoo)
  • MythTV version: 0.27.3_p20140907
  • XBMC version: I tried Gotham and Kodi (both behave the same)
  • MySQL version: 5.5.39

MythTV's own frontend can connect without issues, and also I can manually connect from the command line to the MySQL server.

After flushing hosts, everything seems to work OK - until I close the frontend and restart it, after which the problem is back and 'flush hosts' needs to be done again - which is a pain.

In XBMC's log, I get this:

Code:
00:02:04 T:139887646844672   ERROR: AddOnLog: MythTV cmyth PVR Client: Failed to connect to MythTV database [email protected]:3306 with user mythtv: Host 'VillenVDRdevil' is blocked because of many connection errors; unblock with 'mysqladmin flush-hosts'
00:02:04 T:139887646844672   ERROR: AddOnLog: MythTV cmyth PVR Client: Failed to connect to backend
00:02:04 T:139887646844672   ERROR: PVR - couldn't get the capabilities for add-on 'unknown'. Please contact the developer of this add-on: Christian Fetzer, Jean-Luc Barrière, Tonny Petersen
00:02:04 T:139887441159936  NOTICE: Thread TCPServer start, auto delete: false
00:02:04 T:139887908009728  NOTICE: Thread RSSReader start, auto delete: false

In mysql's (nor MythTV's log) there is nothing that would give me any idea of what is going on. In mysqld.err, the log is constantly spammed with this (unrelated message):

Code:
141012  0:05:48 [Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. REPLACE... SELECT is unsafe because the order in which rows are retrieved by the SELECT determines which (if any) rows are replaced. This order cannot be predicted and may differ on master and the slave. Statement: REPLACE INTO recordmatch (recordid, chanid, starttime, manualid,                           oldrecduplicate, findid) SELECT record.recordid, program.chanid, program.starttime,  IF(search = 5, record.recordid, 0), (CASE   WHEN record.type IN (1, 7, 8) THEN  0   WHEN record.type IN (6, 2, 5) THEN  -1   ELSE (program.generic - 1)  END) , (CASE record.type   WHEN 6    THEN record.findid   WHEN 2    THEN to_days(date_sub(convert_tz(program.starttime, 'UTC', 'SYSTEM'),             interval time_format(record.findtime, '%H:%i') hour_minute))   WHEN 5    THEN floor((to_days(date_sub(convert_tz(program.starttime, 'UTC',             'SYSTEM'), interval time_format(record.findtime, '%H:%i')             hour_minu
141012  0:05:48 [Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. REPLACE... SELECT is unsafe because the order in which rows are retrieved by the SELECT determines which (if any) rows are replaced. This order cannot be predicted and may differ on master and the slave. Statement: REPLACE INTO recordmatch (recordid, chanid, starttime, manualid,                           oldrecduplicate, findid) SELECT record.recordid, program.chanid, program.starttime,  IF(search = 5, record.recordid, 0), (CASE   WHEN record.type IN (1, 7, 8) THEN  0   WHEN record.type IN (6, 2, 5) THEN  -1   ELSE (program.generic - 1)  END) , (CASE record.type   WHEN 6    THEN record.findid   WHEN 2    THEN to_days(date_sub(convert_tz(program.starttime, 'UTC', 'SYSTEM'),             interval time_format(record.findtime, '%H:%i') hour_minute))   WHEN 5    THEN floor((to_days(date_sub(convert_tz(program.starttime, 'UTC',             'SYSTEM'), interval time_format(record.findtime, '%H:%i')             hour_minu
141012  0:05:48 [Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. REPLACE... SELECT is unsafe because the order in which rows are retrieved by the SELECT determines which (if any) rows are replaced. This order cannot be predicted and may differ on master and the slave. Statement: REPLACE INTO recordmatch (recordid, chanid, starttime, manualid,                           oldrecduplicate, findid) SELECT record.recordid, program.chanid, program.starttime,  IF(search = 5, record.recordid, 0), (CASE   WHEN record.type IN (1, 7, 8) THEN  0   WHEN record.type IN (6, 2, 5) THEN  -1   ELSE (program.generic - 1)  END) , (CASE record.type   WHEN 6    THEN record.findid   WHEN 2    THEN to_days(date_sub(convert_tz(program.starttime, 'UTC', 'SYSTEM'),             interval time_format(record.findtime, '%H:%i') hour_minute))   WHEN 5    THEN floor((to_days(date_sub(convert_tz(program.starttime, 'UTC',             'SYSTEM'), interval time_format(record.findtime, '%H:%i')             hour_minu
141012  0:05:48 [Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statements writing to a table with an auto-increment column after selecting from another table are unsafe because the order in which rows are retrieved determines what (if any) rows will be written. This order cannot be predicted and may differ on master and the slave. Statement: INSERT sched_temp_record SELECT * from record

... which is another issue (probably a mythtv bug, it is giving commands to mysql which cause the unsafe statement if I uderstand correctly).

In mythtv backend log there's absolutely nothing, too (well, there's this, but unrelated, and the error is coming from error connecting to the mysql database):

Code:
2014-10-12 00:13:42.291577 I [3098/27024] ProcessRequest mainserver.cpp:1445 (HandleAnnounce) - adding: VillenVDRdevil as a client (events: 1)
2014-10-12 00:13:47.406425 C [3098/27024] ProcessRequest mainserver.cpp:1342 (HandleVersion) - MainServer::HandleVersion - Client speaks protocol version 8 but we speak 77!
2014-10-12 00:13:47.412127 I [3098/27193] ProcessRequest mainserver.cpp:1443 (HandleAnnounce) - MainServer::ANN Monitor
2014-10-12 00:13:47.412139 I [3098/27193] ProcessRequest mainserver.cpp:1445 (HandleAnnounce) - adding: VillenVDRdevil as a client (events: 0)
2014-10-12 00:13:47.413491 C [3098/27024] ProcessRequest mainserver.cpp:1342 (HandleVersion) - MainServer::HandleVersion - Client speaks protocol version 8 but we speak 77!
2014-10-12 00:13:47.415937 I [3098/27024] ProcessRequest mainserver.cpp:1443 (HandleAnnounce) - MainServer::ANN Monitor
2014-10-12 00:13:47.415948 I [3098/27024] ProcessRequest mainserver.cpp:1445 (HandleAnnounce) - adding: VillenVDRdevil as a client (events: 1)

Any ideas? I could try to automate running flush-hosts, which would be trivial, but I feel it is a workaround and not a real fix for the issue.

Cheers!
Reply
#2
Also, I've tried the new MythTV plugin, but it does not work at all. Should it work on MythTV 0.27, or only 0.28?

If I try it, I get this in XBMC log (and no TV menu at all in XBMC):
Code:
00:29:47 T:140588599023360   ERROR: AddOnLog: MythTV PVR Client: (CPPMyth)CheckVersion: invalid response
00:29:47 T:140588599023360   ERROR: AddOnLog: MythTV PVR Client: (CPPMyth)CheckService: MythTV API service is unavailable: 192.168.0.3:6544
00:29:47 T:140588599023360   ERROR: AddOnLog: MythTV PVR Client: Failed to connect to MythTV backend on 192.168.0.3:6544
00:29:47 T:140588599023360   ERROR: AddOnLog: MythTV PVR Client:
00:29:47 T:140588599023360   ERROR: PVR - couldn't get the capabilities for add-on 'unknown'. Please contact the developer of this add-on: Christian Fetzer, Jean-Luc Barrière

Oh, forgot to mention, I'm using Daktak's ebuilds / overlay from Daktak's overlay - which in turn uses the code from opdenkamp's github overlay / master branch.
Reply
#3
On the new addon, you need to set the API 'on' on the backend. Mythtv-setup and set pin to 0000.
If I have helped you or increased your knowledge, click the 'thumbs up' button to give thanks :) (People with less than 20 posts won't see the "thumbs up" button.)
Reply
#4
Smile 
nickr,

Thanks for the quick reply!

I had set a pin number in mythtv-setup for whatever reason. Setting it to 0000 and the new plugin now also works, and no flush-host is required! After a quick test, everything (EPG; channel data etc) seems to be working.

Thanks! Smile

(MODS: You may want to move this to the mythtv subforum for archival. I didn't notice it while posting Blush)
Reply

Logout Mark Read Team Forum Stats Members Help
cmyth (MythTV) plugin and mysql flush hosts required at every startup [SOLVED]0