[mythtv-users] scheduler settling with conflicts where they are resolvable

Brian J. Murrell brian at interlinx.bc.ca
Fri Sep 9 22:05:06 UTC 2011


On 11-09-09 05:51 PM, Michael T. Dean wrote:
> 
> Not according to the printsched output you posted.   The one and only 
> occurrence of Person of Interest on that schedule is:
> 
> 2011-09-08 08:13:57.424734 I  Person of Interest - Pilot         84-77 WWNY    22 21:00-22:00  2 0 0  A C -3

But WWNY is available on both digital and analog.  Perhaps I am being
misguided by an assumption I have been following all along and that
assumption being that the (schedules direct) guide data for digital
channels and analog channels (i.e. those with the same callsign) will be
equally present.  Perhaps that is not the case?

> So, if you're saying there's now a showing on one of your analog 
> channels, that is probably one of the things that changed that caused 
> the scheduler to "strangely" schedule/place things differently such that 
> you didn't need an override--exactly what Kevin was talking about where 
> more information becomes available allowing MythTV to better optimize 
> usage of resources.  (Of course, before you do add any channel 
> priorities, please read and understand all of 
> http://www.mythtv.org/docs/mythtv-HOWTO-12.html because it will have 
> other effects. :)  Adding a negative priority to the Ontario channels 
> (preferred approach) or a positive priority to the NY channels (a worse 
> approach of attempting to solve the same problem) will actually mean 
> that MythTV may choose to record a -3 priority show on WWNY rather than 
> a -2 priority show that airs only on CJOH.)

Well, I don't care if the scheduler uses Ontario channels vs. NY
channels.  Sometimes one is preferred, other times, the other is.  What
would be ideal (and I know it doesn't happen since I've been down this
road before) is that the scheduler just prefers the channels that yields
the most recording from the multirec tuners.  If that means that the
109- channels is best, great but if it means that the 84- channels are
the best choice, so be it.

> How about you post your capturecard and cardinput tables along with the 
> schedule on your website instead of making me guess at all the possible 
> different configurations you might have that might make a difference?  
> :)  And, really, based on what you've said above, I'd like to see your 
> channel table, too.

Well, perhaps we can short circuit all of this by either confirming or
denying my above assumption.  If it's in fact a false assumption, then
that probably does explain everything.

> If you had done that, your capture cards and inputs should all be 
> starting at 1, not 19.

Hrm.  My experience is that even when you delete all capture cards, it
doesn't actually doesn't reset the index.  Witness:

cardid	videodevice	audiodevice	vbidevice	cardtype	defaultinput
audioratelimit	hostname	dvb_swfilter	dvb_sat_type
dvb_wait_for_seqstart	skipbtaudio	dvb_on_demand	dvb_diseqc_type
firewire_speed	firewire_model	firewire_connection	signal_timeout
channel_timeout	dvb_tuning_delay	contrast	brightness	colour	hue
diseqcid	dvb_eitscan
22	/dev/dvb/adapter0/frontend0	NULL	NULL	DVB	DVBInput
NULL	pvr	0	0	1	0	1	0	0	NULL	0500	3000	0	0	0	0	0	0	0
23	/dev/dvb/adapter0/frontend0	NULL	NULL	DVB	DVBInput
NULL	pvr	0	0	1	0	1	0	0	NULL	0500	3000	0	0	0	0	0	0	0
24	/dev/pvr_mpeg0	NULL	/dev/vbi1	MPEG	Tuner 1	NULL	pvr	00	1	0	0
NULL	0	NULL	0	1000	12000	00	0	0	0	NULL	1
25	/dev/pvr_mpeg1	NULL	/dev/vbi2	MPEG	Tuner 1	NULL	pvr	00	1	0	0
NULL	0	NULL	0	1000	12000	00	0	0	0	NULL	1
20	/dev/dvb/adapter0/frontend0	NULL	NULL	DVB	DVBInput
NULL	pvr	0	0	1	0	1	0	0	NULL	0500	3000	0	0	0	0	0	0	0
21	/dev/dvb/adapter0/frontend0	NULL	NULL	DVB	DVBInput
NULL	pvr	0	0	1	0	1	0	0	NULL	0500	3000	0	0	0	0	0	0	0
19	/dev/dvb/adapter0/frontend0	NULL	NULL	DVB	DVBInput
NULL	pvr	0	0	1	0	1	NULL	0	NULL	0500	3000	0	0	0	0	0	0	0

> So, it seems you may have done that before, but 
> have since changed things around?

Nope.  Not to the best of my recollection.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://www.mythtv.org/pipermail/mythtv-users/attachments/20110909/cd71630c/attachment.bin 


More information about the mythtv-users mailing list