Difference between revisions of "MythTV System Events"
(Use new template) |
(mythutil now used to send test systemevents) |
||
(4 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
+ | {{User Manual New TOC}} | ||
+ | |||
+ | {{UpToDate 0.27}} | ||
+ | |||
+ | This article describes the System Events page of MythTV Setup. | ||
+ | |||
+ | This is an optional setting and an advanced usage. You do not need to do anything here for basic recording and playback in MythTV. | ||
+ | |||
MythTV System Events are a new feature in MythTV 0.23. Historically MythEvents have been used to communicate between components of the system when blocking was not required for proper operation. Now it is possible for the end user to tap into a number of events as well as defining up to ten keypress events. These events are handled by running an external script with appropriate parameters. MythTV System Events are configured on a per box basis so each machine can have it's own system specific handlers. | MythTV System Events are a new feature in MythTV 0.23. Historically MythEvents have been used to communicate between components of the system when blocking was not required for proper operation. Now it is possible for the end user to tap into a number of events as well as defining up to ten keypress events. These events are handled by running an external script with appropriate parameters. MythTV System Events are configured on a per box basis so each machine can have it's own system specific handlers. | ||
+ | |||
+ | Beginning with release 0.26, timestamps of recordings are stored in UTC. Applications that use xxxTIME parameters to directly index the database will need to either handle timezone conversion internally, or switch to the respective xxxTIMEUTC parameters. See [[UTC]]. | ||
== Available Events == | == Available Events == | ||
Line 5: | Line 15: | ||
These are the currently defined events: | These are the currently defined events: | ||
− | * | + | * Any event |
− | * | + | * Client connected to master backend |
− | * | + | * Client disconnected from master backend |
− | * | + | * Keystroke event #1 |
− | * | + | * Keystroke event #2 |
+ | * Keystroke event #3 | ||
+ | * Keystroke event #4 | ||
+ | * Keystroke event #5 | ||
+ | * Keystroke event #6 | ||
+ | * Keystroke event #7 | ||
+ | * Keystroke event #8 | ||
+ | * Keystroke event #9 | ||
+ | * Keystroke event #10 | ||
* LiveTV started | * LiveTV started | ||
+ | * Master backend shutdown | ||
+ | * Master backend started | ||
+ | * mythfilldatabase ran | ||
+ | * Network Control client connected | ||
+ | * Network Control client disconnected | ||
+ | * Playback paused | ||
+ | * Playback program changed | ||
* Playback started | * Playback started | ||
* Playback stopped | * Playback stopped | ||
− | |||
* Playback unpaused | * Playback unpaused | ||
− | * | + | * Recording deleted |
− | * | + | * Recording expired |
− | * | + | * Recording finished |
− | * | + | * Recording pending |
− | * | + | * Recording started |
+ | * Recording started writing | ||
+ | * Scheduler ran | ||
+ | * Screen created or destroyed | ||
+ | * Settings cache cleared | ||
* Slave backend connected to master | * Slave backend connected to master | ||
* Slave backend disconnected from master | * Slave backend disconnected from master | ||
− | * | + | * System Event Command Editor |
− | + | ||
− | + | For each event you can optionally define a command that the system will run when that event occurs. | |
− | |||
− | |||
These events are all sent automatically when the appropriate condition is met, but it is also possible to send events from the command line, for example: | These events are all sent automatically when the appropriate condition is met, but it is also possible to send events from the command line, for example: | ||
− | <pre> | + | <pre>mythutil --systemevent USER_1</pre> |
sends the first user event to whatever handler has been defined for that event. | sends the first user event to whatever handler has been defined for that event. | ||
Revision as of 13:53, 28 October 2015
This page is up-to-date as of MythTV version 0.27.6, the current release is 34.0
This article describes the System Events page of MythTV Setup.
This is an optional setting and an advanced usage. You do not need to do anything here for basic recording and playback in MythTV.
MythTV System Events are a new feature in MythTV 0.23. Historically MythEvents have been used to communicate between components of the system when blocking was not required for proper operation. Now it is possible for the end user to tap into a number of events as well as defining up to ten keypress events. These events are handled by running an external script with appropriate parameters. MythTV System Events are configured on a per box basis so each machine can have it's own system specific handlers.
Beginning with release 0.26, timestamps of recordings are stored in UTC. Applications that use xxxTIME parameters to directly index the database will need to either handle timezone conversion internally, or switch to the respective xxxTIMEUTC parameters. See UTC.
Contents
Available Events
These are the currently defined events:
- Any event
- Client connected to master backend
- Client disconnected from master backend
- Keystroke event #1
- Keystroke event #2
- Keystroke event #3
- Keystroke event #4
- Keystroke event #5
- Keystroke event #6
- Keystroke event #7
- Keystroke event #8
- Keystroke event #9
- Keystroke event #10
- LiveTV started
- Master backend shutdown
- Master backend started
- mythfilldatabase ran
- Network Control client connected
- Network Control client disconnected
- Playback paused
- Playback program changed
- Playback started
- Playback stopped
- Playback unpaused
- Recording deleted
- Recording expired
- Recording finished
- Recording pending
- Recording started
- Recording started writing
- Scheduler ran
- Screen created or destroyed
- Settings cache cleared
- Slave backend connected to master
- Slave backend disconnected from master
- System Event Command Editor
For each event you can optionally define a command that the system will run when that event occurs.
These events are all sent automatically when the appropriate condition is met, but it is also possible to send events from the command line, for example:
mythutil --systemevent USER_1
sends the first user event to whatever handler has been defined for that event.
Defining event handlers
Events handlers are edited in the System Events section in mythtv-setup. Select the event you would like to edit in the event list and then type in the script path and name followed by any parameters that you would like to pass to the script. For example to run a script whenever a recording is pending you could select the "Recording pending" event and type:
/opt/bin/RecordingPending.sh %STARTTIME%
That script could be a priming script to get a set top box out of it's sleep mode:
#!/bin/bash flock -x /tmp/chch.lock DEVICE="--address=cherry:5000" REMOTE_NAME=dish1 irsend $DEVICE SEND_ONCE $REMOTE_NAME select echo "Sent priming shortly before %1" >> /tmp/priming-debug.log
Parameters available to event handlers
The parameters that it is possible to pass to an event depends on the event.
Parameter | Description | Used
By |
Released
In |
---|---|---|---|
%CARDID% | Event | ||
%CATEGORY% | Program subject category, may be undefined. | Both | |
%CHANID% | Channel ID | Both | |
%DESCRIPTION% | Program title, may be undefined. | Both | |
%DIR% | Event: myth://IP:6543/file.mpg, Job: actual directory, may be undefined prior to recording start. | Both | |
%ENDTIME% | Recording end time (estimated) yyyyMMddhhmmss. | Both | |
%ENDTIMEISO% | YYYY-MM-DDThh:mm:ss | Both | |
%ENDTIMEISOUTC% | YYYY-MM-DDThh:mm:ssZ | ||
%ENDTIMEUTC% | yyyyMMddhhmmss | Both | |
%EPISODE% | Number | Both | 0.25? |
%EVENTNAME% | E.g. REC_PENDING | Event | |
%FILE% | Recording file, may be undefined prior to recording start. | Both | |
%FINDID% | Find ID, for DB lookups. | Event | |
%HOSTNAME% | Both | ||
%INETREF% | String, e.g. ttvdb.py_123456 | ||
%JOBID% | The id of this job in the mythconverg jobqueue table. | ||
%ORIGINALAIRDATE% | Original Air Date of recording. | Both | |
%PARENTID% | Parent recording rule ID, for DB lookups. | Event | |
%PARTNUMBER% | Number | ||
%PARTTOTAL% | Number | ||
%PLAYGROUP% | Play group | Both | |
%PROGEND% | Program's scheduled end time. | Both | |
%PROGENDISO% | Both | ||
%PROGENDISOUTC% | |||
%PROGENDUTC% | Both | ||
%PROGSTART% | Both | ||
%PROGSTARTISO% | Both | ||
%PROGSTARTISOUTC% | |||
%PROGSTARTUTC% | Both | ||
%REACTIVATE% | 1 if this recording was reactivated after failing to start on time, 0 otherwise. | Event | |
%RECGROUP% | Recording group | Both | |
%RECID% | Recording rule ID, for DB lookups. | Event | |
%RECORDEDID% | Recorded rule ID, for DB lookups. | Both | v29.2 |
%RECSTATUS% | Recording status as an integer for completeness, not currently useful. | Event | |
%RECTYPE% | This is the recording rule type as an integer, in the priming script example this could be used to do an extensive priming prior to some recordings and not others. These integers are listed in recordingtypes.h in the RecordingType enum. | Event | |
%SEASON% | Number | Both | 0.25? |
%SECS% | Time until upcoming recording starts. | Event | |
%SENDER% | Origin of event (hostname.) | Event | |
%STARTTIME% | Both | ||
%STARTTIMEISO% | Both | ||
%STARTTIMEISOUTC% | |||
%STARTTIMEUTC% | Both | ||
%SUBTITLE% | Program subtitle, may be undefined. | Both | |
%SYNDICATEDEPISODE% | String | ||
%TITLE% | Program title, may be undefined. | Both | |
%TRANSPROFILE% | Profile number. | Job | |
%TOTALEPISODES% | Integer | ||
%VBIDEVICE% | E.g.: --verbose --logpath --loglevel --quiet --nodblog [--syslog (if non Windows)]. | Event | 30 |
%VERBOSELEVEL% | Bit mapped decimal value. See: https://code.mythtv.org/cgit/mythtv/tree/mythtv/libs/libmythbase/verbosedefs.h | Both | |
%VERBOSEMODE% | E.g.: --verbose --logpath --loglevel --quiet --nodblog [--syslog (if non Windows)]. | Job | 0.25 |
%VIDEODEVICE% | String identifying the physical video device | Event | 30 |