[mythtv-commits] Ticket #13121: Sat>IP client support

[MythTV]

#13121: Sat>IP client support
--------------------------------+-------------------------------
 Reporter:  cg@…                |          Owner:  Klaas de Waal
     Type:  Patch - Feature     |         Status:  assigned
 Priority:  minor               |      Milestone:  32.0
Component:  MythTV - Recording  |        Version:  Master Head
 Severity:  low                 |     Resolution:
 Keywords:                      |  Ticket locked:  0
--------------------------------+-------------------------------

Comment (by Klaas de Waal):

 With the backup scripts from fe31nz my system works nearly perfect.
 However, the underlying problem is still there and it is about what runs
 in which thread, as already indicated in comment:29.

 Sat>IP is started at system start in the CoreContext thread at the moment
 where all capture cards are opened and tuned just to see if they are
 present. The Sat>IP streams are never closed.

 The CoreContext thread is where all non-recording activities of
 mythbackend, such as the housekeeping tasks, are done. This explains why
 the Housekeeper tasks do influence the Sat->IP recordings and this also
 explains why such a large UDP input buffer, 8Mbyte, is needed to avoid
 packet loss.

 The recording is started in the TVRecEvent thread. In this thread we have
 to read the control stream to check if the tuner is in lock. This does not
 work if the UDP socket is created in the TVRecEvent thread; it looks like
 there is no event handler in this thread but it can also be a bug in my
 test code.

 At least reading the media stream data from the UDP socket has to be moved
 in the SatIPStreamHandler::run thread but maybe it is easier to recreate
 also reading the control stream in this thread once the tuner is locked.

-- 
Ticket URL: <https://code.mythtv.org/trac/ticket/13121#comment:66>
MythTV <http://www.mythtv.org>
MythTV Media Center