Setting DBPort to MythTV port cause frontend to hang with no gui display rather than error

[bits@…]

So, this started out out as a stupid user error due to other issues that were my own fault, but it caused a good 2 days of headaches.

At some point in my debugging of a bad backend setup, I set DBPort=6543 in mysql.txt on the frontend.

The result is that the frontend starts, appears to connect to the db, does some UPNP stuff, and then just hangs there indefinitely never showing a GUI at all.

I'm a newbie to MythTV so this would probably be obvious to someone whos done it before, and I should have known that wasn't the standard mysql port, but no error makes it a PITA to deal with.

I'm guessing this is really an issue with the mysql libraries not reporting an error or timing out since the port is open and connects, but I've not developed with mysql or looked at the mythtv source so I figured I'd leave it to the experts.

[anonymous]

TRAC wouldn't let me attach the output of mythfrontend.real -v all so here it on pastebin:

​http://pastebin.org/48888

Also, the output of the mythbuntu log grabber is here:

​http://mythbuntu.pastebin.com/m34471c13

[bits@…]

Version info: I installed mythbuntu 9.10RC, and updated with apt-get update/upgrade around 5pm on Oct 27th, 2009

mythfrontend --version xprop: unable to open display Please include all output in bug reports. MythTV Version : 22594 MythTV Branch : branches/release-0-22-fixes Network Protocol : 50 Library API : 0.22.20091023-1 QT Version : 4.5.2 Options compiled in:

linux profile using_oss using_alsa using_pulse using_jack using_backend using_dvb using_firewire using_frontend using_glx_proc_addr_arb using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_libavc_5_3 using_live using_mheg

[Nigel]

Any mythtv program will hang, not just the frontend. e.g. mythbackend in gdb:

2010-01-21 16:27:54.444 MCP::DefaultUPnP() - No default UPnP backend
2010-01-21 16:27:54.444 MythSocket(4b190e0:8): new socket
2010-01-21 16:27:54.447 MythSocket(4b190e0:8): attempting connect() to (149.135.128.77:6543)
2010-01-21 16:27:54.448 MythSocket(4b190e0:8): state change Idle -> Connected
2010-01-21 16:27:54.448 MythSocket(4b190e0:8): state change Connected -> Idle
2010-01-21 16:27:54.448 MSocketDevice::close: Closed socket 8
2010-01-21 16:27:54.448 Clearing Settings Cache.
2010-01-21 16:27:54.449 New DB connection, total: 1
^C
Program received signal SIGINT, Interrupt.
0x944f5bf9 in read$UNIX2003 ()
(gdb) where
#0  0x944f5bf9 in read$UNIX2003 ()
#1  0x01d5cbaf in vio_read ()
#2  0x01d5cc75 in vio_read_buff ()
#3  0x01d5dee4 in my_real_read ()
#4  0x01d5e16b in my_net_read ()
#5  0x01d5526e in cli_safe_read ()
#6  0x01d57df9 in mysql_real_connect ()
#7  0x01cf3348 in QMYSQLDriver::open ()
#8  0x01cde811 in QSqlDatabase::open ()
#9  0x01a6da61 in MSqlDatabase::OpenDatabase ()

This is a hard problem to detect. Unless we add a timer to check for timeouts on all connections, (or maybe the initial database connection), a program would never know the port isn't a valid MySQL listener.

[robertm]

Misconfigured system caused issue.