Passes: Lower Priority Wins if Found First (BUG)

Channels DVR Server Troubleshooting
#1

Notice in my passes ordered by priority this situation:

image

You see 2 recordings currently on Priority 3 and 11 set for Priority 1. However, if we look at Priority 1, we can see there are 12 matches:

image

This means that there should be 12 for Priority 1 and 1 for Priority 3. I can prove this by pausing all of the passes and then turning them on again one-by-one from highest priority to lowest:

image

The problem clearly is that once a job aligns to the criteria of one of the lower priority items, it becomes locked to it instead of the next time there is a guide update or a change to the passes to reschedule all upcoming recordings based on priority. The only way I'm able to resolve this is exactly as I demonstrated, which is manual and not desirable.

Submitted diagnostics 8e10ab39-6a41-451d-802f-90605a8af60c, if it is any help.

P.S.
I'm not sure if this is a factor, but the lower priority item is at an earlier time in the schedule. However, in other similar passes I've seen it get locked to a program that was on later (by an entire day), so I don't believe so.

#2

Since you posted in the Community Forum, you should show your Advanced Passes criteria.
Otherwise, only the developers you submitted diags to know what they are.

I've found that the Matches(#) doesn't necessarily mean that pass will record that many airings.
When you have multiple passes that can record the same airing, Queued in the Matches tab doesn't necessarily mean that pass will record it.

1 Like
#3

They are irrelevant to the issue I am focusing on, so I did not include them. It would actually distract from what I'm trying to document and I don't want a tangent around things that only have meaning to me. And this is just one example; I have others. Suffice to say, they are all same SeriesID with differing criteria to control time and station preference order. They work perfectly and have for years; just added some additional sources recently that created this new situation for me.

That being, some stations in the guide have data further out than others, triggering a lower priority pass. But, when the other stations get their data (whether a day or a week later), the higher priority pass is not triggered and the scheduled job remains locked to the lower priority.

Except that is not what I demonstrated nor what I'm talking about. I specifically showed that in this case when I paused and re-enabled the passes that it did do exactly as I said it would, scheduling all the matches (as expected). I could have also shown the before and after in schedule view, but it would be meaningless to someone who doesn't know my stations. This just seemed the simplest way to highlight the problem.

Thus, to reiterate, this is not an issue with my passes or my interpretation of them; this is a problem around how Channels handles passes and scheduling... a gap in the logic tree, if you will. If higher priority pass is triggered, it should cancel lower priority job and schedule higher priority job. Or, more easily, after guide update or change in passes, cancel all jobs and schedule all jobs anew.

#4

I didn't know you could set priorities in passes.
How do you do it?

From my observations/experience, they just get listed in alphabetical order.

#5

I'm interested in this as well.

#6

DVR web UI
DVR > Passes :gear: Adjust Priority

Screenshot 2024-11-28 at 10-47-23 Channels Passes
Screenshot 2024-11-28 at 10-47-23 Channels Passes937×254 13.3 KB

1 Like
#7

Thanks!

How did I never notice it?! :hushed:

#8

So, I've done a little snooping while trying to digest, and I've discovered a few things.

  1. At /dvr/rules, there is a JSON of all the passes with details including an id, pause status, and priority (which is a a declining number, with the highest priority being the total number of passes and the lowest priority being 1)

  2. To pause a pass, you can do a PUT command for /dvr/rules/[ID]/pause

  3. Similarly, to resume a pass, you can do a PUT command for /dvr/rules/[ID]/resume

Given this, I could write a routine for SLM that reads the JSON in number 1, pauses all the passes that are Paused == False, then--in priority order--resume that same list of passes. This could then be scheduled to run every day at the time of my choosing (let's say noon in my case).

This seems all doable, but I'm wondering if there is a simpler approach and straightforward command path I could take? Unless Devs can fix so I don't have to, that is!

#9

If you have never Adjusted your passes Priority, all your passes will show "Priority": 0 in /dvr/rules
Then when you view /dvr/rules, they're listed in ascending "ID" order.
Any new passes you add will have "Priority": 0 (lowest priority).

In that case, I assume the highest priority is the lowest "ID" and lowest priority is highest "ID".
The order they appear in /dvr/rules.

#10

Good to know, I'll keep it in mind!