Opened 14 years ago
Closed 14 years ago
#10815 closed Bug Report - General (fixed)
MythWelcome binds to port 6948, MythFrontend unable to use MythMessage
| Reported by: | Owned by: | Raymond Wagner | |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.26 |
| Component: | MythTV - Mythwelcome & Mythshutdown | Version: | 0.25-fixes |
| Severity: | medium | Keywords: | |
| Cc: | Ticket locked: | no |
Description
MythWelcome binds to port 6948, thus making it impossible for MythFrontend to bind to that port. This means thatmythuitl --message is unable to send a message to the frontend.
Steps to reproduce:
- Start MythWelcome
- Start MythFrontend from MythWelcome
- Run {{{mythutil --message --message_text "Hello World" --timeout 60
Expected result: Seeing "Hello World" on my TV.
Actual result: Output on TV is the same as before, no popup.
Note: Messaging works as expected if MythWelcome is not running.
Attached:
- mythwelcome log file (where we can see it binds to the port)
- mythfrontend log file (where we can see the port is in use)
- mythfrontend --version
Attachments (3)
Change History (5)
by , 14 years ago
| Attachment: | mythfrontend.log added |
|---|
by , 14 years ago
| Attachment: | mythfrontend-version.log added |
|---|
by , 14 years ago
| Attachment: | mythwelcome.log added |
|---|
comment:1 by , 14 years ago
| Milestone: | unknown → 0.26 |
|---|---|
| Owner: | set to |
| Status: | new → accepted |
comment:2 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | accepted → closed |
Note:
See TracTickets
for help on using tickets.

I actually thought there was another open ticket for this, but I can't find one. I have discussed this with Stuart Morgen in the past few weeks. There's a couple options here. With Stuart's "idle mode" frontend, there is little reason why MythWelcome wouldn't dissolve into MythFrontend, and MythShutdown into MythBackend, making the problem just go away. I could add a hook into the MythSystem class, allowing the listen server to be taken down when the UI stop listening for other input events. I could add checks in the ServerPool class for broadcast and multicast addresses, to allow reuse. The second and third ones should likely be done anyway, even if the first happens.