Mailing List Archive

Scheduling issue after upgrading
Having just upgraded to fixes/33, and of necessity done a rescan, I discover that suddenly some of
my recording rules have stopped functioning.

My specific example: 'Van der Valk' on ITV1 at 20:00 tonight (Sunday)(UK). I have recorded all the
previous episodes and series using this recording rule without any problem.

Looking at the rule, I have 'Record any' selected and the only box ticked was 'this channel'.
Removing the tick shows up the missing recording.

I'm wondering exactly which field the 'this channel' selection operates on, and whether doing a
rescan changes, for example, the chanid or other field used for matching.

--

Mike Perkins

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Scheduling issue after upgrading [ In reply to ]
On Sun, Jul 2, 2023 at 5:25?AM Mike Perkins <mikep@randomtraveller.org.uk>
wrote:

> Having just upgraded to fixes/33, and of necessity done a rescan, I
> discover that suddenly some of
> my recording rules have stopped functioning.
>
> My specific example: 'Van der Valk' on ITV1 at 20:00 tonight (Sunday)(UK).
> I have recorded all the
> previous episodes and series using this recording rule without any problem.
>
> Looking at the rule, I have 'Record any' selected and the only box ticked
> was 'this channel'.
> Removing the tick shows up the missing recording.
>
> I'm wondering exactly which field the 'this channel' selection operates
> on, and whether doing a
> rescan changes, for example, the chanid or other field used for matching.
>
> --
>
> Mike Perkins
>
>
I have had issues with "This Channel" after a rescan. I always check that
it's not checked. I run into this a lot when I travel by RV and have to
rescan in each TV territory I visit. If you choose the most flexible
options, it will keep recording after you arrive in a new town with
different channels after you do the rescan.

It's useful to use "this Channel" when you have 2 stations broadcast the
same program but one station does a poor job. "This Channel" can force it
to work with the one you want.

Jim A
Re: Scheduling issue after upgrading [ In reply to ]
On 02/07/2023 11:07, James Abernathy wrote:
> On Sun, Jul 2, 2023 at 5:25?AM Mike Perkins <mikep@randomtraveller.org.uk>
> wrote:
>
>> Having just upgraded to fixes/33, and of necessity done a rescan, I
>> discover that suddenly some of
>> my recording rules have stopped functioning.
>>
>> My specific example: 'Van der Valk' on ITV1 at 20:00 tonight (Sunday)(UK).
>> I have recorded all the
>> previous episodes and series using this recording rule without any problem.
>>
>> Looking at the rule, I have 'Record any' selected and the only box ticked
>> was 'this channel'.
>> Removing the tick shows up the missing recording.
>>
>> I'm wondering exactly which field the 'this channel' selection operates
>> on, and whether doing a
>> rescan changes, for example, the chanid or other field used for matching.
>>
>> --
>>
>> Mike Perkins
>>
>>
> I have had issues with "This Channel" after a rescan. I always check that
> it's not checked. I run into this a lot when I travel by RV and have to
> rescan in each TV territory I visit. If you choose the most flexible
> options, it will keep recording after you arrive in a new town with
> different channels after you do the rescan.
>
> It's useful to use "this Channel" when you have 2 stations broadcast the
> same program but one station does a poor job. "This Channel" can force it
> to work with the one you want.
>
The reason I tend to tick "this channel" for some of my rules is that we have a lot of channels
showing nothing but repeats. For example, I record new episodes of "Midsomer Murders" but if I
didn't specify "this channel" I'd have loads of matches for old episodes going back decades, which
I'd then have to say, "do not record" for every one.

It might be useful to have a flag saying, "I have this channel but don't schedule anything on it
unless I actually ask for it", similar perhaps to the "inactive" flag you can set per recording rule.

--

Mike Perkins


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Scheduling issue after upgrading [ In reply to ]
On Sun, Jul 2, 2023 at 6:59?AM Mike Perkins <mikep@randomtraveller.org.uk>
wrote:

> On 02/07/2023 11:07, James Abernathy wrote:
> > On Sun, Jul 2, 2023 at 5:25?AM Mike Perkins <
> mikep@randomtraveller.org.uk>
> > wrote:
> >
> >> Having just upgraded to fixes/33, and of necessity done a rescan, I
> >> discover that suddenly some of
> >> my recording rules have stopped functioning.
> >>
> >> My specific example: 'Van der Valk' on ITV1 at 20:00 tonight
> (Sunday)(UK).
> >> I have recorded all the
> >> previous episodes and series using this recording rule without any
> problem.
> >>
> >> Looking at the rule, I have 'Record any' selected and the only box
> ticked
> >> was 'this channel'.
> >> Removing the tick shows up the missing recording.
> >>
> >> I'm wondering exactly which field the 'this channel' selection operates
> >> on, and whether doing a
> >> rescan changes, for example, the chanid or other field used for
> matching.
> >>
> >> --
> >>
> >> Mike Perkins
> >>
> >>
> > I have had issues with "This Channel" after a rescan. I always check that
> > it's not checked. I run into this a lot when I travel by RV and have to
> > rescan in each TV territory I visit. If you choose the most flexible
> > options, it will keep recording after you arrive in a new town with
> > different channels after you do the rescan.
> >
> > It's useful to use "this Channel" when you have 2 stations broadcast the
> > same program but one station does a poor job. "This Channel" can force it
> > to work with the one you want.
> >
> The reason I tend to tick "this channel" for some of my rules is that we
> have a lot of channels
> showing nothing but repeats. For example, I record new episodes of
> "Midsomer Murders" but if I
> didn't specify "this channel" I'd have loads of matches for old episodes
> going back decades, which
> I'd then have to say, "do not record" for every one.
>
> It might be useful to have a flag saying, "I have this channel but don't
> schedule anything on it
> unless I actually ask for it", similar perhaps to the "inactive" flag you
> can set per recording rule.
>
> --
>
> Mike Perkins
>
>
That is the same reason I use it. Reruns get tagged as "NEW" on some
stations. When I moved my Production backend to Ubuntu 22.04 and Mythtv v33
over a year ago I did have to rescan and then import my database and
recordings. That really messed things up, so I went back and started over
fresh and then imported my database and recordings. And then I deleted all
my tuners and added everything back. Because the channels have some
invisible-to-me difference, I had to fix any rules where "This channel" was
needed. There were only a few, luckily.

