Opened 7 years ago

Closed 6 years ago

#11025 closed Bug Report - General (Works for me)

excess (>2) HLS transcode jobs stay permanently queued

Reported by: George Nassas <gnassas@…> Owned by: cpinkham
Priority: minor Milestone: unknown
Component: MythTV - HTTP Streaming Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

When 3 or more HLS streams are requested the first two begin transcoding immediately while the remainder go into queued state. Queued HLS transcodes never come out of that state even when active transcodes complete. In fact, if further HLS streams are requested of an idle machine they're processed immediately while the previous, queued, ones stay dormant. Apparently they're ignored forever: I have one that has been queued since July 30.

My mythbox has a dual-core CPU so that 2 limit may be different on a quad core etc.

Change History (1)

comment:1 Changed 6 years ago by cpinkham

Resolution: Works for me
Status: newclosed

Unable to reproduce this, it could have been fixed by thread pool changes since the ticket was submitted.

I was successfully able to use the HLS test page to add 4 concurrent HLS streams and watch my dual-core backend be immediately brought to its knees running 4 simultaneous mythtranscode sessions in the background.

A lot of the current code, including the DB table will likely go away when I get around to completing the on-demand HLS encoder. The DB table is not a real queue, if you restart the backend in the middle of a HLS transcode, it will not restart, the DB table is only for tracking. The HLS transcodes are not handled the same way as normal JobQueue? jobs. Early on, the thought was there to make them such, but on-demand encoding of segments will eliminate a lot of the need for that.

If you can reproduce the issue, please reopen the ticket and I'll try to help on the mailing list.

Note: See TracTickets for help on using tickets.