Opened 12 years ago

Closed 12 years ago

#3803 closed defect (fixed)

mac osx frontend freeze when trying to connect to linux backend

Reported by: anonymous Owned by: Nigel
Priority: major Milestone: 0.21
Component: mythtv Version: head
Severity: high Keywords:
Cc: Ticket locked: no

Description

When trying to get macosx frontend with current svn to connect to current backend on linux box, the mac osx frontend hangs..

Change History (8)

comment:1 Changed 12 years ago by Nigel

We need more information about the freeze. Is there anything on the console? (e.g. open Console.app and look) Is the backend getting any network traffic? (e.g. run sudo tcpdump host IP-ADDRESS-OF-MAC )

Please reopen this ticket with that sort of information included.

comment:2 Changed 12 years ago by anonymous

I didn't know I could add to this.. Ticket was resummitted as #3808...

I'm adding info here too.. But you can close one since they are the same..

Using svn 14150 or anything near it Trying to connnect to linux backend at 192.168.1.106 If the backend is up and settings appear to be correct the frontend never comes up. If I shut the backend down the frontend will come up, but obviously w/o a connectiong..

TCP Dump When Launching front end.. tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 96 bytes 16:52:15.259906 IP (tos 0x0, ttl 64, id 35623, offset 0, flags [DF], proto: TCP (6), length: 64, bad cksum 0 (->2b69)!) 192.168.1.109.53787 > 192.168.1.106.lds-distrib: S, cksum 0x845a (incorrect (-> 0x671c), 471959475:471959475(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 910460410 0,sackOK,eol> 16:52:15.260163 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.1.106.lds-distrib > 192.168.1.109.53787: S, cksum 0xaf26 (correct), 3517135507:3517135507(0) ack 471959476 win 5792 <mss 1460,sackOK,timestamp 246912852 910460410,nop,wscale 7> 16:52:15.260216 IP (tos 0x0, ttl 64, id 35624, offset 0, flags [DF], proto: TCP (6), length: 52, bad cksum 0 (->2b74)!) 192.168.1.109.53787 > 192.168.1.106.lds-distrib: ., cksum 0x844e (incorrect (-> 0xf492), ack 1 win 65535 <nop,nop,timestamp 910460410 246912852>

after which the frontend just sits there (shows not responding in the force quit menu)

if I run the frontend from a shell and use ctrl-c to end it after it hangs.. I get this additional tcpdump

16:54:09.944895 IP (tos 0x8, ttl 64, id 35681, offset 0, flags [DF], proto: TCP (6), length: 52, bad cksum 0 (->2b33)!) 192.168.1.109.53787 > 192.168.1.106.lds-distrib: F, cksum 0x844e (incorrect (-> 0xf3ac), 1:1(0) ack 1 win 65535 <nop,nop,timestamp 910460639 246912852> 16:54:09.945244 IP (tos 0x0, ttl 64, id 44480, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.106.lds-distrib > 192.168.1.109.53787: F, cksum 0x3369 (correct), 1:1(0) ack 2 win 46 <nop,nop,timestamp 247027559 910460639> 16:54:10.146868 IP (tos 0x0, ttl 64, id 44481, offset 0, flags [DF], proto: TCP (6), length: 52) 192.168.1.106.lds-distrib > 192.168.1.109.53787: F, cksum 0x329f (correct), 1:1(0) ack 2 win 46 <nop,nop,timestamp 247027761 910460639> 16:54:10.146919 IP (tos 0x8, ttl 64, id 35682, offset 0, flags [DF], proto: TCP (6), length: 52, bad cksum 0 (->2b32)!) 192.168.1.109.53787 > 192.168.1.106.lds-distrib: ., cksum 0x844e (incorrect (-> 0x32cc), ack 2 win 65535 <nop,nop,timestamp 910460640 247027761>

the output from the front end when I run from the shell is.. the first and last lines represent the shell commmand to start, and the shell prompt after ctrl-c to kill it

terminal$ /Applications/MythFrontend?.app/Contents/MacOS/MythFrontend -v all 2007-08-06 16:52:15.232 Using runtime prefix = /Applications/MythFrontend?.app/Contents/Resources 2007-08-06 16:52:15.241 New DB connection, total: 1 C terminal$

using same setup and db,etc I can connect using the downgrade server to 20fixes and use 20fix osx frontend and it instantly connects.. (I am however unable to play video files as it says they cant be found, but I am assuming this is a db difference or soemthing between the versions..)

anyhow...

tx..

p.s. with the same settings running a 20fixes backend build, and using a 20fixes OSX frontend, everythings works...

comment:3 Changed 12 years ago by anonymous

here's the answer.. Apparently the problem is that the frontend is not finding the mysql server..

DBPort was incorrectly set to 6543 (I haven't seen any docs refer to setting this to mysql server port, my assumption was that DB was talking about the backend)

Apparently the design is to find the mysql database, and from there find the backend

20fixes would still find mysql server even though the DBPort was set incorrectly to the backend port.

svn will not find the mysql server, and will hang w/o error message.

Outside of the possibility of putting an error message when the mysql server cant be found, this can be closed..

comment:4 Changed 12 years ago by Nigel

Owner: changed from Isaac Richards to Nigel
Status: newassigned

It is probably time to add code for the situation where the database is not reachable. It has been a particular problem on the Mac client for years (mainly because Mac users don't see the hundreds of "Can't connect to MySQL server on '127.0.0.1' (61)" errors unless they have Console.app open). Now that there is another way it can be broken (DBPort bad), I think a showOkPopup may be appropriate.

comment:5 Changed 12 years ago by Nigel

(In [14203]) New fn's for ping/telnet. Will be used when checking for DB host. See #3803

comment:6 Changed 12 years ago by Nigel

Resolution: fixed
Status: assignedclosed

(In [14205]) Re-enable command-line database prompting that [5741] disabled, and put extra database connectivity checking in before the initial MSqlQuery. Bad DBHost should now be detected quickly (3 secs) instead of after a few minutes (in the case of non-routable addresses). Also checks DBport. Closes #3803.

Have tested lots with Mac frontend, but not much on Linux.

Hope this doesn't clash too much with future "backend autodetect" changes.

comment:7 Changed 12 years ago by Nigel

Resolution: fixed
Status: closedreopened

I didn't deal with the situation where the server/network doesn't respond to pings. Easiest fix is to put a new field in mysql.txt that makes that optional.

comment:8 Changed 12 years ago by Nigel

Resolution: fixed
Status: reopenedclosed

(In [14239]) UI for optional database ping, command-line equivalent for same, extra doco. in generated mysql.txt, fix broken WOL default in command-line code. Closes #3803

Note: See TracTickets for help on using tickets.