[mythtv-users] scheduler confusion
Mark Perkins
perkins1724 at hotmail.com
Fri Sep 5 22:50:58 UTC 2014
> -----Original Message-----
> From: mythtv-users-bounces at mythtv.org [mailto:mythtv-users-
> bounces at mythtv.org] On Behalf Of Stephen Worthington
> Sent: Saturday, 6 September 2014 3:20 AM
> To: Discussion about MythTV
> Subject: Re: [mythtv-users] scheduler confusion
>
> On Fri, 05 Sep 2014 11:59:39 -0400, you wrote:
>
> >On 09/05/2014 11:15 AM, Mark Perkins wrote:
> >> From: Michael T. Dean
> >>> On 09/05/2014 08:25 AM, Michael T. Dean wrote:
> >>>> On 09/05/2014 07:52 AM, Mark Perkins wrote:
> >>>>> To be honest I don't think the ordering is causing your problem,
> >>>>> but the recommendation is that if all the tuners are equally
> >>>>> functional then that should be reflected in the order priority.
> >>>> Though not all having the same value. If you have 4 physical
> >>>> capture devices, all equally functional and equivalent to one
> >>>> another, you should set them up as having schedule orders of 1, 2,
> >>>> 3, and 4. Then, you would likely choose Live TV order of 4, 3, 2,
> >>>> 1 to ensure you take the least-likely-to-be-chosen-for-recordings
> >>>> device first when you enter Live TV (so it's also the least likely
> >>>> to be already locked to a mux).
> >>> Oh, and BTW, this is exactly how MythTV will configure your system
> >>> by default. If it's not already this way, I highly recommend you
> >>> "Delete all capture cards" (not "Delete all capture cards
> >>> on<hostname>") and re-create them to ensure they're fixed properly so
> you don't:
> >>>> Choosing exactly the same schedule order value for the different
> >>>> physical devices may break multirec placement efficiency.
> >>> break multirec.
> >> Mike, this appears to be the opposite answer to what you gave me when
> >> I went through this exact issue earlier this year. In particular you
said:
> >>
> >> MythTV, in absence of instruction to do otherwise, will always
> >> schedule recordings on the first-available input that can be used for
> >> that recording. So, if it's doing otherwise, you've told it to do
otherwise.
> >
> >Yes, so when it puts a recording from mux 1 on physical device
> >1/virtual tuner 1 and a recording from mux 2 on physical device
> >2/virtual tuner 4 and it tries to place another recording from mux 1,
> >it will do so on physical device 1/virtual tuner 2, which means it
> >shares the same physical tuner and maximized multirec efficiency.
> >
> >The only time this is "broken" is when you have a so many concurrent
> >recordings on a given mux that at least one of them spills over to
> >another physical device (say you now have devices 1 and 3 recording
> >from mux 1) and the recording on the "later" (= higher scheduling
> >order, in this example device 3) device has a longer run time than all
> >of the recordings on the earlier device (device 1). At the point the
> >final recording on device 1 finishes, device 3 is being used for mux 1,
> >but if a new recording from mux 1 starts when device 1 (and 2) is not
> >being used for recording from other mux'es, it will start the new
> >recording on device 1, so you'll still have devices 1 and 3 used for
> >the same mux until the recording on device 3 finishes. In other words,
> >you'll need both a spill over (more concurrent recordings on a given
> >mux than virtual tuners on the physical device) /and/ the latest-ending
> >recording must be placed on the higher-schedule-order device /and/ a
> >new recording from the same mux must start before that (latest-ending)
> >recording on the higher-schedule-order device ends /and/ at least one
> >lower-schedule-order devices must be
> >unoccupied/not-in-use-for-a-recording-on-a-different-mux at the time.
> >
> >This is enough of a corner case that it's really not worth trying to
> >"fix"--especially as there are nearly as many ways that assigning the
> >new recording to the later-schedule-order device will break other
> >future recordings as there are ways that the above issue will actually
> >break recordings (where "break," here, tends to mean "cause conflicts").
>
> This explanation is how I thought it was supposed to work. But for me, it
> demonstrably did not always work like this. I have three DVB-T tuners
with
> five multirec tuners each. When I was having problems, here in New
Zealand
> we had only three muxes being transmitted. So if it actually worked as
> described, each mux should get one physical tuner only (as long as there
> were enough multirec tuners, which was always the case). But until I
added
> the suggested powerpriority rules to fix it, in complex situations the
> scheduler would assign two physical tuners to one mux, and would run out
of
> tuners. I was getting situations like this at least once or twice a week.
>
> It is possible that there was a bug that has now been fixed, as I think
this was
> with the initial versions of 0.27, and I have not tried removing my
> powerpriority rules with the latest 0.27/fixes to see if it still happens.
The
> scheduler dumps I did at the time are still on my web site:
>
> http://www.jsw.gen.nz/mythtv/scheduling_problem_2013-12-5.zip
>
> These dumps clearly show the use of two physical tuners for the same mux
> when there were still available multirec tuners on the physical tuner
first
> assigned to the mux.
>
> The fix was to use powerpriority rules that guide the scheduler to assign
a
> specific physical tuner for each mux:
>
> mysql> select * from powerpriority;
>
+----------------------+-------------+--------------------------------------
----------------
> -+
> | priorityname | recpriority | selectclause
|
>
+----------------------+-------------+--------------------------------------
----------------
> -+
> | TVNZ multiplex | 20 | channel.mplexid=2 and cardinputid
in
> (1,2,3,4,5) |
> | Mediaworks multiplex | 20 | channel.mplexid=3 and cardinputid
in
> (11,12,13,14,15) |
> | Kordia multiplex | 20 | channel.mplexid=4 and cardinputid
in
> (6,7,8,9,10) |
>
+----------------------+-------------+--------------------------------------
----------------
> -+
> 3 rows in set (0.00 sec)
>
> Note that the mplexid values above have changed due to retuning and the
> adding of a fourth mux in NZ since I created those dumps. The mplexid
> values at the time of the dumps will have been 1, 2 and 3, I believe.
>
> See
> http://www.mythtv.org/pipermail/mythtv-users/2013-
> December/357428.html
> for the original discussion of this. On reading it again now, it looks
like there
> was some further discussion after I stopped looking at the thread when
> David Engel's suggested fix worked for me.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
I see the same behaviour as Stephen. At the time I expected it to work the
way Mike described but that was not what I was seeing in practice (Dec 13 /
Jan 14) hence the earlier threads. Nor what it seemed others were seeing in
practice.
I still don't see the behaviour as described by Mike. It only takes three
straightforward recordings to demonstrate. In the below example there are no
other subsequent recordings until 8 o'clock so with just three recordings I
can get the same multiplex (ABC2 and ABC3 are the same multiplex) to tie up
two physical tuners where each physical tuner is setup for five multirec:
$ mythbackend --printsched
2014-09-06 06:06:17.846510 C mythbackend version: fixes/0.27
[v0.27.1-7-g41d04b6] www.mythtv.org
2014-09-06 06:06:17.846532 C Qt version: compile: 4.8.4, runtime: 4.8.6
2014-09-06 06:06:17.846538 N Enabled verbose msgs: general
2014-09-06 06:06:17.846554 N Setting Log Level to LOG_INFO
2014-09-06 06:06:17.859422 I Setup Interrupt handler
2014-09-06 06:06:17.859449 I Setup Terminated handler
2014-09-06 06:06:17.859467 I Setup Segmentation fault handler
2014-09-06 06:06:17.859455 I Added logging to the console
2014-09-06 06:06:17.859481 I Setup Aborted handler
2014-09-06 06:06:17.859499 I Setup Bus error handler
2014-09-06 06:06:17.859513 I Setup Floating point exception handler
2014-09-06 06:06:17.859530 I Setup Illegal instruction handler
2014-09-06 06:06:17.859546 I Setup Real-time signal 0 handler
2014-09-06 06:06:17.859599 N Using runtime prefix = /usr/local
2014-09-06 06:06:17.859623 N Using configuration directory =
/home/mythtv/.mythtv
2014-09-06 06:06:17.859710 I Assumed character encoding: en_AU.UTF-8
2014-09-06 06:06:17.860165 I Using localhost value of mark-EP35-DS3
2014-09-06 06:06:17.860217 I Testing network connectivity to '192.168.1.9'
2014-09-06 06:06:17.861166 I Starting process manager
2014-09-06 06:06:17.863686 I Starting process signal handler
2014-09-06 06:06:17.863801 I Starting IO manager (write)
2014-09-06 06:06:17.863927 I Starting IO manager (read)
2014-09-06 06:06:17.961151 I New Client: (#1)
Retrieving Schedule from Master backend.
2014-09-06 06:06:17.980324 N Setting QT default locale to en_AU
2014-09-06 06:06:17.980389 I Current locale en_AU
2014-09-06 06:06:17.980427 E No locale defaults file for en_AU, skipping
2014-09-06 06:06:17.981068 I New static DB connectionDataDirectCon
2014-09-06 06:06:17.983749 I MythCoreContext: Connecting to backend server:
192.168.1.9:6543 (try 1 of 1)
2014-09-06 06:06:17.985672 I Using protocol version 77
2014-09-06 06:06:18.007946 I --- print list start ---
2014-09-06 06:06:18.007952 I Title - Subtitle Ch
Station Day Start End S C I T N Pri
2014-09-06 06:06:18.008029 I Dora The Explorer 9 Nine
Ad 06 06:30-07:00 1 1 1 A 1 0
2014-09-06 06:06:18.008069 I Yo Gabba Gabba! - Pets 22 ABC2
/ 06 06:30-07:30 1 6 6 A 6 0
2014-09-06 06:06:18.008107 I Kid Vs Kat - Down The Drain 23 ABC3
06 07:10-07:20 1 1 1 A 1 0
If I get time in the next few days I will setup a schedule to put
simultaneous recordings from a single multiplex across 3 or 4 physical
tuners.
More information about the mythtv-users
mailing list