[mythtv] Services bug with dupin field

Peter Bennett pb.mythtv at gmail.com
Sat Aug 22 15:16:11 UTC 2020

On 8/21/20 9:09 PM, David Engel wrote:
> On Fri, Aug 21, 2020 at 02:48:27PM -0400, Peter Bennett wrote:
>> MythTV Devs
>> The dupin (Dup Scope) field in the record table is used for telling whether
>> to check for duplicates in Recorded, Oldrecorded, or both. It is also used
>> to indicate whether to record only "new episodes" or "new and repeat
>> episodes". The value for "new episodes" is 0x10 and that is "ored" with the
>> other duplicate settings (0x01, 0x02, 0x0f). The toRawString and other
>> similar functions in recordingtypes.cpp assign the value "New Episodes Only"
>> to the value 16 but that is never found, as the 0x10 flag is always set in
>> conjunction with other values, so if you have "Record New Episodes Only"
>> selected, the services apis GetRecordSchedule and GetRecordScheduleList
>> return "Unknown" for Dupin.
>> I propose changing the toRawString and similar routines to return the value
>> "New Episodes Only" when the 0x10 bit is set, regardless of other values,
>> since checking for duplicates is moot if you are recording new episodes
>> only, and "Unknown" is not helpful.
> That's not correct.  New Episodes Only is *not* a filter like the New
> Episodes filter.  Rules using thie New Episodes Only still match all
> episodes.  However, if a program is not new(*), it is marked with
> RecStatus::Repeat.  In contrast, the New Episode filter doesn't match
> repeat programs at all.
> (*)"New" is determined by the repeat flag.  Originally, this was
> defined as something like within 2 weeks of the original air date.
> The details might have changed over the years, but the intent is still
> the same.  Anyway, duplicate checking is still needed when New
> Episodes Only is used as many channels repeat new programs one or more
> times the first week they are shown.
OK I understand now.
>> In the case of the "AddRecordSchedule" method, setting "New Episodes Only"
>> will currently set a value of 0x10. This is invalid since creation of record
>> rules through the frontend never results in this value. In the frontend you
>> always have to also set where to check duplicates, you cannot set it to
>> check duplicates in neither recorded nor oldrecorded (even if you selected
>> "Dont Match Duplicates" in the dup method)
>> I propose changing dupInFromString so that if you set "new episodes only" it
>> combines that with "all recordings".  Otherwise if you create a record rule
>> through the api using "new episodes only" and subsequently edit it through
>> the frontend to take off "new episodes only" you may be left with a rule
>> having an invalid dupin of zero.
>> Any comments or suggestions? Let me know.
> I think the best solutino is to split the new episodes only/new and
> repeat value out into a totally new value.  The trick will be to
> maintain as much backward compatibility as you can.

So, change the service apis so that Dupin returns only "Current 
Recordings" , "Previous Recordings" or "All Recordings" by first 
removing the "New episodes" flag if present. Then add a new tag called 
"NewEpisodesOnly" with boolean true/false value, based on that flag.

The new tag should not affect existing users who should just ignore it.

In the AddRecordSchedule method if they do submit value "New Episodes 
Only" for Dupin and leave out the "NewEpisodesOnly" tag, then continue 
with what it would have done before, set only that value with nothing 
for current, previous or all recordings (for backward compatibility).

Does this sound good?


More information about the mythtv-dev mailing list