Opened 12 years ago
Closed 11 years ago
#11025 closed Bug Report - General (Works for me)
excess (>2) HLS transcode jobs stay permanently queued
| Reported by: | 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 11 years ago by
| Resolution: | → Works for me |
|---|---|
| Status: | new → closed |
Note: See
TracTickets for help on using
tickets.
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.