EIT lockup - more information

[pstehlik@…]

I was asked to provide more information about scanning channels that add a channel (3980 "ASTRA MHP MOSAIC") although it cannot tune to it later. Attached should be the output of "mythtv-setup -v channel,siparser" from the scan (scan_astra.txt.gz) and the output of "mythbackend -v channel,siparser,record" (to3980.txt) when tuning to the problem channel.

Please note that this is not one single channel out of those 600 (or so) that would be faulty. Even if I narrowed down the huge list of channels to some 20-30 I still can't browse them successfully with MythTV Live TV's up/down arrow keys. I can see two or three channels but if I continue browsing them then it locks up.

[pstehlik@…]

log of mythtv-setup scanning Astra-19.2E

[pstehlik@…]

log of mythtv trying to tune to channel 3980

[danielk]

Does this channel ever go off-the-air? Or is it perhaps access controlled?

It looks like it wasn't in the PMT during the scan either; but it was in the SDT.

We have to insert such channels because in some places it is common place for perfectly good channels to not show up in the PMT when it is "off-the-air". But you should still be able to change the channels after a tuning to one of these channels; and of course the an EIT scan should work.

So it appears the channel scan is not at fault for inserting this channel. Can you add the change the EIT timeout on that source to 1 minute and produce a log of the EIT scan that gets stuck? To about 10 minutes after it is stuck.

[anonymous]

I don't know anything about this particular channel but I'd say it's for some MHP testing only. I have here a complete log of the automatic EIT crawler, since starting the backend up to the lockup (and survival), it's about 500 thousand lines (730 kB gzipped). It started at 9:33:31. At 9:45:17 it started tuning to 3980 for the first time. Automatically recovered (without the "Value too large for defined data type" error) at 09:53:50. Then a second run began and at 10:33:40 it ran into 3980 again. Auto recovered at 10:42. Now I understand why you wanted me to record 10 minutes after-stuck log :-)

Anyway, since the "Value too large for defined data type" error didn't appear this is rather minor problem. It just fills up the logs and makes the machine busy. I hope this 10 minutes autorecovery time from "Program #XXXX not found in PAT!" could be shortened to say 1 second and the log file could be saved from the repeated messages.

I wanted to help with debugging the real error but it must have been caused by me browsing the channels while this EIT loop occured since the EIT auto scan itself doesn't make it.

[pstehlik@…]

the 10 minutes of recovering from the "Program not found in PAT"

[anonymous]

The channel browsing probably caused the lockup, there are still several lose ends in the new LiveTV implementation. The EIT scan spends the same amount of time on each channel, more or less 5 minutes 30 seconds by default. This per-channel time can be changed in the backend configuration. If you want to help with improvements to the EIT scanner please coordinate with Stuart Auchterlonie.

Ok, since the EIT doesn't seem to have caused the lockup I'm closing this as 'invalid', but if the scan itself does trigger a lockup please reopen with the same types of logs.