HLS of content from Video SG broken

[robertm]

Somewhere in the bast few months, HLS streaming of content from the Videos SG has been broken. The backend allows the creation of the HLS Job (URL constructed automatically with the information provided by the backend itself) but then hangs forever on "Starting."

Log enclosed. The issue appears to be one of hostname case sensitivity-- the relevant log section is:

2012-03-25 22:56:20.066794 E RemoteFile::openSocket(control socket): Could not connect to server holmes:6543 2012-03-25 22:56:20.066815 E FileRingBuf(myth://Videos@holmes/Avatar.m2ts): RingBuffer::RingBuffer(): Failed to open remote file (myth://Videos@holmes/Avatar.m2ts)

The output of the "hostname" command on the BE is "Holmes." Something in the remotefile/socket code has changed in the past several months such that the case difference is no longer allowed-- the options are threefold:

1) change the video scanner to insert the proper case (this hasn't mattered in the past) 2) Fix the remotefile to not care about case again 3) 1 and 2

Regardless, anyone with mixed-case backend hostnames will likely find HLS non-functional for video content at the moment.

[robertm]

I should have made clear-- hardcoding "Holmes" as the host in the URL (versus the "holmes" stored by the video scanner as it has for a number of years) allows the transcode to begin.

[Raymond Wagner]

Adds final attempt at internal name resolution in MythSocket.

This adds one last pass at name resolution through the database before falling back on the system name resolution. This corrects an issue on Debian systems caused by their non-standard use of a 127.0.1.1 address we do not listen on. There is potential for problem should MythSocket::connect be called during CoreContext init, but a read through the init code did not turn up any instances where this might occur.

Fixes #10510

Branch: master Changeset: 885ca53fd839c43fd964c69046ada3b0ef84c928