[mythtv] MythWeb - Overrides on title search recordings not
bjm at lvcm.com
Mon Jun 6 00:53:34 UTC 2005
Christian Hack wrote:
> I have a number of title search recordings setup (type=4, search=2)
> When I use the "Don't Record" option from the Upcoming Recordings screen in
> MythTV they work fine and correctly create a type=8 entry in the record
> table. MythWeb correctly displays them with a red box and all is well and
> the recording doesn't happen.
> Using the Activate or Default options from MythWeb correctly removes the
> type=8 entry and the show is back in the schedule (i.e. removing the
> override entry).
> If I use the Don't Record option from MythWeb however, it creates the type=8
> entry in the DB but neither MythWeb or MythTV recognise it as a disabled
> 1) I notice that MythTV fills the parentid field correctly. MythWeb does
Currently, this is only needed for FindDaily or FindWeekly with a
search rule so that it can tell that a matching showing has been
overridden and it does not need to record another showing in the
same period. This is a recent change and not addressed yet in
mythweb but it would need to be fixed for a type=9 or type=10.
> 2) MythWeb creates copies the search column whereas MythTV leaves it as 0.
This is more likely the problem. An override is like a single that
inherits the attributes of the recurring rule and as a single showing
thingy, it should always be search=0.
> Apart from that I can't see any difference in the database entry. So why
> doesn't this work?
Because a search type expects the description field to hold the
search phrase but it instead has the (correct) description for
that showing. The full description, of course, is not a matching
string for the title field.
> All record entries with (search=0) work fine in both MythWeb and MythTV.
> It's only the search=2 ones that are broken.
This needs to be fixed in mythweb so that when creating an override,
'search' should always be set to '0'. There could also be a safe
guard in the scheduler so that the search value is ignored for
> I've tried to understand the code, but can't see why two identical entries
> (apart from recordid) in the table don't do the same thing. I thought I
> could easily fix it myself but if the database entry is correct, why doesn't
> MythTV recognise it?
Look for where it prepares the fields to add an override to the
record table and explicitly set search=0 if type=7 or type=8 and
bonus points if you can set parentid to the recordid of the existing
recurring rule at this same point in the code. Send Chris your
patch when you get it working.
More information about the mythtv-dev