stuart wrote:
>
> Tom Metro wrote:
>> Simon Hyde wrote:
>>> It looks like you've got your backend's IP address configured as
>>> 127.0.0.1 in your MythTV settings...
>> Ah, good catch. That makes perfect sense.
>>
>> Someone should add this to the FAQ or MythTV troubleshooting section of
>> the wiki.
>
> Well, you could. But I think this configuration "gotcha" is valid for
> any myth front end running on a different box from the server. The
> 127.0.0.1 default is more for security. That is, the default is to run
> both the front and back end on the same box and not allow external access.
>
>>> Perhaps in the future we should make mvpmc behave differently when it
>>> receives 127.0.0.1 back from MythTV, and connect to the IP address
>>> specified by the -s option, but it doesn't do this at the moment.
>> Perhaps. When we see the loopback address, we know for sure it is wrong,
>> but using the -s address is just the best guess, that will work most of
>> the time, though not necessarily always. Would an automatic fallback to
>> -s make the problem even tougher to detect in the rare case when that
>> isn't the right address? (Resulting in even more misleading error messages?)
>>
>> The straight forward thing to do is display a more specific error
>> message directing directing the user to their MythTV back-end settings.
>>
>> -Tom
>
> I'm guessing, but I think your thinking of a scenario where there are
> multiple myth backends. I assume the -s option is assigned the master
> back end's IP. Then, if you tried to pull a recording off another back
> end which was incorrectly configured for supporting external front ends,
> the mvpmc box would, reverting to the -s command line's IP number, try
> to pull the recording off the master.
>
> Do I have that right? Wow, imagine putting that into a warning mvpmc popup!
>
I think there is more complications than that.
There is another situation that seems to cause mvpmc issues, if you have an old
slave backend that you got rid of, the myth db still contains the hostname
pointing to that old slave backend, mvpmc will actually *crash* and restart
when
you try to access one of those recordings, oddly enough the old slave not being
there does not appear to affect real myth frontends. Bring back up the old
slave's mythbackend will result in the recording working. This is even if
you
are fully using NFS for reading the recordings, and actually causes the crash
before it even tries to read the NFS file.
I am not sure how to best solve that issue, it may be best to figure out the
reason for the crash, and properly catch it, and if the host (whether it be
localhost or a no longer there slave) and fall back to the "-s" address.
Roger
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Mvpmc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mvpmc-users
mvpmc wiki: http://mvpmc.wikispaces.com/
