LinHES Forums
http://forums.linhes.org/

R5E50 - Backend not starting up reliably after reboot
http://forums.linhes.org/viewtopic.php?f=6&t=13224		 Page 1 of 2
Author:  acronce [ Mon Jan 01, 2007 12:47 pm ]
Post subject:  R5E50 - Backend not starting up reliably after reboot
I've got a new install of R5E50 on a backend server. Unfortunately, the backend doesn't seem to be starting up reliably after a reboot. Sometimes it works, other times it doesn't.

When it doesn't work, the myth backend ports are not open, so frontends cannot connect to it, either locally or remotely. To work around the problem I have to start the backend manually via:

/etc/init.d/mythtv-backend restart

I'm new to myth, so I'm not sure where to look to resolve this. But a quick look at the following logs haven't provided any clues:

/var/log/mythtv/mythbackend.log
/var/log/messages
/var/log/syslog

Searching this forum seems to indicate that other people have seen this problem, and that it might be related to rebooting during commercial flagging. But there doesn't seem to be a resolution.

In any case, I don't know how to confirm that commercial flagging is running when I see the problem. That is, I don't see anything in the mythbackend.log about commercial flagging.

Any thoughts about how to resolve this? Thanks in advance.
Author:  tjc [ Mon Jan 01, 2007 12:55 pm ]
Post subject: 
We're still trying to track this one down. Scan your /var/log/mythtv/mythbackend.log logfiles for something about a mysql crash or the backend having a problem connecting to mysql.
Author:  acronce [ Mon Jan 01, 2007 1:13 pm ]
Post subject: 
tjc wrote:
We're still trying to track this one down. Scan your /var/log/mythtv/mythbackend.log logfiles for something about a mysql crash or the backend having a problem connecting to mysql.


Thanks for your response.

I grep'd all the logs for mysql, but didn't find anything interesting. All that showed up was the creation of the mysql.txt after my initial installation.

But I'm happy to give you my log files if you think they might help. Maybe something else will show up that will provide a clue as to what's happening here.

If you want the logs, let me know how you'd like me to get them to you.
Author:  the_manowar [ Mon Jan 01, 2007 5:36 pm ]
Post subject: 
tjc wrote:
We're still trying to track this one down. Scan your /var/log/mythtv/mythbackend.log logfiles for something about a mysql crash or the backend having a problem connecting to mysql.


I also see this issue.

Mysql seems to be running fine, however the backend doesn't stay up.


On one boot it appeared that the PID file was still present, and hence the "start" from the init failed, suggesting a "restart" instead. I haven't rebooted in a while, so haven't been able to confirm whether this is the case each time.
Author:  tjc [ Mon Jan 01, 2007 5:45 pm ]
Post subject: 
Someone in another thread said that it seemed dependent on how he shut down, so if you see any evidence of that it'd be a good data point...
Author:  the_manowar [ Mon Jan 01, 2007 7:16 pm ]
Post subject: 
tjc wrote:
Someone in another thread said that it seemed dependent on how he shut down, so if you see any evidence of that it'd be a good data point...


Hmmm, I manually removed the PID file at that time, and don't seem to have had the problem since.

I don't recall restarting abnormally, or anything else that may have caused the issue, but it may pay to add something to the init script which checks for the presence of the PID file, and if found, checks for the PID itself. If the file is present and the PID is not (check /proc ?) then start normally.

I'm reasonably happy, I only have one problem left which is annoying the crap out of me now:

http://mysettopbox.tv/phpBB2/viewtopic.php?t=13200
Author:  bruce_s01 [ Mon Jan 01, 2007 7:22 pm ]
Post subject: 
I found this problem as well.
I don't know if this is the cause of acronces problem, but what I've found is because of the revised speedy boot-up sequence, the order of my capture cards being assigned /dev/video[0-2] seems to change.
On the initial knoppmyth detection, where it lists the cards remains the same, but when the drivers are loaded, it appears the card order seems to change.
It seems the PVR350 has been assigned to all 3 devices in turn after a reboot. This seems to cause myth-backend some severe indigestion and claiming that the tuner was not available.
If you have multiple cards that are same from the same video source there shouldn't be any problems but if you are using different cards with different sources, there maybe some gotchas there.

