Reply to thread

Message

Hi,

The network configurations that you are referring to are pretty rare for HTPC usage, although some of them will be handled better in MP2. For MP1 however I believe these are quite extreme and some even impossible.

This is not as simple as it may sound. Even if you could configure TVServer with the external IP, TVServer would still need to somehow find out where the initial call came from (internally or external) to decide which IP to return. This detection is not possible AFAIK using .Net Remoting (which is what TVServer uses). Furthermore even if it were possible you would have to somehow configure some rules to help determine which IP addresses are internal. And even if we use a IP/Subnet mask as filter there will always be someone with a more complex net config (e.g. multiple subnets, multiple NAT gateways etc).
Still the RTSP protocol requires that the streaming server address be passed in an SDP response, and the RTSP library (live555) cannot be configured to return the external address when the request comes from an external client (and again would require to do the same detection).

This has been disabled on purpose, because the library (live555) used to implement RSTP had issues when listening to 0.0.0.0. It is not clear if the new version of the library has fixed those issues but there is an indication that it has. It would however need extensive testing to verify that re-enabling 0.0.0.0 does not break anything and certainly too risky for 1.1.0 at the stage it was when the library was updated to the new version. Provided enough test is performed, this could be re-enabled in the future (probably post 1.2.0).

Not sure what you mean by this. If you mean that your DB server has 2 IPs and you want clients to connect to one but TVServer to connect to the other, you don't need any more configuration options in TVServer. Just use split-DNS or hosts file in TVServer.

Something of the sort is being considered for MP2 but a lot of the details and use cases need to be decided. Primary concern here is usability. We want to have a user management system that is both simple and effective to use as it is powerful enough to handle most user's needs.

In general I don't like being negative, and these are all valid issues. However we always have to consider the percentage of the user base that will benefit from each feature vs the amount of work and risk involved in its implementation. The team's resources are rather limited and priorities have to be set.

<blockquote data-quote="arion_p" data-source="post: 639067" data-attributes="member: 45945">Hi,The network configurations that you are referring to are pretty rare for HTPC usage, although some of them will be handled better in MP2. For MP1 however I believe these are quite extreme and some even impossible.This is not as simple as it may sound. Even if you could configure TVServer with the external IP, TVServer would still need to somehow find out where the initial call came from (internally or external) to decide which IP to return. This detection is not possible AFAIK using .Net Remoting (which is what TVServer uses). Furthermore even if it were possible you would have to somehow configure some rules to help determine which IP addresses are internal. And even if we use a IP/Subnet mask as filter there will always be someone with a more complex net config (e.g. multiple subnets, multiple NAT gateways etc).Still the RTSP protocol requires that the streaming server address be passed in an SDP response, and the RTSP library (live555) cannot be configured to return the external address when the request comes from an external client (and again would require to do the same detection).This has been disabled on purpose, because the library (live555) used to implement RSTP had issues when listening to 0.0.0.0. It is not clear if the new version of the library has fixed those issues but there is an indication that it has. It would however need extensive testing to verify that re-enabling 0.0.0.0 does not break anything and certainly too risky for 1.1.0 at the stage it was when the library was updated to the new version. Provided enough test is performed, this could be re-enabled in the future (probably post 1.2.0).Not sure what you mean by this. If you mean that your DB server has 2 IPs and you want clients to connect to one but TVServer to connect to the other, you don't need any more configuration options in TVServer. Just use split-DNS or hosts file in TVServer.Something of the sort is being considered for MP2 but a lot of the details and use cases need to be decided. Primary concern here is usability. We want to have a user management system that is both simple and effective to use as it is powerful enough to handle most user's needs.In general I don't like being negative, and these are all valid issues. However we always have to consider the percentage of the user base that will benefit from each feature vs the amount of work and risk involved in its implementation.&nbsp; The team's resources are rather limited and priorities have to be set.</blockquote>

[QUOTE="arion_p, post: 639067, member: 45945"] Hi, The network configurations that you are referring to are pretty rare for HTPC usage, although some of them will be handled better in MP2. For MP1 however I believe these are quite extreme and some even impossible. This is not as simple as it may sound. Even if you could configure TVServer with the external IP, TVServer would still need to somehow find out where the initial call came from (internally or external) to decide which IP to return. This detection is not possible AFAIK using .Net Remoting (which is what TVServer uses). Furthermore even if it were possible you would have to somehow configure some rules to help determine which IP addresses are internal. And even if we use a IP/Subnet mask as filter there will always be someone with a more complex net config (e.g. multiple subnets, multiple NAT gateways etc). Still the RTSP protocol requires that the streaming server address be passed in an SDP response, and the RTSP library (live555) cannot be configured to return the external address when the request comes from an external client (and again would require to do the same detection). This has been disabled on purpose, because the library (live555) used to implement RSTP had issues when listening to 0.0.0.0. It is not clear if the new version of the library has fixed those issues but there is an indication that it has. It would however need extensive testing to verify that re-enabling 0.0.0.0 does not break anything and certainly too risky for 1.1.0 at the stage it was when the library was updated to the new version. Provided enough test is performed, this could be re-enabled in the future (probably post 1.2.0). Not sure what you mean by this. If you mean that your DB server has 2 IPs and you want clients to connect to one but TVServer to connect to the other, you don't need any more configuration options in TVServer. Just use split-DNS or hosts file in TVServer. Something of the sort is being considered for MP2 but a lot of the details and use cases need to be decided. Primary concern here is usability. We want to have a user management system that is both simple and effective to use as it is powerful enough to handle most user's needs. In general I don't like being negative, and these are all valid issues. However we always have to consider the percentage of the user base that will benefit from each feature vs the amount of work and risk involved in its implementation. The team's resources are rather limited and priorities have to be set. [/QUOTE]