MediaPortal over WAN..."Could not play: Stream4.0" (1 Viewer)

[JET]

Hi there
I got MediaPortal 1.12 up and running flawlessly on my LAN with several PC's.
Using 2 Terrestrial T free to air receivers and 1 T2 with CAM for coded channels.
Using MySQL as it came with the installationpack.
My OS is now Windows 10 and everything works perfect.
15Mb/s up and down speed both at summerhouse and at home.
Now I want to use the functionality of my home TV-Server in my summerhouse over the WAN, so I dont have to put up antennas ect. at my summerhouse.
Summerhouse-PC has MediaPortal 1.11 as singleseat installation, but pointed to the home-PC's TVServer
So I got TeamViewer VPN running between summerhouse and home. I can ping my home router and share files on the home-PC that is running TVServer.
Windows firewall is set up to allow MediaPortal, TVServer and MySQL at both ends for WAN and for LAN.
Testing connection in Mediaportal Configuration on summerhouse-PC to home TVServer is successful so everything seems fine.
The directory on the home PC that the home-TVServer uses for recordings is, on summerhouse-PC, in MediaPortal Configuration added as "Video-folder" so it pops up when choosing "Video" in MediaPortal on summerhouse-PC.
And any recording-file (.ts) in this folder is played fine on summerhouse-PC.

The problem is when doing this on summerhouse-PC over WAN connected to home-PC TVServer:
1) when I try to watch "Live TV". Then I get the message: "Could not play: stream 4.0"
(This message I have translated from danish. I dont know the exact words of the english errormessage)
and
2) when I try to play a file listed in "Recorded TV" from the menu inside Mediaportal TV, I get an errormessage saying ie:
"Could not play: 570405F2" (trying to play the exact same file that played well when accessed and chosen under the "Video" menu.)
The numbers in the errormessage is not the same every time I try. They vary and may be some HEX code.
LAV filters are used playing Video-files(.ts) and TV-files (.ts) Meaning it is LAV filters that are chosen in MediaPortal Setup for Codecs.
When the summerhouse-PC is brought home and connected to the home-PC TVServer over LAN there is NO issue.
So I guess its a "WAN-thing".
Any ideas for a solution to a problem that to me does not seem logical.??
Uploaded is the WatchDog file made just now trying out the 2 above mentioned situations.

 

[mm1352000]

Hello JET

So I guess its a "WAN-thing".

You are right.

This message in the TsReader log:
[2015-11-29 17:01:46,073] [ f100048] [ efc] - Failed to get a SDP description from URL rtsp://JET-Corei5:554/7E870C82 connect() failed: Unknown error

...is telling me that you have a problem with the RTSP connection (which is the video/audio connection for viewing live TV and recordings). I can only guess that the problem is either:

1. "JET-Corei5" cannot be resolved to a network (IP) address, OR...
2. Your firewall configuration is insufficient to enable the RTSP connection to be established.

For the first point: can you ping JET-Corei5 from the summer-house PC (JT-I5-4690K)?

For the second point: have you configured the firewall to allow port 554 is open/usable between the 2 machines?

In general you may find it easier to use UNC paths (SMB share) for the TV connection:
http://wiki.team-mediaportal.com/1_...iaPortal_Configuration/22_TV/Advanced_Options

Regards,
mm

 

[JET]

Hello mm
Thank You for Your input.
Yes I can ping JET-Corei5 --in Teamviewer vpn connection-window-- but also with command "ping" in windows cmd.
I have now, in my routers at each end, that is my home-router and my summerhouse-router, pointed port 554 at the respective PC's.
That did not change the situation.

BUT Your suggestion to use UNC paths in "Advanced Options" TV/Radio settings in MediaPortal Setup made things --almost-- work
Then I can play "Live TV" and play "Recorded TV"
Only thing is that after maybe 5 minutes or so, small "fall-outs" of sound and slight studdering of the pictures start to build up. Not much, but enough to make it an "unpleasant replay" of the recording.
The studdering seems to increase a bit after a while so it gets annoying at some point.
This is not the case when I choose the --same-- file to be played under menu "Video". No studdering there.
Any idea as to what might cause this?

Kind regards
JET

 

[mm1352000]

I have now, in my routers at each end, that is my home-router and my summerhouse-router, pointed port 554 at the respective PC's.
That did not change the situation.

It may not have changed the overall result, but I expect that opening the port will have allowed TsReader to receive the video/audio/subtitles stream information (PMT). Next step would be (or would have been) to open UDP ports for the actual video/audio/subtitles content. Those are chosen randomly which makes it harder to configure firewalls and routers appropriately, and that's why I suggested that maybe UNC paths would be easier.

Only thing is that after maybe 5 minutes or so, small "fall-outs" of sound and slight studdering of the pictures start to build up. Not much, but enough to make it an "unpleasant replay" of the recording.
The studdering seems to increase a bit after a while so it gets annoying at some point.
This is not the case when I choose the --same-- file to be played under menu "Video". No studdering there.
Any idea as to what might cause this?

First I should say: in your case I would not expect any difference playing any recording from "videos" or "TV -> recordings" because you have not configured MP to "use video codecs when playing .ts files" (-->here<--). The only way that I could explain the stuttering is bad luck/timing with the network connection/bandwidth/latency.

You said that your connection is 15 Mbps up/down at each end. TV streams are usually between 1.5 - 20 Mbps (without even considering overhead for network transfer overheads). So, it may be the case that your connection is not good enough. You can test this by checking if SD streams work better than HD streams. If this is the problem, the only solution would be to pay for a faster/better connection.

Also, 15 Mbps bandwidth does not say anything about the latency. Variable connection latency can cause problems (eg. buffer underflow). The only suggestion I can offer for this possibility is to increase the TsReader "BufferingDelayInMilliSeconds" registry setting (under HKEY_CURRENT_USER\Software\Team MediaPortal\TsReader).

In short: I'm saying that the problem seems almost certainly to be your network connection.

Regards,
mm

 

[JET]

Hello mm
I have tried to increase "BufferingDelayInMilliSeconds" from 0 to 100 (Decimal value) and have been testing replaying the same 14-20 minutes sequense of a recorded .ts film.
The result is that the studdering seems to have improved a little, but there is still some and it still seems to be building up, meaning it gets worse as time passes. (Yes, I did restart the PC after adjustments in RegDB)
I have increased to 500 millisec's too, but I have to test with the film copied to the HD on local summerhouse-PC too because there are some fall-outs at exact same points in film at each test, so it may be a fault in the recording. I have to rule that out. This takes some time since I have to wait minimum 5 minutes each time.
I will be back with my results.

Kind regards
JET

 

[mm1352000]

100 is quite a small value; even 500 is not particularly large. You may find that you have to increase the value quite significantly (eg. 5000).

Good luck!

 

[HTPCSourcer]

so it may be a fault in the recording. I have to rule that out. This takes some time since I have to wait minimum 5 minutes each time.

You can jump a little bit back in your recording by using the left arrow on your remote or keyboard whenvever you encounter a stutter or artifact to replay the last 15 or 30 seconds. If the stutter then occurs at exactly the same moment, it is part of the recording and not subject to connection issues.