Can not watch tv from remote clients (2 Viewers)

TLD

Portal Pro
October 26, 2007
948
386
Rainy Washington
Home Country
United States of America United States of America
I did the VLC test and was able to watch the stream with windows firewall still up. the firewall did the allow program popup i clicked allow and the stream played.
I checked the firewall allowed program settings and VLC and Mediaportal have the same allow settings (Private network box ticked)
I have TV recordings going so i can't restart the computer right now and will be busy tomorrow so will do the firewall test Friday.
Thanks.
 

TLD

Portal Pro
October 26, 2007
948
386
Rainy Washington
Home Country
United States of America United States of America
Here are the logs from the TV server and remote client with the firewalls off and windows restarted.
It still didn't work.
 

Attachments

  • MP logs.zip
    1.2 MB

mm1352000

Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    Thanks for the new log files. Short summary would be that I can't see any significant differences from the previous log files.

    Interestingly, it appears like the remote client is able to acquire the stream description and duration from the streaming server:
    [2020-02-13 11:16:21,335] [139A7098] [2c38] - CRTSPClient::OpenStream(): duration = 1.180000 s
    [2020-02-13 11:16:21,338] [139A7098] [2c38] - CRTSPClient::OpenStream(): created receiver for sub-session, medium name = video, codec name = MP2T, port = 49302

    The client just can't start streaming for some reason. Very odd!

    I wonder if the timeout error message:
    [2020-02-13 11:16:21,338] [139A7098] [2c38] - CRTSPClient::confused:etupStreams(): send RTSP SETUP
    [2020-02-13 11:16:21,839] [139A7098] [2c38] - CRTSPClient::confused:etupStreams(): RTSP SETUP timed out

    ...is actually pointing directly to the problem. In other words: rather than a firewall intercepting the communication, maybe the server is just a little slow to respond due to network links (wireless network?) and disk speed (system and/or timeshift disks on the server are HDDs or SSDs?).

    There are several ways we could move forward from here.

    Option one would be to actually check the timeout theory. This could be done by using a network traffic monitor such as Wireshark on the client and/or server to confirm that the RTSP SETUP command is sent by the client, received by the server, and acknowledged by the server. Assuming the SETUP acknowledgement is sent by the server, it would be possible to measure how long it takes for the client to receive that acknowledgement. Normally this whole process should be very fast - maybe a tenth of a second at most. The error message quoted above indicates that in your case no acknowledgement was received after half a second.

    Option two would be to assume the timeout theory is correct, and try to give the server more time to do what it needs to do. This is probably easier than the first option, but again, it does make the assumption that the timeout theory is correct. The mechanism for giving the server more time is to add/modify one of TsReader's settings. TsReader's settings are stored in the Windows system registry. I've attached a zip file containing scripts that should enable you to make the change fairly easily:
    1. On the remote client, download and extract TsReader_RTSP_registry_settings.zip to a convenient location.
    2. Close MediaPortal.
    3. Run (double click) the "set_2_seconds.reg" file to make the change. You may have to click "yes" to accept security warnings.
    4. Open MediaPortal and test whether TV works.
    5. (To undo the changes, close MediaPortal and run "reset_to_default.reg".)
    Please note that changing the contents of the Windows system registry is not something I'd recommend lightly. Some of the most important Windows and program settings are stored in there. Without meaning to frighten you, a bad modification could cause a PC to stop working, break or change the behaviour of installed programs, or open security loopholes. Though I can hand-on-heart say I have zero interest in wrecking your setup, I'd still recommend that you exercise caution. Feel free to have a look at the contents of the scripts (right click -> edit) that I've provided. (The setting I intend to add/change is TsReader's RtspGenericTimeoutInMilliSeconds.)

    Option three would be to try an alternative way of accessing TV from the server. Specifically: you can configure MediaPortal and TV Server to use shares ("UNC paths") rather than RTSP streaming. The details are in the wiki here:

    Given that you've mentioned you have shares working already, this might not be a bad option to consider.
     

    Attachments

    • TsReader_RTSP_registry_settings.zip
      692 bytes

    TLD

    Portal Pro
    October 26, 2007
    948
    386
    Rainy Washington
    Home Country
    United States of America United States of America
    The network is wired and The server has windows on a SSD and the timeshift on a sata III 6Gps HD. The remote client has windows on an SSD.
    Right now i don't have another SSD to clone the OS of the remote client too that will be next month (lack of funds) and while i do trust you and have used regedit in the past I just feel safer with a clone on the shelf, so i will try the UNC route for now and do the registry hack after i get another SSD.
    I have downloaded the bat file for future use.
    I do find it odd that this setup has not changed for a couple years other that windows updates and upgrading MP and use to work.
    Edit: forgot to mention it's a Gigabit network.
     
    Last edited:

    mm1352000

    Retired Team Member
  • Premium Supporter
  • September 1, 2008
    21,577
    8,224
    Home Country
    New Zealand New Zealand
    UNC option works fine, is there a down side to using this method.
    Good question. I've never really thought about it, but now that you ask: nothing major that I'm aware of.

    As far as I'm aware RTSP has always been the default. I'd guess that's because it doesn't require much additional setup/configuration, is reasonably reliable, and Just Works for most people. My observation over the years is that UNC has only come up when people have experienced problems with RTSP or specifically asked about/for UNC.

    In terms of advantages and disadvantages, like I said, RTSP is probably considered easier to get working for most people. My understanding is that historically UNC had slightly better latency - less lag between selecting a channel and video/audio starting, and also better responsiveness for seeking/fast-forward/rewind. A few years ago Owlsroost did some work to improve RTSP's latency, so these days I'm not sure if UNC's advantage still applies.

    Anyway, I'm still interested to know whether the TsReader setting change enables RTSP to work in your setup, or whether the issue is something else. It's always nice to figure out the cause of an issue. However, given that UNC works, I'd understand if you don't have the time/inclination to test.
     

    TLD

    Portal Pro
    October 26, 2007
    948
    386
    Rainy Washington
    Home Country
    United States of America United States of America
    Anyway, I'm still interested to know whether the TsReader setting change enables RTSP to work in your setup, or whether the issue is something else. It's always nice to figure out the cause of an issue. However, given that UNC works, I'd understand if you don't have the time/inclination to test.

    Tried the bat file and it didn't work. logs attached
     

    Attachments

    • MP_remote_client_log.zip
      194.6 KB

    crusadre

    MP Donator
  • Premium Supporter
  • April 22, 2020
    9
    3
    Home Country
    United States of America United States of America
    TLD - did you ever get it working? I am in the same boat: server is running fine and I can watch tv using the client on the server computer; but none of my remote clients (computers on the same network) are able to watch a channel - getting "unable to play: stream8". In the remote client 'MediaPortal Configuration' under "TV/Radio" I have the IP address and the Test Connection is successful. Firewall is completely disabled on the server and the clients. I am using MP 1.24; and using a HDHomeRun Prime box with 3 tuners. I cleared the log files and then had one of the clients attempt to watch a channel (see attached logs). I have been messing with this for 2 weeks so any help would be much appreciated!
     

    Attachments

    • MP_tv_logs.zip
      6.1 KB

    TLD

    Portal Pro
    October 26, 2007
    948
    386
    Rainy Washington
    Home Country
    United States of America United States of America
    TLD - did you ever get it working? I am in the same boat: server is running fine and I can watch tv using the client on the server computer; but none of my remote clients (computers on the same network) are able to watch a channel - getting "unable to play: stream8". In the remote client 'MediaPortal Configuration' under "TV/Radio" I have the IP address and the Test Connection is successful. Firewall is completely disabled on the server and the clients. I am using MP 1.24; and using a HDHomeRun Prime box with 3 tuners. I cleared the log files and then had one of the clients attempt to watch a channel (see attached logs). I have been messing with this for 2 weeks so any help would be much appreciated!

    No, I tried again to get it working after doing a reinstall of MP 1.25 pre and it still doesn't work with RTSP, but the UNC method works fine for me.
     

    Users who are viewing this thread

    Top Bottom