<div dir="ltr"><div>It looks as if things internal to the myth database are not the problem.</div><div>In the channel table each of the mixed up channels has a different xmltvid, freqid, and mplexid.  Each has the same sourceid (I have only 1).</div><div>In dtv_multiplex each mplexid has its own frequency.</div><div><br></div><div>Looking in the program table, the first overlap (same show at same time)  was 2021-02-27 06:00, although it doesn't seem to have become regular until  2021-02-28 18:30:00.  So the recent lockup may have nothing to do with the problem.  The entries could have been mangled after they were created, but my notes show I noticed problems with 65.3 listings on 02-28 just after I created a rule.  This was NOT while mythfilldatabase was running, which does suggest a local problem.<br></div><div><br></div><div>I had a bunch of network problems in the week before that, and the partition the database was on filled a month before that.</div><div><br></div><div>And I haven't made any attempt to verify what's in ~mythtv/.mythtv/cache, which has lots of stuff for mythfilldatabase.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 6, 2021 at 9:40 AM Ross Boylan <<a href="mailto:rossboylan@stanfordalumni.org">rossboylan@stanfordalumni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I launched mythfrontend on the same machine that hosts the backend and database.  The whole machine locked up.  When I restarted it I found that the listing for channel 65.2 (qubo) was just a copy of the listing for 66.3 (Bounce).</div><div><br></div><div>I looked in the logs for myth and for the database (mariadb).  The latter show recovery from a crash, but other than that I see nothing that looks related.</div><div><br></div><div>Tried mythfilldatabase --refresh all.  No change.  Waited a day so that it could fetch new listings, but the last available listings still show the same pattern.</div><div><br></div><div>There is at least one related report about problems like this with Schedules Direct, <a href="https://code.mythtv.org/trac/ticket/11509" target="_blank">https://code.mythtv.org/trac/ticket/11509</a> which references <a href="http://lists.mythtv.org/pipermail/mythtv-users/2013-March/347938.html" target="_blank">http://lists.mythtv.org/pipermail/mythtv-users/2013-March/347938.html</a>, but that's from before the XML TV grabber.  So I'm not sure it's relevant.</div><div><br></div><div>I'd love to hear about solutions, or even about how I could figure out where things have got mucked up.</div><div><br></div><div>Thanks.</div><div>Ross</div><div><br></div><div>Setup:<br></div><div>backend is 30.0-dmo4 with some code I backported so I could use Python 3.</div><div>I use SchedulesDirect in the US with tv_grab_zz_sdjson</div><div>Debian/buster</div><div><br></div><div><br></div></div>
</blockquote></div>