[mythtv-users] 0.26 recording rules - "not listed"
sgtbundy at gmail.com
Thu Sep 13 12:39:18 UTC 2012
On 3/09/2012 11:11 AM, Carl Lewis wrote:
> But to reproduce the problem (regardless of program guide updates
> being enabled or not)
> 1) Leave mythbackend running for > 24 hours (my be less, but it's hard
> to narrow down)
> 2) Go to the program guide and press record on a program coming up.
> 3) "No Listing" error message.
> If mythbackend has been restarted recently the problem doesn't occur.
> I'll get the wife to try a few records
> today just before the currently scheduled 2pm restart in order to make
> sure it's a duration (24h) rather than a time of day
> thing and post the results.
> I'm running v0.26pre with a last commit in the log of:
> commit ec2ac418bd2d15264ffb99f62d78afa78ec0aa72
> Author: Raymond Wagner <rwagner at mythtv.org>
> Date: Wed Jul 18 01:50:46 2012 -0400
> I've been keeping a sporadic eye on mythtv-commits but seen nothing
> that looked like a fix
> and so haven't updated in a while, but am happy to do so. It's
> non-ratings period so there are multiple evenings
> where nothing is recording.
Just an update on this issue, with much patient help from David (thanks)
I think we have nailed it down.
- using 0.26
- in a GMT+8 or greater offset time zone
- when the scheduler runs, there are programs ending in less than TZ
offset - 8 hours time (i.e GMT+10 = programs ending in the next 2 hours)
- the scheduler is idle for 8 hours or more (or whatever wait_timeout
is set to in MySQL)
The timezone part of it is the scheduler has queries which filters out
programs with end times greater than 8 hours ago. The scheduler uses a
dedicated database connection, and if that happens to timeout with the
scheduler being idle, the connection is automatically reconnected.
However the reconnection code does not reset the database session
time_zone values, which in 0.26 is forced to UTC. You can see when this
occurs with this backend log entry (note it is for the Scheduler).
Sep 13 16:16:32 pvr mythlogserver: mythbackend: I Scheduler
mythdbcon.cpp:243 (Reconnect) MySQL reconnected successfully
The result being that the scheduler SQL queries start filtering
programs relative to local time and not UTC. In my case being GMT+10,
that means anything ending in the next 2 hours is filtered out from
consideration, with the result being those programs suddenly disappear
from the upcoming recordings without a trace. Every time the scheduler
runs from that point (pretty much every deletion or recording ending) it
will strip out anything ending in the next two hours from being recorded.
This also explains why a backend restart fixes it, mostly, not always
but I think that is due to database value changes being commited when
the problem occurs. The restart causes the session to be established
from scratch with the DB session time_zone set correctly by the initial
Also I figure that if your GMT offset is less than +8 hours you won't
see this as the SQL clause wont fail as the calculated time will still
be in the past relative to the program endtime. Also, If your
scheduler activity is enough that the database session does not get to
wait_timeout or get interrupted you probably won't see this.
- modify MySQL and set the wait_timeout value to a higher value (I
have not tested this directly yet).
- set the default database timezone to UTC (seems to work, but may
cause other issues)
- reset your backend during idle times to reduce the impact (painful)
Just an FYI for anyone else who is hitting this issue.
More information about the mythtv-users