SageClient Server Discovery Issues

[Jabroni]

Wondering if someone could comment on what else should I do. Im trying to figure out why my SageTV Client wont autopopulate the server info on my desktop when launching the client.

SageTV Server runs on a Win8 VM (9.0.12)
SageTV Client 9 on Windows 10

- Both machines have the Windows Firewall Disabled
- Both machines show the network as "Private" within windows.
- Tried running the SageClient as 'Run as administrator'
- Both machines are within the same subnet, with static ips
- If I try from my Laptop, the SageClient does seem to populate fine the Server Discovery
- Tried removing / reinstalling the SageClient
- Placeshifter does discovery the server correctly on load
- On my client machine, running Wireshark for network sniffing, I see a UDP broadcast on 8270, then a reply from my SageTV IP to my Desktop IP on port 8271 with a text someting like "STV ServerName"
- On the Sagetvclient_0.txt I see the entry

Mon 2/13 23:23:51.197 [main@74cd4d] SageTV V9.0.13.536
Mon 2/13 23:23:51.204 [main@74cd4d] hostname=DESKTOP
Mon 2/13 23:23:51.207 [main@74cd4d] Splash: Discovering SageTV Servers...
Mon 2/13 23:23:51.212 [main@74cd4d] Sending out discovery packets to find SageTV Servers...
Mon 2/13 23:23:51.229 [main@74cd4d] Discovery packet received:java.net.DatagramPacket@6824be from /192.168.1.4:8270
Mon 2/13 23:23:51.232 [main@74cd4d] Server info 9.0.12

However it stills just load a blank form to fill with IP, if i input the IP it connects fine

Hope someone can give me some more ideas on what else Im missing to try

[Fuzzy]

Versions don't match. Server and Client versions need to match for it to consider it a valid target. (specificly, it is checked here: https://github.com/google/sagetv/blo...ient.java#L936)

It seems like it might be wise to add an else statement to that line to debug that it was ignored due to a version mismatch.

EDIT: Technically, versions don't have to match, but the server has to be equal or newer than the client. In your case, the opposite is true (running 9.0.12 server with a 9.0.13 client).

[EnterNoEscape]

Originally Posted by Fuzzy

EDIT: Technically, versions don't have to match, but the server has to be equal or newer than the client. In your case, the opposite is true (running 9.0.12 server with a 9.0.13 client).

Don't count on that. I experience problems when I was testing the database upgrade that I was writing for 9.0.13. I was testing with a remote client they needed to match or I got strange errors that broke things for that client session badly while it was syncing from the database. The placeshifter/miniclient is the only time it generally doesn't matter. There's a good reason why the versions are enforced for the client.

[Jabroni]

Originally Posted by Fuzzy

Versions don't match. Server and Client versions need to match for it to consider it a valid target. (specificly, it is checked here: https://github.com/google/sagetv/blo...ient.java#L936)

It seems like it might be wise to add an else statement to that line to debug that it was ignored due to a version mismatch.

EDIT: Technically, versions don't have to match, but the server has to be equal or newer than the client. In your case, the opposite is true (running 9.0.12 server with a 9.0.13 client).

Thank you for the comment. I can confirm that was the issue. I upgraded the SageTV server jar and now the client discovers fine the server I knew it has something to do within Sage rather than issue with firewall or network (since all previous threads always pointed to that direction). The only good thing bout this is that I discovered that there is a autoconnect_server_hostname= on the SageClient.properties file that can do the trick too and connects faster since it doesnt need to discover the server

[Fuzzy]

Originally Posted by EnterNoEscape

Don't count on that. I experience problems when I was testing the database upgrade that I was writing for 9.0.13. I was testing with a remote client they needed to match or I got strange errors that broke things for that client session badly while it was syncing from the database. The placeshifter/miniclient is the only time it generally doesn't matter. There's a good reason why the versions are enforced for the client.

Sorry, I wasn't trying to imply that mismatches would "work" - just that it only checks that the server is newer than the client before presenting that server as an option.

[EnterNoEscape]

Originally Posted by Fuzzy

Sorry, I wasn't trying to imply that mismatches would "work" - just that it only checks that the server is newer than the client before presenting that server as an option.

Gotcha. That is truish. It actually checks the minimum client version on the server (not the server version).

[Fuzzy]

Originally Posted by EnterNoEscape

Gotcha. That is truish. It actually checks the minimum client version on the server (not the server version).

It's sort of a two way street. The client broadcasts out on the network with it's actual version (in his case above, 9.0.13) (this is in NetworkClient.java). The server receives the broadcast packet and checks that the client version is >= the CLIENT_COMPATIBLE version that is coded into the server (as set in Sage.java). The server then sends back a packet with the server's actual version - among other things, like port, hostname, etc (this is in SageTV.java), which the client (back in NetworkClient.java) verifies is greater than or equal to it's own version before adding it to the list of servers and allowing the user to connect to it.

This essentially means that the only combination that will work is:
SERVER >= CLIENT >= CLIENT_COMPATIBLE

Which is fine, as long as CLIENT_COMPATIBLE is always updated when a change to either the database, or the client-server architecture warrants it. Currently, the CLIENT_COMPATIBLE in the 9.0.13 server is set to 9.0.13. That doesn't NEED to always be the case though, and if we are changing code that doesn't touch the things I listed, it would make sense to not match those, so the server can be upgraded without needing to upgrade every client (this is the main reason there IS a CLIENT_COMPATIBLE version. It would certainly me nice is we could implement some sort of notice when a version incompatibility is preventing connection, especially not that the unRAID Docker server will automatically update on restarts.

[EnterNoEscape]

Originally Posted by Fuzzy

It would certainly me nice is we could implement some sort of notice when a version incompatibility is preventing connection, especially not that the unRAID Docker server will automatically update on restarts.

If you explicitly type in the server name and try to connect with the full client, it will tell you that the versions are incompatible.

[Fuzzy]

Originally Posted by EnterNoEscape

If you explicitly type in the server name and try to connect with the full client, it will tell you that the versions are incompatible.

Actually, in his case, it will connect without complaint, because THAT check is just that the CLIENT >= the CLIENT_COMPATIBLE version.