[mythtv-users] Adding HDHR to a master backend with an HDPVR already

[Matt Emmott]

On Wed, Dec 16, 2009 at 1:24 PM, Johnny Walker <johnnyjboss at gmail.com>wrote:

>
>
> It seems that my whole backend and frontend have become unstable now -
> I need to re-read Michael's comments on how channels are tracked in
> the database and what I need to know to keep it all straight for the
> backend.
>
>
I'd like to chime in on the stability issue - I'm running an HDHR on Charter
in Massachusetts. After adding channels via a channel scan, I have to go and
tune each one, one at a time, in order to find out what they actually are
and modify Myth's channel mappings accordingly. It's a mind numbing, painful
process that takes hours.

When I tune to a channel that Myth can't handle, several different things
can happen: 1) If I'm lucky, I realize it's never going to come back and am
able to tune back to a channel that works. However, if this doesn't work,
then Myth 2) Kicks back to the main FE page with an error about opening a
jump file, or some other error that I can't remember. However, it's at this
point that my FE becomes unstable and will no longer tune any channels. I
have to restart mythfrontend. When I relaunch mythfrontend and attempt to
watch TV, I have to quickly remember to tune to a good channel, or step 2
repeats itself and I have to restart the app once again. Probably once every
five times myth will 3) Crash the frontend app altogether, or even 4)Crash
the backend, and I have to manually restart that process.

These are not encrypted channels as far as I can tell, as I have the option
to skip encrypted channels enabled. They're just 'bad' channels. And this
behavior has been going on since I got my HDHR with .21, and occurs across
all my FEs. So if you have a crash in tuning the channel, my recommendation
is to restart mythfrontend, or even reboot to be sure everything is as it
was.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20091216/068df1dc/attachment.htm>