[mythtv-users] UK-Mendip DVB-T multiplex, post 11 January 2011

[Alex Butcher]

On Mon, 24 Jan 2011, nospam312 wrote:

>> I'm having weird tuning/failed recording problems with a Nova-T-500
>> card that used to work perfectly before a coincidental rebuild/system
>> upgrade from Fedora 8/MythTV 0.21-fixes to Fedora 14/MythTV 0.24-fixes.
>> I'm wondering if the proliferation of 'auto' in some of those columns
>> may be a factor.
>>
>> A failed recording (with mythfrontend's 'upcoming recordings' showing
>> it stuck in the 'tuning' state) goes like this:
>
> I am on a different transmitter and I have recordings getting stuck in
> the "t" (lower case t) state also.

Exactly.

> I am using single tuner Haupaugge USB sticks.

The dual-tuner Nova-T-500 is known to be problematic, so I was expecting it
to be something to do with the driver, but based on lack of I2C/MT2060
errors in the kernel syslog and your message, I think it's a problem on the
MythTV side, probably not helped by the vagaries of UK DVB-T broadcasting...

> I was thinking it was related to a recent update on my 0.24fixes - I
> was running an early 0.24fixes when it was first released (old CVS
> style build number).  After updating I have a newer Git related build
> number in my status page.  I was waiting to ensure Mythbuntu update
> building from Git was working.  At the same time it did kernel updates
> etc so I guess something may have changed that Myth uses.
>
> I think I have had a few days where I have had no problems since I
> completely deleted everything from all the channels* / dtv* tables and
> did a full scan on all my cards.  I too have several Auto's in fields
> I do not recall previously but in this regard I would have to dig out
> my previous backups to be 100% sure on this.

I've filled in some of the autos based on a bit of (semi)intelligent
guesswork; we'll see how that goes. My backup from 0.21-fixes doesn't have
any autos for any of the values, but I recall doing some manual hacking back
then to deal with the analogue switch off last year, and consequent jumbling
of channels and their mplexes, and not wanting to just drop the tables,
recreate as empty and rescan.

My dtv_multiplex table now looks like this:

mysql> select mplexid,transportid,networkid,frequency,modulation,bandwidth,lp_code_rate,transmission_mode,guard_interval,constellation,hp_code_rate,hierarchy from dtv_multiplex;
+---------+-------------+-----------+-----------+------------+-----------+--------------+-------------------+----------------+---------------+--------------+-----------+
| mplexid | transportid | networkid | frequency | modulation | bandwidth | lp_code_rate | transmission_mode | guard_interval | constellation | hp_code_rate | hierarchy |
+---------+-------------+-----------+-----------+------------+-----------+--------------+-------------------+----------------+---------------+--------------+-----------+
|      15 |        4161 |      9018 | 794000000 | qam_64     | 8         | 1/2          | 8                 | 1/32           | qam_64        | 2/3          | n         |
|      16 |        8204 |      9018 | 738000000 | qam_64     | 8         | 1/2          | 8                 | 1/32           | qam_64        | 2/3          | n         |
|      17 |       12290 |      9018 | 802166670 | qam_64     | 8         | 1/2          | 2                 | 1/32           | qam_64        | 2/3          | n         |
|      18 |       20480 |      9018 | 754166670 | qam_16     | 8         | 3/4          | 2                 | 1/32           | qam_16        | 3/4          | n         |
|      19 |       24640 |      9018 | 842000000 | qam_64     | 8         | 1/2          | 8                 | 1/32           | qam_64        | 2/3          | n         |
+---------+-------------+-----------+-----------+------------+-----------+--------------+-------------------+----------------+---------------+--------------+-----------+

> The first issue is the recording getting stuck in the "t" state (I
> think I saw this on the Upcoming Recordings screen).  The second issue
> is if you go and look at the Previous Recordings screen after the "t"
> state problem it is classed as recorded meaning Myth does not
> reschedule or give any indication there was a problem so it is next to
> impossible to know if you have missed a recording as Myth thinks
> everything was fine.

Indeed.

> Not knowing something has not worked is the main problem for me Myth
> should not class the programme as recorded if it hasn't even managed
> to tune to the channel - it should marked the recording as failed and
> try to reschedule it.

I'm now running mythbackend with '-v important,record,channel,siparser'
which seems to log useful stuff which may help with any debugging.

> As we both have a very similar problem I think adding a trac ticket is
> probably the way to go?

Quite possibly, if my dtv_multiplex column guesses don't help. Feel free to
open one yourself in the meantime.

Thanks for the confirmation that I'm not the only person experiencing this;
I hope my post helps you similarly.

Best Regards,
Alex