Opened 16 years ago

Closed 16 years ago

#5648 closed defect (fixed)

mythlcdserver problem when frontend starts

Reported by: anonymous Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: mythtv Version: 0.21-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

A number of references on the 'net: http://ubuntuforums.org/showthread.php?t=304807 and a fairly detailed discussion here: http://www.mailinglistarchive.com/mythtv-users@mythtv.org/msg62986.html

Basic gist is that when the frontend starts, something happens with mythlcdserver and the VFD/LCD goes back to the LCDproc server CLi: X SCR: X screen.

On my box, using mythwelcome, the VFD correctly shows the time until the frontend is started at which point it goes back to the LCDproc screens. Killing mythlcdserver and waiting until the front-end restarts seems to be a workaround, but not a very nice one.

I'm on mythbuntu 8.04 and the 0.21-fixes branch

Change History (2)

comment:1 Changed 16 years ago by paulh

(In [18245]) Fix a couple of problems with the LCD.

  1. Don't send any commands to mythlcdserver until we have a response to 'HELLO'. Refs #5421.
  1. Work around a problem with the LCD not always starting up properly. Refs #5648. Probably also fixes #5613.

The problem seems to be that if the readyread_thread is monitoring only one socket (the BE isn't running) then it can get into a state where it never wakes up to process a read. If another socket is added (the BE is started) or if it is forced to wake up then it starts to behave properly.

The hack is to Lock() and Unlock() the socket after the first write which is enough to get the readyready_thread working properly.

comment:2 Changed 16 years ago by paulh

Resolution: fixed
Status: newclosed

(In [18246]) Merge [18245] from trunk.

Fix a couple of problems with the LCD.

  1. Don't send any commands to mythlcdserver until we have a response to 'HELLO'. Fixes #5421.
  1. Work around a problem with the LCD not always starting up properly. Fixes #5648. Probably also fixes #5613.

The problem seems to be that if the readyread_thread is monitoring only one socket (the BE isn't running) then it can get into a state where it never wakes up to process a read. If another socket is added (the BE is started) or if it is forced to wake up then it starts to behave properly.

The hack is to Lock() and Unlock() the socket after the first write which is enough to get the readyready_thread working properly.

Note: See TracTickets for help on using tickets.