On Fri, 23 Oct 2020 14:53:12 -0500, you wrote:
>On 10/22/20 9:46 PM, Stephen Worthington wrote:
>> On Thu, 22 Oct 2020 20:32:05 -0500, you wrote:
>>
>>> One of my tuner is bad and it produces 0 byte recordings whenever that
>>> tuner is used. I am not sure which one it is. How do I find out from the
>>> recorded program information? I mean, when I look up previously recorded
>>> programs, I do not get input information. Is that kept in the database,
>>> if so how do I get it?
>> On a recording, push the I key twice and scroll down if necessary to
>> find the "Recording Input:" field. In the database, this is the
>> recorded.inputname field. It does rely on you having set up the names
>> for the tuners in mythtv-setup so that you can differentiate them.
>> From SQL a query like this should work:
>>
>> select chanid,starttime,title,inputname from recorded where filesize=0
>> order by starttime desc limit 10;
>>
>> You can also look in mythbackend.log. I do this grep command daily to
>> check for damaged recordings:
>>
>> grep -a "overall_score=\"0" /var/log/mythtv/mythbackend.log
>>
>> However, the log lines that relies on may only be there if you have
>> the "-v record" option set on your mythbackend command line. I always
>> have that option set. Here is the sort of message that grep will
>> find:
>>
>> Oct 17 04:51:47 mypvr mythbackend: mythbackend[3235]: I TVRecEvent
>> tv_rec.cpp:826 (FinishedRecording) TVRec[92]:
>> FinishedRecording(10007_2020-10-16T15:51:26Z) damaged
>> recq:<RecordingQuality overall_score="0"
>> key="10007_2020-10-16T15:51:26Z" continuity_error_count="0"
>> packet_count="116465">#012 <Gap start="2020-10-16T15:20:00Z"
>> end="2020-10-16T15:51:27Z" duration="1887" />#012 <Gap
>> start="2020-10-16T15:51:47Z" end="2020-10-16T16:10:00Z"
>> duration="1092" />#012</RecordingQuality>
>>
>> The tuner number is available as the [92] in TVRec[92] in that
>> message. I believe all messages referring to a tuner will have the
>> tuner number in that format.
>>
>I added -v record to mythtv-backend service and restarted the service.
>Interestingly I had some hits from your grep command eventhough I did
>not have -v record switch when the error message was generated. Here is
>what I got
>> Oct 19 16:00:00 zym mythbackend: mythbackend[2673]: I
>> HDHRStreamHandler tv_rec.cpp:826 (FinishedRecording) TVRec[18]:
>> FinishedRecording(1041_2020-10-19T20:57:04Z) damaged
>> recq:<RecordingQuality overall_score="0"
>> key="1041_2020-10-19T20:57:04Z" continuity_error_count="0"
>> packet_count="1388107">#012??? <Gap start="2020-10-19T20:30:00Z"
>> end="2020-10-19T20:57:04Z" duration="1624" />#012</RecordingQuality>
>
>> Oct 19 16:22:29 zym mythbackend: mythbackend[2673]: I TVRecEvent
>> tv_rec.cpp:826 (FinishedRecording) TVRec[18]:
>> FinishedRecording(1041_2020-10-19T21:00:00Z) damaged
>> recq:<RecordingQuality overall_score="0"
>> key="1041_2020-10-19T21:00:00Z" continuity_error_count="0"
>> packet_count="9976787">#012??? <Gap start="2020-10-19T21:22:27Z"
>> end="2020-10-20T00:15:00Z" duration="10352" />#012</RecordingQuality>
>
>This does not match the 0byte recording as the incident time does not
>match. My 0byte recording program starts at 17:30
>(NBC nightly news).
>
>Ramesh
When a recording fails the time the failure happens is at the end of
the recording time. So if your recording starts at 17:30 and runs for
60 minutes plus say 4 minutes of post roll it will likely be actually
finishing at 17:30+60+4+1, with the extra 1 minute coming from the
default 60 seconds setting for the other (general to all recordings)
post-roll setting. So you would expect the matching "damaged" message
to be logged at about 18:35 local time. You can match up the
"damaged" messages to recordings using the filestamp that gets logged.
In the last message above, the filestamp is the
"FinishedRecording(1041_2020-10-19T21:00:00Z)" and that tells you that
the chanid for the recording was 1041 and the timestamp for the start
of recording was 2020-10-19T21:00:00Z (UTC = the Z on the end). So in
the database, the basename for that recording will be
1041_20201019210000.ts. In a database query you can then find that
recording with:
select * from recorded where basename like '1041_20201019210000%'\G
select * from recordedprogram where chanid=(select chanid from
recorded where basename like '1041_20201019210000%') and
starttime=(select progstart from recorded where basename like
'1041_20201019210000%')\G
I do not get many 0 byte recordings, so I am not sure exactly what a
"damaged" message for one would look like. There are two
possibilities - either there would be no "damaged" message at all
(since the recording never started), but more likely there would be a
message with a gap for the entire length of the recording, so the
"<Gap start=" will be a timestamp for the start of the recording (in
UTC though) and the "duration=" will be the number of seconds for the
total recording time including both types of pre-roll and both types
of post-roll.
When trying to match recordings to "damaged" messages, I find it
really useful to know the chanid value I am looking for. So I have my
database set up so that most chanids have values that match the
channel numbers. For example, for my Sky TV channels, the chanid is
always 10000 plus the channel number. Your database may not have
that, so you may need to look up the chanid:
select chanid,channum+0,callsign,name from channel where channum=1;
or
select chanid,channum+0,callsign,name from channel where name like
'%NBC%';
I am also lucky with the timezone I live in - New Zealand is UTC+12
normally and UTC+13 during daylight saving. So it is fairly easy
arithmetic to work out the UTC time for a programme from its local
time. If your timezone is not so cooperative, you can get the
database to help. To convert from UTC to local time (for the NZ
timezone):
MariaDB [mythconverg]> select convert_tz('2020-10-19T21:22:27Z',
'UTC', 'NZ');
+-------------------------------------------------+
| convert_tz('2020-10-19T21:22:27Z', 'UTC', 'NZ') |
+-------------------------------------------------+
| 2020-10-20 10:22:27 |
+-------------------------------------------------+
1 row in set, 1 warning (0.000 sec)
and back again:
MariaDB [mythconverg]> select convert_tz('2020-10-20
10:22:27','NZ','UTC');
+----------------------------------------------+
| convert_tz('2020-10-20 10:22:27','NZ','UTC') |
+----------------------------------------------+
| 2020-10-19 21:22:27 |
+----------------------------------------------+
1 row in set (0.000 sec)
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users http://wiki.mythtv.org/Mailing_List_etiquette MythTV Forums:
https://forum.mythtv.org