Just to show, the output from /var/log/messages between the two IVTV headers:
Code:
Jan  1 13:46:44 homenet-pvr kernel: ivtv:  ==================== START INIT IVTV ====================
Jan  1 13:46:44 homenet-pvr kernel: ivtv:  version 0.8.2 (tagged release) loading
Jan  1 13:46:44 homenet-pvr kernel: ivtv:  Linux version: 2.6.18-chw-13 SMP preempt mod_unload 586 gcc-4.1
Jan  1 13:46:44 homenet-pvr kernel: ivtv:  In case of problems please include the debug info between
Jan  1 13:46:44 homenet-pvr kernel: ivtv:  the START INIT IVTV and END INIT IVTV lines, along with
Jan  1 13:46:44 homenet-pvr kernel: ivtv:  any module options, when mailing the ivtv-users mailinglist.
Jan  1 13:46:44 homenet-pvr kernel: usb 2-3.1: new full speed USB device using ohci_hcd and address 3
Jan  1 13:46:44 homenet-pvr kernel: usb 2-3.1: configuration #1 chosen from 1 choice
Jan  1 13:46:44 homenet-pvr kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
Jan  1 13:46:44 homenet-pvr kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Jan  1 13:46:44 homenet-pvr kernel: 00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 2-0050: Hauppauge model 90002, rev C176, serial# 229554
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 2-0050: MAC address is 00-0D-FE-03-80-B2
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 2-0050: tuner model is Thompson DTT7592 (idx 76, type 4)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 2-0050: TV standards ATSC/DVB Digital (eeprom 0x80)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 2-0050: audio processor is None (idx 0)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 2-0050: decoder processor is CX882 (idx 25)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 2-0050: has no radio, has IR remote
Jan  1 13:46:44 homenet-pvr kernel: cx88[0]: hauppauge eeprom: model=90002
Jan  1 13:46:44 homenet-pvr kernel: parport: PnPBIOS parport detected.
Jan  1 13:46:44 homenet-pvr kernel: parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
Jan  1 13:46:44 homenet-pvr kernel: usb 2-3.2: new full speed USB device using ohci_hcd and address 4
Jan  1 13:46:44 homenet-pvr kernel: input: cx88 IR (Hauppauge Nova-T DVB-T as /class/input/input2
Jan  1 13:46:44 homenet-pvr kernel: cx88[0]/0: found at 0000:05:07.0, rev: 5, irq: 20, latency: 32, mmio: 0xcc000000
Jan  1 13:46:44 homenet-pvr kernel: cx88[0]/0: registered device video0 [v4l2]
Jan  1 13:46:44 homenet-pvr kernel: cx88[0]/0: registered device vbi0
Jan  1 13:46:44 homenet-pvr kernel: ACPI: PCI Interrupt 0000:05:07.2[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 20
Jan  1 13:46:44 homenet-pvr kernel: cx88[0]/2: found at 0000:05:07.2, rev: 5, irq: 20, latency: 32, mmio: 0xcd000000
Jan  1 13:46:44 homenet-pvr kernel: cx88[0]/2: cx2388x based dvb card
Jan  1 13:46:44 homenet-pvr kernel: DVB: registering new adapter (cx88[0]).
Jan  1 13:46:44 homenet-pvr kernel: DVB: registering frontend 0 (Conexant CX22702 DVB-T)...
Jan  1 13:46:44 homenet-pvr kernel: CORE cx88[1]: subsystem: 0070:9002, board: Hauppauge Nova-T DVB-T [card=18,autodetected]
Jan  1 13:46:44 homenet-pvr kernel: TV tuner 4 at 0x1fe, Radio tuner -1 at 0x1fe
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 3-0050: Hauppauge model 90002, rev C176, serial# 229552
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 3-0050: MAC address is 00-0D-FE-03-80-B0
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 3-0050: tuner model is Thompson DTT7592 (idx 76, type 4)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 3-0050: TV standards ATSC/DVB Digital (eeprom 0x80)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 3-0050: audio processor is None (idx 0)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 3-0050: decoder processor is CX882 (idx 25)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 3-0050: has no radio, has IR remote
Jan  1 13:46:44 homenet-pvr kernel: cx88[1]: hauppauge eeprom: model=90002
Jan  1 13:46:44 homenet-pvr kernel: input: cx88 IR (Hauppauge Nova-T DVB-T as /class/input/input3
Jan  1 13:46:44 homenet-pvr kernel: ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
Jan  1 13:46:44 homenet-pvr kernel: ACPI: PCI Interrupt 0000:05:08.2[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 21
Jan  1 13:46:44 homenet-pvr kernel: cx88[1]/2: found at 0000:05:08.2, rev: 5, irq: 21, latency: 32, mmio: 0xd0000000
Jan  1 13:46:44 homenet-pvr kernel: cx88[1]/2: cx2388x based dvb card
Jan  1 13:46:44 homenet-pvr kernel: DVB: registering new adapter (cx88[1]).
Jan  1 13:46:44 homenet-pvr kernel: DVB: registering frontend 1 (Conexant CX22702 DVB-T)...
Jan  1 13:46:44 homenet-pvr kernel: ACPI: PCI Interrupt 0000:05:08.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 21
Jan  1 13:46:44 homenet-pvr kernel: cx88[1]/0: found at 0000:05:08.0, rev: 5, irq: 21, latency: 32, mmio: 0xcf000000
Jan  1 13:46:44 homenet-pvr kernel: cx88[1]/0: registered device video1 [v4l2]
Jan  1 13:46:44 homenet-pvr kernel: cx88[1]/0: registered device vbi1
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Autodetected Hauppauge card (cx23415 based)
Jan  1 13:46:44 homenet-pvr kernel: ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
Jan  1 13:46:44 homenet-pvr kernel: ACPI: PCI Interrupt 0000:05:06.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 22
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: loaded v4l-cx2341x-dec.fw firmware (262144 bytes)
Jan  1 13:46:44 homenet-pvr kernel: Initializing USB Mass Storage driver...
Jan  1 13:46:44 homenet-pvr kernel: tuner 4-0043: chip found @ 0x86 (ivtv i2c driver #0)
Jan  1 13:46:44 homenet-pvr kernel: tda9887 4-0043: tda988[5/6/7] found @ 0x43 (tuner)
Jan  1 13:46:44 homenet-pvr kernel: tuner 4-0061: chip found @ 0xc2 (ivtv i2c driver #0)
Jan  1 13:46:44 homenet-pvr kernel: msp3400 4-0040: MSP4418G-B3 found @ 0x80 (ivtv i2c driver #0)
Jan  1 13:46:44 homenet-pvr kernel: msp3400 4-0040: MSP4418G-B3 supports nicam and radio, mode is autodetect and autoselect
Jan  1 13:46:44 homenet-pvr kernel: saa7115 4-0021: saa7115 found @ 0x42 (ivtv i2c driver #0)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 4-0050: Hauppauge model 48139, rev K257, serial# 8378626
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 4-0050: tuner model is Philips FM1216 ME MK3 (idx 57, type 38)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 4-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) (eeprom 0x74)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 4-0050: audio processor is MSP4418 (idx 25)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 4-0050: decoder processor is SAA7115 (idx 19)
Jan  1 13:46:44 homenet-pvr kernel: tveeprom 4-0050: has radio, has IR remote
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Autodetected Hauppauge WinTV PVR-350
Jan  1 13:46:44 homenet-pvr kernel: saa7127 4-0044: saa7129 found @ 0x88 (ivtv i2c driver #0)
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Encoder revision: 0x02050032
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Decoder revision: 0x02020023
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Registered device video2 for encoder MPEG
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Registered device video32 for encoder YUV
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Registered device vbi2 for encoder VBI
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Registered device video24 for encoder PCM audio
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Registered device radio0 for encoder radio
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Registered device video16 for decoder MPEG
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Registered device vbi8 for decoder VBI
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Registered device vbi16 for decoder VOUT
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Registered device video48 for decoder YUV
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: loaded v4l-cx2341x-init.mpg firmware (155648 bytes)
Jan  1 13:46:44 homenet-pvr kernel: tuner 4-0061: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3))
Jan  1 13:46:44 homenet-pvr kernel: ivtv0: Initialized Hauppauge WinTV PVR-350, card #0
Jan  1 13:46:44 homenet-pvr kernel: ACPI: PCI Interrupt 0000:05:0b.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 22
Jan  1 13:46:44 homenet-pvr kernel: cx2388x blackbird driver version 0.0.6 loaded
Jan  1 13:46:44 homenet-pvr kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[22]  MMIO=[d2004000-d20047ff]  Max Packet=[2048]  IR/IT contexts=[4/8]
Jan  1 13:46:44 homenet-pvr kernel: ivtv:  ====================  END INIT IVTV  ====================


As you can see it's not the nice neat ivtv block that was there before. :) Looks like cat messages |grep ivtv is going have to be used to generate that block.

ETA: I had to stop myth-backend, and modify the tuners, the first time I deleted them, so I've ended up with tuner[4-6].

Bruce S.
Author:  the_manowar [ Mon Jan 01, 2007 7:29 pm ]
Post subject: 
the_manowar wrote:
tjc wrote:
Someone in another thread said that it seemed dependent on how he shut down, so if you see any evidence of that it'd be a good data point...


Hmmm, I manually removed the PID file at that time, and don't seem to have had the problem since.

I don't recall restarting abnormally, or anything else that may have caused the issue, but it may pay to add something to the init script which checks for the presence of the PID file, and if found, checks for the PID itself. If the file is present and the PID is not (check /proc ?) then start normally.



Further to this, in order to test, I've modified my /etc/init.d/mythtv-backend script (the "start" section) as follows:

Code:
  start)
        START=1
        if test -e $RUNDIR/$NAME.pid ; then
                OLDPID=`cat $RUNDIR/$NAME.pid`
                if test -e /proc/$OLDPID ; then
                        echo "mythbackend already running, use restart instead."
                        START=0
                else
                        echo "stale PID file, $RUNDIR/$NAME.pid found, removing."
                        rm $RUNDIR/$NAME.pid
                fi
        fi

        if [ $START == "1" ] ; then
                echo -n "Starting $DESC: $NAME"
                start-stop-daemon --start --pidfile $RUNDIR/$NAME.pid \
                        --chuid $USER --nicelevel $NICE --exec $DAEMON -- $ARGS
                echo "."
        fi
        ;;


I'll see how that goes for a while.
Author:  Krem1120 [ Thu Jan 18, 2007 2:46 pm ]
Post subject: 
Do your script ever end up working? I seem to be experiencing a issue similar to this...
Author:  rando [ Thu Jan 18, 2007 3:23 pm ]
Post subject: 
Is the problem in this thread specific to R5E50? I'm wondering if maybe what i'm seeing here (http://mysettopbox.tv/phpBB2/viewtopic.php?t=13605) is perhaps the same thing? I'm running R5D1 at the moment.
Author:  the_manowar [ Sat Jan 20, 2007 4:14 am ]
Post subject: 
Krem1120 wrote:
Do your script ever end up working? I seem to be experiencing a issue similar to this...


I have not seen any evidence of the problem since applying the above changes.
Author:  the_manowar [ Sat Jan 20, 2007 4:20 am ]
Post subject: 
rando wrote:
Is the problem in this thread specific to R5E50? I'm wondering if maybe what i'm seeing here (http://mysettopbox.tv/phpBB2/viewtopic.php?t=13605) is perhaps the same thing? I'm running R5D1 at the moment.


I don't think that is the same problem.

When your problem occurs, is the mythbackend process still running?

Does doing a:
Code:
netstat -lnp


show entries similar to:

Code:
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN     2790/mysqld
tcp        0      0 0.0.0.0:6543            0.0.0.0:*               LISTEN     3028/mythbackend
tcp        0      0 0.0.0.0:6544            0.0.0.0:*               LISTEN     3028/mythbackend
tcp        0      0 0.0.0.0:6546            0.0.0.0:*               LISTEN     24370/mythfrontend


Is there anything interesting in /var/log/mythtv/mythbackend.log?
Author:  rando [ Sat Jan 20, 2007 9:46 am ]
Post subject: 
Let's carry this discussion out in my thread, I'd hate to hijack something else that's on the go....

http://mysettopbox.tv/phpBB2/viewtopic.php?t=13605
Author:  Tarwn [ Sat Jan 20, 2007 2:36 pm ]
Post subject: 
i just noticed this thread. I was suspecting it might be a leftover PID from the way that start/stop/restart was function on the startup script. It would make sense if the PID was not getting cleaned up that we would be forced to do a restart (and get the message about not being able to actually find a running instance of myth-backend).

I'll be adding your changes to my startup script tomorrow as this has been an issue for me as well.
Author:  tjc [ Sat Jan 20, 2007 3:08 pm ]
Post subject: 
Known. Well understood. Fix here for the search averse: http://mysettopbox.tv/phpBB2/viewtopic. ... htvbackend
Page 1 of 2 All times are UTC - 6 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/