Can't understand priority

[djv6ru]

Hello

I have a single host setup and I am posting jobs to the api.
I have included the priority to post body like this:
"priority": "1"

I am printint %i_job_priority% to file, to monitor if the priority from post is actually considered, but the printed priority value is always the one that set in the workflow properties, so the priority from the api post is ignored it seems.

Am I completely missing the point or working principles of priority argument?

[admin]

Hi djv6ru,

Thank you for using FFAStrans and welcome to the forum!

This is a bug But thanks for reporting. To work around the problem (until a new release is out) you could try and put a priority change to the job right after you get the job id. That should work. There might be a small delay (2-3 secs) before it's fully updated to the new prio.

Code: Select all

{
    "action": "priority",
    "value": 1
}

PUT to /api/v2/jobs/<job_id>

-steinar

[djv6ru]

I tried to put the priority after getting the id, but the /api/v2/jobs endpoint only seems to have access to jobs that are already rendering not to those that are queued. So if I queue the job and want to move it up in the queue by setting priority, this endpoint doesn't allow that. And setting priority on an already rendering job doesn't do anything to make the job complete faster if I understand the documentation correctly?

[emcodem]

Aye sorry for the delay, our viking steinar is already caught in a snow castle and i was busy adding new features to webint

You are absolutely correct with your observations. There is an "undocumented" endpoint /api/v2/tickets which reads all files recursively in db/tickets folder. The top level field "pending" will contain an array of "queued" jobs submitted from API or Manual submit but not Watchfolders (they manage their own queue).
Not sure tough if the possible workaround that steinar proposes here is also valid for pending tickets @admin ?

[admin]

An already running job will change priority at runtime. This also means it will try to change the priority of child jobs, like ffmpeg encoding. However, to avoid stalling the system with high priority on CPU-intensive operations, the maximum possible priority for child processes will be "normal". The job itself can have a higher priority, which will be beneficial for it to be executed before other jobs.

FFAStrans is meant to change priority on pending and queued jobs (two different technical concepts in FFAStrans), which are submitted from API or GUI. It does NOT work with watchfolder before they're actually running. However, there is a bug with that logic in version 1.4.0.7, so it doesn't work as expected. This issue is already fixed for the next release.

To get consistent priority behavior, you must wait for the update.
Sorry for any inconvenience.

-steinar

[djv6ru]

Yeah, as I am working with a bunch of short clips, and there might be instances where I need to prioritize some, but there are 100 already queued, then currently waiting for the update is the only option I guess. Although I think, I can create two identical workflows and give a higher priority in properties to one and then post to the higher priority jobs to that one and achieve prioritization that way.

No inconvenience, it is a awesome piece of kit as it is .
Do you have a realease date/time for the next update?

[emcodem]

well we don't have release schedules but usually in winter we are more bored than in summertime so chances for a release while it's cold on northern
hemisphere are quite good i guess