[mythtv] [mythtv-commits] Ticket #9566: Mythbackend reports "multiplex is not available" and afterwards the specified DVB tuner is busy for ever
Michael T. Dean
mtdean at thirdcontact.com
Sun Feb 13 14:09:15 UTC 2011
On 02/13/2011 02:59 AM, Tomi Orava wrote:
> Hmm, of course I did find some very propable cause for the usage of
> wrong profiles for "regular" recordings so a short update in case
> somebody else has similar problems:
>
>> Does somebody have any ideas about the second(?) problem that my
>> system seems to have ie. it still has tendency to create recordings
>> which are missing the physical file ie. the file size is right from
>> the start marked as 'B' ?
>>
>> The log clip below raises questions, why on earth some recordings
>> are using the profile "Live TV" and others are using the profile
>> "Default". All of those recordings have been pre scheduled via
>> Mythweb and certainly not via mythfrontend watch tv functinality
>> ... Also what bothers be
>> is that I can see from the logs the following my personally added
>> debug line, that doesn't
>> seem to make any sense as none of the frontends have been on at this
>> time. This of course
>> might explain why some of the recordings get lost as the GetState
>> reports the value "kState_none"
>> instead of "kState_RecordingOnly" as I would expect.
>>
>> Example entries from last night without any of frontends watching anything:
>>
>> #> grep 'EXITED' mythbackend.log
>>
>> 2011-02-13 00:41:49.560 TVRec(13): Going to send LIVETV_EXITED msg!
>> 2011-02-13 00:47:40.147 TVRec(14): Going to send LIVETV_EXITED msg!
>> 2011-02-13 01:25:03.644 TVRec(1): Going to send LIVETV_EXITED msg!
>> 2011-02-13 02:10:03.543 TVRec(7): Going to send LIVETV_EXITED msg!
>> 2011-02-13 03:10:03.174 TVRec(6): Going to send LIVETV_EXITED msg!
>> 2011-02-13 03:17:38.923 TVRec(15): Going to send LIVETV_EXITED msg!
>> 2011-02-13 03:26:29.186 TVRec(7): Going to send LIVETV_EXITED msg!
>> 2011-02-13 04:00:02.845 TVRec(11): Going to send LIVETV_EXITED msg!
>> 2011-02-13 05:00:03.512 TVRec(12): Going to send LIVETV_EXITED msg!
>> 2011-02-13 06:00:03.251 TVRec(6): Going to send LIVETV_EXITED msg!
>> 2011-02-13 06:30:02.716 TVRec(7): Going to send LIVETV_EXITED msg!
>> 2011-02-13 06:30:04.746 TVRec(9): Going to send LIVETV_EXITED msg!
>> 2011-02-13 06:35:02.942 TVRec(8): Going to send LIVETV_EXITED msg!
>> 2011-02-13 07:00:03.380 TVRec(11): Going to send LIVETV_EXITED msg!
>> 2011-02-13 07:20:03.876 TVRec(1): Going to send LIVETV_EXITED msg!
>> 2011-02-13 07:25:03.826 TVRec(6): Going to send LIVETV_EXITED msg!
>> 2011-02-13 08:05:06.197 TVRec(7): Going to send LIVETV_EXITED msg!
>> 2011-02-13 08:05:23.423 TVRec(1): Going to send LIVETV_EXITED msg!
>> 2011-02-13 08:13:18.006 TVRec(2): Going to send LIVETV_EXITED msg!
>> 2011-02-13 08:25:02.911 TVRec(8): Going to send LIVETV_EXITED msg!
>> 2011-02-13 08:37:03.209 TVRec(12): Going to send LIVETV_EXITED msg!
>> 2011-02-13 08:37:10.038 TVRec(11): Going to send LIVETV_EXITED msg!
>> 2011-02-13 08:37:19.778 TVRec(2): Going to send LIVETV_EXITED msg!
>> 2011-02-13 08:37:21.161 TVRec(6): Going to send LIVETV_EXITED msg!
>> 2011-02-13 08:37:24.432 TVRec(1): Going to send LIVETV_EXITED msg!
>>
>>
>> The added debug line comes from here:
>>
>> @@ -661,6 +670,7 @@ RecStatusType TVRec::StartRecording(const
>> ProgramInfo *rcinfo)
>>
>> if (!cancelNext&& (GetState() == kState_None))
>> {
>> + VERBOSE(VB_RECORD, LOC + "Going to send LIVETV_EXITED msg!");
>> if (tvchain)
>> {
>> QString message = QString("LIVETV_EXITED");
>> @@ -686,6 +696,7 @@ RecStatusType TVRec::StartRecording(const
>> ProgramInfo *rcinfo)
>> }
>> else if (!cancelNext&& (GetState() == kState_WatchingLiveTV))
>> {
>> + VERBOSE(VB_RECORD, LOC + "Going to send LIVETV_WATCH msg!");
>> SetPseudoLiveTVRecording(new ProgramInfo(*rcinfo));
>> recordEndTime = GetRecordEndTime(rcinfo);
>> pendingRecLock.lock();
>>
>> I've added a clip from the mythbackend.log that might give you some
>> clues about the problem.
> Both of the mythtv installations (one with 0.23-fixes and second with
> 0.24-fixes) had quite interesting looking profilegroups and
> recordingprofiles table combinations:
>
> mysql> select * from recordingprofiles;
> +----+----------------+------------+--------------+--------------+
> | id | name | videocodec | audiocodec | profilegroup |
> +----+----------------+------------+--------------+--------------+
> | 1 | Default | NULL | NULL | 1 |
> | 2 | Live TV | NULL | NULL | 1 |
> | 3 | High Quality | NULL | NULL | 1 |
> | 4 | Low Quality | NULL | NULL | 1 |
> | 5 | Default | NULL | NULL | 2 |
> | 6 | Live TV | NULL | NULL | 2 |
> | 7 | High Quality | NULL | NULL | 2 |
> | 8 | Low Quality | NULL | NULL | 2 |
> | 9 | Default | NULL | NULL | 3 |
> | 10 | Live TV | NULL | NULL | 3 |
> | 11 | High Quality | NULL | NULL | 3 |
> | 12 | Low Quality | NULL | NULL | 3 |
> | 13 | Default | NULL | NULL | 4 |
> | 14 | Live TV | NULL | NULL | 4 |
> | 15 | High Quality | NULL | NULL | 4 |
> | 16 | Low Quality | NULL | NULL | 4 |
> | 17 | Default | NULL | NULL | 5 |
> | 18 | Live TV | NULL | NULL | 5 |
> | 19 | High Quality | NULL | NULL | 5 |
> | 20 | Low Quality | NULL | NULL | 5 |
> | 21 | RTjpeg/MPEG4 | RTjpeg | MP3 | 6 |
> | 22 | MPEG2 | RTjpeg | MP3 | 6 |
> | 23 | Default | NULL | NULL | 8 |
> | 24 | Live TV | NULL | NULL | 8 |
> | 25 | High Quality | NULL | NULL | 8 |
> | 26 | Low Quality | NULL | NULL | 8 |
> | 27 | High Quality | RTjpeg | MP3 | 6 |
> | 28 | Medium Quality | NULL | NULL | 6 |
> | 29 | Low Quality | MPEG-4 | Uncompressed | 6 |
> | 30 | Default | NULL | NULL | 10 |
> | 31 | Live TV | NULL | NULL | 10 |
> | 32 | High Quality | NULL | NULL | 10 |
> | 33 | Low Quality | NULL | NULL | 10 |
> | 34 | Default | NULL | NULL | 11 |
> | 35 | Live TV | NULL | NULL | 11 |
> | 36 | High Quality | NULL | NULL | 11 |
> | 37 | Low Quality | NULL | NULL | 11 |
> | 38 | Default | NULL | NULL | 12 |
> | 39 | Live TV | NULL | NULL | 12 |
> | 40 | High Quality | NULL | NULL | 12 |
> | 41 | Low Quality | NULL | NULL | 12 |
> | 42 | Default | NULL | NULL | 10 |
> | 43 | Live TV | NULL | NULL | 10 |
> | 44 | High Quality | NULL | NULL | 10 |
> | 45 | Low Quality | NULL | NULL | 10 |
> | 46 | Default | NULL | NULL | 11 |
> | 47 | Live TV | NULL | NULL | 11 |
> | 48 | High Quality | NULL | NULL | 11 |
> | 49 | Low Quality | NULL | NULL | 11 |
> | 50 | Default | NULL | NULL | 12 |
> | 51 | Live TV | NULL | NULL | 12 |
>
> mysql> select * from profilegroups;
> +----+----------------------------------------------------------+-----------+------------+----------+
> | id | name |
> cardtype | is_default | hostname |
> +----+----------------------------------------------------------+-----------+------------+----------+
> | 1 | Software Encoders (v4l based) | V4L
> | 1 | NULL |
> | 2 | MPEG-2 Encoders (PVR-x50, PVR-500) | MPEG
> | 1 | NULL |
> | 3 | Hardware MJPEG Encoders (Matrox G200-TV, Miro DC10, etc) |
> MJPEG | 1 | NULL |
> | 4 | Hardware HDTV | HDTV
> | 1 | NULL |
> | 5 | Hardware DVB Encoders | DVB
> | 1 | NULL |
> | 6 | Transcoders |
> TRANSCODE | 1 | NULL |
> | 7 | FireWire Input |
> FIREWIRE | 1 | NULL |
> | 8 | USB Mpeg-4 Encoder (Plextor ConvertX, etc) |
> GO7007 | 1 | NULL |
> | 17 | Import Recorder |
> IMPORT | 1 | NULL |
> | 10 | Freebox Input |
> Freebox | 1 | NULL |
> | 11 | HDHomeRun Recorders |
> HDHOMERUN | 1 | NULL |
> | 12 | CRC IP Recorders |
> CRC_IP | 1 | NULL |
> | 13 | Freebox Input |
> Freebox | 1 | NULL |
> | 14 | HDHomeRun Recorders |
> HDHOMERUN | 1 | NULL |
> | 15 | CRC IP Recorders |
> CRC_IP | 1 | NULL |
> | 16 | HD-PVR Recorders |
> HDPVR | 1 | NULL |
> +----+----------------------------------------------------------+-----------+------------+----------+
> 16 rows in set (0.00 sec)
>
> After cleaning these both systems up, I'm very interested to see if
> the missing recordings problem disappears. Both of these systems have
> been running mythtv quite a long time and have been upgraded to newer
> releases a couple of times and somewhere a long the journey the tables
> have got messed up.
>
> I will of course retest the EIT scanning functionality in order to see
> if this was interfering EIT scanning somehow.
Your recordingprofile table contents, shown above, look fine. And, if
you "cleaned" it up, I seriously hope you did so through the UI since
manually editing it would likely have broken your data. (This is why we
create a UI--so users don't need to understand the data constraints and
manually poke around in the database, where MySQL would allow them to
break the data. The MythTV UI doesn't allow you to break the data and
enforces constraints on the data.)
The profilegroups table contents, other than having duplicate
definitions for Freebox, HDHR, and CRC IP recorders, is fine, too (and
the duplicates definitely shouldn't cause any problems when not using
those 3 recorder types and likely wouldn't anyway). However, the fact
that they are duplicated seems to indicate you may have run with some
patches applied during the 0.19->0.20 development cycle that caused
multiple applications of the 1146 and 1149 DB updates. Depending on
what those patches were (and whether they modified the DB schema
version--thereby causing other updates to never occur), you may or may
not have a corrupt DB schema.
If you don't trust your schema or the data within it, your best
bet--rather than manually editing DB tables and assuming you fully
understand all the constraints on the data (which is only defined within
the code, and not within the DB schema)--is to do a partial restore of
your database, as at
http://www.mythtv.org/wiki/Database_Backup_and_Restore
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup
That said, if you haven't noticed any problems with your schema since
0.20, I doubt there's anything seriously wrong (and, I don't think the
above is related to the 0-length recordings).
Mike
More information about the mythtv-dev
mailing list