[mythtv-users] 0.26 recording rules - "not listed"

[Adrian Saul]

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.

The conditions:
   - 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[32223]: 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 
connection code.

  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.

Possible workarounds:
   - 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.

Cheers,
   Adrian