[mythtv-commits] Ticket #10633: Network Control socket fails to listen on second address

[MythTV]

#10633: Network Control socket fails to listen on second address
-------------------------------------+--------------------------
 Reporter:  Paul Saunders <darac@…>  |          Owner:  pbennett
     Type:  Bug Report - General     |         Status:  new
 Priority:  minor                    |      Milestone:  0.27.7
Component:  MythTV - General         |        Version:  0.25
 Severity:  medium                   |     Resolution:
 Keywords:                           |  Ticket locked:  0
-------------------------------------+--------------------------

Comment (by cas@…):

 The problem is caused by the fact that you're trying to listen on a port
 using a http proxy.

 That makes no sense.  There are no circumstances where that makes any
 sense at all.  It is not a thing that can or should be done. It does not
 and can not work.

 The solution is to NOT do that.

 The fact that you your response includes "People may use a proxy for
 tunnelling or other things" indicates that you do not know the subject
 matter well enough to make a judgement on this - it looks like code for "i
 don't know but maybe we did this sometime for some good reason that
 someone, somewhere knows".   I can understand a reluctance to not mess
 with something you're not an expert on but there isn't any good reason for
 doing this, not one.  This is a bug, nothing more.  If anyone did need to
 do anything like that, there is no way they ever would or could do it via
 a web proxy.

 BTW, did you notice that doc.qt.io link you posted **ONLY** mentioned
 binding to a port for a socks5 proxy?  Not for http or ftp proxies?  That
 it even says "**supports only outgoing TCP connections**" for them?
 That's because web & ftp proxies don't support that.  They are for
 clients, not servers of any kind.  It's a good idea to use the proxy for
 outgoing requests (http/https/ftp or whatever), not for listening on a
 port for incoming connections.

 But you don't have to believe me (I've been doing network admin on unix
 systems for over 30 years, but you don't know me or my knowledge or my
 level of expertise).  Find a recognised networking expert you know and
 trust, or ask on Stack Exchange or something.

 If anyone does need or want to set up a socks proxy or ssh port forwarding
 or vpn or tunnel or whatever else for whatever weird network configuration
 they have or need, that's something that can and **should** be done
 outside of an application like MythTV.  Do one thing and do it well.  That
 one thing for MythTV is to be a great, full featured media scheduling,
 recording, and playback application.  Leave networking in all its weird
 and wonderful special cases to networking tools - that is their speciality
 and they will do it far better than MythTV ever can or will.  This is out
 of scope for a media application.

 Worse, by using the `http_proxy` env var in this way, you are making it
 unnecessarily more difficult for those who do have unusual or complex
 networking needs.  Having to `unset http_proxy` just to get mythbackend
 running is certainly making it difficult for those who run myth behind any
 kind of firewall and need any data-fetching scripts called by myth (e.g.
 to fetch from IMDB or other video info sources) to use the local web
 proxy.

--
Ticket URL: <https://code.mythtv.org/trac/ticket/10633#comment:33>
MythTV <http://www.mythtv.org>
MythTV Media Center