[mythtv-users] My scheduler problems are back again

[Mike Perkins]

On 14/01/14 11:06, Mark Perkins wrote:
> Stephen, hope you are still watching this thread.
>
> Thought you might be able to test these changes on your system to see if they make an improvement. I have tried them on mine but a) I don't really have the volume of recordings to genuinely make a big difference, plus b) I am trying to reserve a tuner for LiveTV which was not one of your goals so I've only really got three spare to play with so the improvement is watered down.
>
> Note your original zip file does not seem to be available any more so couldn't double check against the details you posted to see if it these changes were appropriate for you or not (particularly as you have non DVB-T tuners which I can't recall) but shouldn't be any harm in testing (I hope). At least it may give you some idea's.
>
> Firstly, set all your DVB-T tuners to have identical priority of 1. I believe the scheduler always gets the list of tuners in order anyway (which gives a pseudo priority order anyway) so having stepped priority is not really necessary. Plus searching through archives of the mail list I found advice to this effect as well. Ditto for LiveTV if you just want LiveTV to follow the recorder order as much as possible.
>
> Secondly identify which multiplex's you record from most often. I used Mythweb - Statistics for this info.
>
> Next, the idea is essentially to prioritise a multiplex to its own tuner card (where possible). Because the scheduler always gets the tuner list in order my theory is to put the multiplex with the most recordings on the last tuner. The second most used multiplex gets the second last tuner. Etc. The first tuner picks up everything else that doesn't get caught by the earlier tuners.
>
> Note - these are just priorities to guide the scheduler, they don't lock it in to anything (although I assume that badly crafted priorities will make the schedulers life much tougher...)
>
> To do this add Custom Priority rules under (Mythfrontend) Setup - Video - Recording Priorities - Custom Priority.
>
> Add a rule for each multiplex along these lines (changed to suit your multiplex ID's, capturecards etc):
>
> channel.freqid = '???' AND capturecard.videodevice = '/dev/dvb/adapter???/frontend0'
>
> To find the channel frequencies go into mysql and do:
>
> SELECT chanid, channum, freqid FROM mythconverg.channel;
>
> In my setup this works as follows:
> I record most from channel7 multiplex, then channel10, then ABC, then channel9, then SBS.
> These are multiplex 5, 11, 12, 7, 6 respectively.
> I have 3 tuners I want to work with (at the moment I am saving tuner 4 for LiveTV and have set a schedorder and livetvorder accordingly) which are /dev/dvb/adapter0/frontend0, /dev/dvb/adapter1/frontend0, /dev/dvb/adapter2/frontend0 (SELECT cardid, videodevice FROM mythconverg.capturecard);
> So I have two Custom Priority rules:
>
> 1)
> Rule Name: Group_Chan_7_Multiplex
> Priority Change: 2
> Rule statement: channel.freqid = '5' AND capturecard.videodevice = '/dev/dvb/adapter2/frontend0'
>
> 2)
> Rule Name: Group_Chan_10_Multiplex
> Priority Change: 2
> Rule statement: channel.freqid = '11' AND capturecard.videodevice = '/dev/dvb/adapter1/frontend0'
>
> I think the above will work the best (maybe even perfectly) if you have the same number of DVB-T tuners as multiplexes (plus an additional tuner for LiveTV if you wish). Then you should never get the same multiplex on two cards at the same time until you have more recordings on a multiplex than virtual tuners.
>
> I've run out of time now but would be keen to hear your thoughts, particularly if it works or helps in your situation.
>
> PS - disclaimer - backup your database first.
>
If you can run to one tuner per mulitplex there's a much simpler way of 
achieving the above - and that is to make a separate source for each multiplex, 
containing just the channels in that multiplex.

You just assign each source to a tuner (or more if you have them), making sure 
you have enough virtual tuners to cover the max simultaneous recordings on that 
source.

This technique avoids having to muck about with the database at all.

-- 

Mike Perkins