2016-05-22, 02:23 PM
Once again, I'm providing this information for other people who might
find it useful.
I've been doing a lot of playing around with changing priorities
because I want to understand how they work in NextPVR, and what the
quirks are.
Just as an experiment, I used the following sql to change
all the priorities:
This sets the priorities to 100, 102, 104, 106, etc., but leaving them
in their default ordering (i.e., same ordering as oid). This could be
useful because it leaves a "blank" space between consecutive
priorities, so that there's room to move a new recording's priority
into that space.
Once you've change priorities, then you have to use
> NextPVR.exe -recurring
to have the system recompute all the scheduled recordings. This
takes one to two minutes.
You have to do the same after you've inserted a new recurring
recording or deleted the old one. If you make the change through the
GUI, then the recomputation takes place automatically. Otherwise, you
have to force it with the command above.
Here's an example of some SQL that inserts a new recurring
recording:
The tricky thing is to get the GMT times right without screwing
them up, which is very easy to do.
Note the line at the end: "(select max(priority)+2 from
recurring_recording)". This sets the priority of the next recording
to the maximum priority so far, plus 2, to guarantee that priorities
will be unique.
After you do this, (or you delete an existing recurring recording),
then you have to:
> NextPVR.exe -recurring
I've found two bugs in this process. One is that any existing
recordings are duplicated (I'll discuss this below).
The other is that if npvr has previously scheduled a recording as a
"Conflict Alternative Airing," then the conflicting recording is
sometimes, but not always, deleted, so this has to be handled
manually.
find it useful.
I've been doing a lot of playing around with changing priorities
because I want to understand how they work in NextPVR, and what the
quirks are.
Just as an experiment, I used the following sql to change
all the priorities:
Code:
update recurring_recording set priority =
2 * (oid - (select min(oid) from recurring_recording) ) + 100 ;
This sets the priorities to 100, 102, 104, 106, etc., but leaving them
in their default ordering (i.e., same ordering as oid). This could be
useful because it leaves a "blank" space between consecutive
priorities, so that there's room to move a new recording's priority
into that space.
Once you've change priorities, then you have to use
> NextPVR.exe -recurring
to have the system recompute all the scheduled recordings. This
takes one to two minutes.
You have to do the same after you've inserted a new recurring
recording or deleted the old one. If you make the change through the
GUI, then the recomputation takes place automatically. Otherwise, you
have to force it with the command above.
Here's an example of some SQL that inserts a new recurring
recording:
Code:
INSERT INTO "RECURRING_RECORDING"
(name, match_rules, priority)
VALUES ("CNN-6-7pm","<Rules>
<ChannelOID>8947</ChannelOID>
<ChannelName>CNN</ChannelName>
<StartTime>2016-05-21T22:00:00.0000000Z</StartTime>
<EndTime>2016-05-21T23:00:00.0000000Z</EndTime>
<PrePadding>0</PrePadding>
<PostPadding>0</PostPadding>
<Quality>0</Quality>
<Keep>99</Keep>
<Days>SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY</Days>
</Rules>
",
(select max(priority)+2 from recurring_recording)
);
The tricky thing is to get the GMT times right without screwing
them up, which is very easy to do.
Note the line at the end: "(select max(priority)+2 from
recurring_recording)". This sets the priority of the next recording
to the maximum priority so far, plus 2, to guarantee that priorities
will be unique.
After you do this, (or you delete an existing recurring recording),
then you have to:
> NextPVR.exe -recurring
I've found two bugs in this process. One is that any existing
recordings are duplicated (I'll discuss this below).
The other is that if npvr has previously scheduled a recording as a
"Conflict Alternative Airing," then the conflicting recording is
sometimes, but not always, deleted, so this has to be handled
manually.