MythTV / mythtv

The official MythTV repository
https://www.mythtv.org
GNU General Public License v2.0
710 stars 345 forks source link

Scheduler DB error, no upcoming recordings #405

Closed TenMinJoe closed 3 years ago

TenMinJoe commented 3 years ago

What steps will reproduce the bug?

trying to schedule any recordings

How often does it reproduce? Is there a required condition?

it's permanent

What is the expected behaviour?

scheduled recordings

What do you see instead?

No recordings scheduled. Log output:

mythbackend: mythbackend[8918]: E Scheduler mythdb.cpp:181 (DBError) DB Error (AddNewRecords):#012Query was:#012SELECT c.chanid, c.sourceid, p.starttime, p.endtime, p.title, p.subtitle, p.description, c.channum, c.callsign, c.name, oldrecduplicate, p.category, sched_temp_record.recpriority, sched_temp_record.dupin, recduplicate, findduplicate, sched_temp_record.type, sched_temp_record.recordid, p.starttime - INTERVAL sched_temp_record.startoffset minute AS recstartts, p.endtime + INTERVAL sched_temp_record.endoffset minute AS recendts, p.previouslyshown, sched_temp_record.recgroup, sched_temp_record.dupmethod, c.commmethod, capturecard.cardid, 0, p.seriesid, p.programid, sched_temp_record.inetref, p.category_type, p.airdate, p.stars, p.originalairdate, sched_temp_record.inactive, sched_temp_record.parentid, recordmatch.findid, sched_temp_record.playgroup, oldrecstatus.recstatus, oldrecstatus.reactivate, p.videoprop+0, p.subtitletypes+0, p.audioprop+0, sched_temp_record.storagegroup, capturecard.hostname, recordmatch.oldrecstatus, NULL, oldrecstatus.future, capturecard.schedorder, p.syndicatedepisodenumber, p.partnumber, p.parttotal, c.mplexid, capturecard.displayname, p.season, p.episode, p.totalepisodes, c.recpriority + capturecard.recpriority + IF(capturecard.cardid = sched_temp_record.prefinput, 1, 0) 2 + IF(p.hdtv > 0 OR FIND_IN_SET('HDTV', p.videoprop) > 0, 1, 0) 2 + IF(FIND_IN_SET('SIGNED', p.subtitletypes) > 0, 1, 0) -5 + (p.first > 0 ) 3 AS powerpriority FROM recordmatch INNER JOIN sched_temp_record ON (recordmatch.recordid = sched_temp_record.recordid) INNER JOIN program AS p ON ( recordmatch.chanid = p.chanid AND recordmatc

I can see that this error is truncated but I don't know how to capture a longer version - obviously happy to follow any instructions to that effect.

Additional information

I have tried rebooting. I have tried repairing the database (no errors reported). I have tried deleting all capture cards and adding them back in. It's not something that only happens after a period of time - it's immediate on starting MythTV.

Thanks in advance for any help with this.

Jpilk commented 3 years ago

It looks as if the version you are running has the 'fix', but your DB probably still has some problems. See

https://forum.mythtv.org/viewtopic.php?f=36&t=4628#p22778

billmeek commented 3 years ago

@TenMinJoe, please check your backend log for a line similar to this:

BIGINT UNSIGNED value is out of range in '((mythconverg.p.previouslyshown= 1) * -(50))'

and paste it here. If you start the backend with --logpath /tmp, better logging is available. You'll see an obvious log file in /tmp.

Also, run this from the command line:

mysql --user=mythtv --password --host=localhost --execute="SELECT * FROM powerpriority" mythconverg

TenMinJoe commented 3 years ago

@billmeek cat /var/log/mythtv/mythbackend.log |grep BIGINT doesn't return anything at all

The SQL query returns:

+---------------+-------------+--------------------+
| priorityname  | recpriority | selectclause       |
+---------------+-------------+--------------------+
| first showing |           3 | program.first > 0  |
+---------------+-------------+--------------------+

Thank you.

billmeek commented 3 years ago

Did you use --logpath /tmp? I only log the error when using that. You can do sudo systemctl stop mythtv-backend. Then sudo mythbackend --user mythtv --logpath /tmp

The SQL, however means you have a Custom Priority and that wasn't addressed in the latest fix.

If you build from source, I can give you a fix, otherwise, it will likely be Tuesday 'til it gets to Ubuntu's servers.

In the mean time, if you can live with it, remove the Custom Priority and retest please.

TenMinJoe commented 3 years ago

I have tried again with --logpath /tmp, no change.

I will try removing the custom priority and get back to you, thanks.

TenMinJoe commented 3 years ago

Removing the custom priority fixed it, thank you very much! I probably put that rule in 10 years ago and I don't recall why, I think I can live without it.

billmeek commented 3 years ago

I left out the Fixed line in the commit. Manually closing this.

master 8646ad33eafe345120f58005d6e7783f6448f1e6 fixes/31 bb507cf183e26b5c61fd12b4aa7b2d2434b2489a