Mailing List Archive

#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):

My backup script, dating from 2011, makes a backup with
mythconverg_backup.pl but it also makes a second backup with mysqldump on
the entire mythconverg database.
The backup with mysqldump on the entire database causes the problems as
this blocks the Housekeeper task. The Housekeeper tasks then blocks the
complete mythbackend.

What happens is this:
- Sat>IP recording in progress
- The backup with mysqldump of the entire database starts
- Sat>IP recording continues
- The Housekeeper starts (it does this every minute)
- After the last log message line of the Housekeeper mythbackend is frozen
- Sat>IP recording stops
- The backup with mysqldump finishes
- mythbackend unfreezes
- Sat>IP fails with "sendMessage read: RTSP/1.0 454 Session Not Found" for
the keepAlive message.

The Sat>IP box has a session timeout of 60 seconds; therefore a keepAlive
message is sent every 30 seconds.
The keepAlive messages are not sent when mythbackend is frozen and thus
the session times out when the frozen period is long enough.
The Sat>IP box is then idle while mythbackend thinks it is still
recording.

This problem showed up when I started to use the Sat>IP on my living room
system which has a much larger database than my development system and
hence the backup takes much longer.

The first solution, removing the mysqldump of the complete database and
using only the mythconverg_backup.pl, is now under test.

A better solution is to use the backup scripts of fe31nz: do first a
backup to a SSD and then later do the compression and the copying.
To be tested.

The Sat>IP code can be improved so that it can recover from the "Session
Not Found".
If this happens the current recording should be terminated and it should
be possible to start a new recording.

Also the Housekeeper task can be investigated. After starting the
mysqldump backup the recording continues, but only when the Housekeeper
task runs mythbackend completely freezes. Even when the Houskeeper task is
blocked it should not need to block recordings.

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

#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

#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):

When I run mythbackend on a laptop then the connection to the SatIP box
does not survive a sleep/wakeup (closing the lid and opening it later)
cyclus; the backend needs to be started again then. A HDHomeRun just
starts working again after the lid is opened so this is something that
does need to be fixed.

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

#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 jksj461):

I have been using this feature with a Digibit R1 for 10 months now and
the performance is still excellent. I use all 4 sources and can
successfully record 5 HD channels.

In the last 5 weeks there have been 247 recordings.

Of these 237 are marked as good. They have an average packet loss < 1 most
recordings showing 0 worst case 15.

Of the 10 damaged recordings they occur at two instances in the 5 week
period when the Digibit got tired.

Probably had gone too long between resets (was being done weekly).

An indicator of the Digibit box getting tired is that all 4 tuner lights
are not lit.
I note from your comments above that a tuner is never closed once
initialised.
So should all 4 lights stay on?
I have seen them go out after recordings finished but the box continues to
work.
I am now testing power cycling the Digibit daily to see if that resolves
the issue.

Do you think a daily power cycle is the best approach.

I know the web interface allows the user to reset it but I am looking for
something I can automate.

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

#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 jksj461):

At present the backend still attempts to use a tuner if the sat/ip box is
powered off at backend startup.
It would be useful if it recognises that it is not available and marks it
failed which I would hope would allow another source to be used.

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

#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):

Commit aaacfb75d81205406538052a588b63c45aed284f

Check SatIP channel presence at backend start

At the start of mythbackend, ping each SatIP channel
to verify that the SatIP box can be reached on the network.
This is done similar to how it is done for the Vbox.
Give the UDP buffer size message only once instead
of once per SatIP channel.

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

#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 jksj461):

Thanks for Check SatIP channel presence at backend start.
Tested on mythbackend version: master [v32-Pre-3262-g484138c0d2] with
minisatip as server.

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

#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):

Remove extraneous ? character in Sat>IP OPTIONS message

The extraneous ? character occurs when the QUrl query is initialized to an
empty string "".
Fixed by replacing the "" by a QString() in the OPTIONS and the PLAY query
composition.
Thanks to Mike Bibbings for reporting and fixing this for the TEARDOWN
command,
see https://code.mythtv.org/trac/ticket/13121#comment:20

Refs #13121

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