I didn't have that issue moving to v34 (Master). I just changed the ppa to
34 and did an upgrade. It could be that it's just the mix of shows on
right now. I have had issues with reruns of "Late Night" showing up as new
when they are on strike and not recording. I think the broadcasters are
just playing with us.

Jim A
Re: Scheduling issue after upgrading [ In reply to ]
On Sun, 2 Jul 2023 10:24:28 +0100, you wrote:

>Having just upgraded to fixes/33, and of necessity done a rescan, I discover that suddenly some of
>my recording rules have stopped functioning.
>
>My specific example: 'Van der Valk' on ITV1 at 20:00 tonight (Sunday)(UK). I have recorded all the
>previous episodes and series using this recording rule without any problem.
>
>Looking at the rule, I have 'Record any' selected and the only box ticked was 'this channel'.
>Removing the tick shows up the missing recording.
>
>I'm wondering exactly which field the 'this channel' selection operates on, and whether doing a
>rescan changes, for example, the chanid or other field used for matching.

The "This channel" option works on the record.station value - it has
to match the channel.callsign value.

To work this out, I used SQL to change the record.station of one of my
recording rules that has "This channel" set (ie where (record.filter &
1024) = 1024) and was recording later in the week. Then I ran
mythutil --resched and looked to see if it was still recording, and it
was not. Then I changed the record.filter to 0 and run mythutil
--resched again and then it was recording even with the wrong
record.station value, and the rule was displayed as recording from
channel "Any". When I tried changing the record.chanid value, nothing
happened - it was still scheduled to record.

So it looks like the rescanning is changing the channel.station values
and that is what is messing up the "This channel" rules. That is down
to the channel having updated the data it broadcasts to identify
itself. So it looks like there is a defect in how MythTV handles
rescanning. If a channel changes its broadcast name, but remains on
the same multiplex and serviceid, then I think that the scanning code
should automatically be updating all the recording rules where
record.station matches the old name to be the new name.

I very rarely rescan exactly for this sort of reason, as channels can
and do change their names occasionally, even when they are not
changing their content. When I do rescan, I first do a manual station
scan using external software (a script that uses dvbtune and scan-s2)
to see what the channel names are and if they have changed. Then
after the MythTV rescan, I manually update the record.station values
to match any new names for old channels.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Scheduling issue after upgrading [ In reply to ]
Hoi Stephen,

Sunday, July 2, 2023, 2:08:07 PM, you wrote:

> On Sun, 2 Jul 2023 10:24:28 +0100, you wrote:

>>Having just upgraded to fixes/33, and of necessity done a rescan, I discover that suddenly some of
>>my recording rules have stopped functioning.
>>
>>My specific example: 'Van der Valk' on ITV1 at 20:00 tonight (Sunday)(UK). I have recorded all the
>>previous episodes and series using this recording rule without any problem.
>>
>>Looking at the rule, I have 'Record any' selected and the only box ticked was 'this channel'.
>>Removing the tick shows up the missing recording.
>>
>>I'm wondering exactly which field the 'this channel' selection operates on, and whether doing a
>>rescan changes, for example, the chanid or other field used for matching.

> The "This channel" option works on the record.station value - it has
> to match the channel.callsign value.

> To work this out, I used SQL to change the record.station of one of my
> recording rules that has "This channel" set (ie where (record.filter &
> 1024) = 1024) and was recording later in the week. Then I ran
> mythutil --resched and looked to see if it was still recording, and it
> was not. Then I changed the record.filter to 0 and run mythutil
> --resched again and then it was recording even with the wrong
> record.station value, and the rule was displayed as recording from
> channel "Any". When I tried changing the record.chanid value, nothing
> happened - it was still scheduled to record.

> So it looks like the rescanning is changing the channel.station values
> and that is what is messing up the "This channel" rules. That is down
> to the channel having updated the data it broadcasts to identify
> itself. So it looks like there is a defect in how MythTV handles
> rescanning. If a channel changes its broadcast name, but remains on
> the same multiplex and serviceid, then I think that the scanning code
> should automatically be updating all the recording rules where
> record.station matches the old name to be the new name.

> I very rarely rescan exactly for this sort of reason, as channels can
> and do change their names occasionally, even when they are not
> changing their content. When I do rescan, I first do a manual station
> scan using external software (a script that uses dvbtune and scan-s2)
> to see what the channel names are and if they have changed. Then
> after the MythTV rescan, I manually update the record.station values
> to match any new names for old channels.
> _______________________________________________

I haven't used the scan functionality for years for that kind of
reasons. Its not only the channel identifiers, but also the sourceid
that can be relevant.
I keep an sql backup of the source, transports and channels an now and
then do a scan with my hdhomerun. I created a script that just gives
me the diffs. If needed I edit a copy of the backup, backup and dump
those tables and restore the edited tables. Of cause with the backend
offline. It rarely fails and then I have the backups to start the
process anew.


Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org