RTP Stream Freezes After a Few Minutes (2 Viewers)

[Alex@Avenview]

I'm noticing an option in the Client config: TsReader Options 'Don't drop discontinued packets...'

Could that change anything?

What about the advanced option "force RTSP usage"? The streaming appliance also supports RTSP.

 

[Alex@Avenview]

So, I've heard back from our software engineers and they think that MediaPortal is the problem. This is what they sent me:
------------------------------------------------------------------------------------------------------------
Hi, Alex
We recreated the issue on our end and the conclusion is that:
1. It's not the stream box that's the issue, we used VLC to play the video stream, and it's smooth.
2. After deeper research to the MediaPortal software, we found it has a service and client. The service get the stream from outside via RTP protocol (stream box), and turn it to RTSP stream to it client.
3. The issue happen on the client. While the client got some error packets, it couldn't handle it. The fault-tolerant machanism in it is not so perfect. As I do the experiment, you can find the log in path: C:\ProgramData\Team MediaPortal\MediaPortal TV Server\tvserver_streamingserver.log
4. When I use VLC to play the MediaPortal service stream: rtsp://192.168.2.123/stream2.0, it can totally work. (192.163.2.123 is my PC IP)
So please contact the developer of this software, and consult what they can do .
------------------------------------------------------------------------------------------------------------
Reupload of my logs: Wikisend: free file sharing service

So my software team is convinced that MP is the issue. Any thoughts or comments I can fire back at them is appreciated because frankly, I don't think the stream box isn't the issue. If you watch the stream in VLC, it's very choppy with many artifacts so it's possible that the error handling in MP can't handle the choppiness of the stream.

 

[VoB]

TV Server's standard IPTV filter doesn't send keep-alive messages [because they're not standard for RTSP]. I may be able to dig up a version that does.

Hi mm1352000,

it would be very nice to have "still alive messages" on the servers IPTV-filter.

I'm currently trying to use the xoro SAT>IP Server 8100 (almost the same as the megasat). The problem is that the xoro-firmware has an option called "SAT> IP-Session-Timeout-Periode" which cannot be deactivated. Only the time can be switched between 30s and 3600s.


UPDATE: I'm currently testing a workaround: on the xoro I've exported the server-settings, edited the Timeout to 32000 seconds (=almost 9 hours) and imported the manipulated file into the xoro. --> the new value is correctly displayed. Now I have to test, if it works with the new value ...

 

[mm1352000]

SAT>IP-Server Triax in MPO einbinden

 

[VoB]

Thanks! I will test it next weekend.

 

[Alex@Avenview]

SAT>IP-Server Triax in MPO einbinden

Is there any chance the development team could take a look at my issue? I sent you a PM. Thanks.

 

[mm1352000]

I sent you a PM.

I personally haven't received any PM, but either way, I don't think there's much more that I can offer you. Owlsroost is the expert when it comes to problems with client-side playback.

1. It's not the stream box that's the issue, we used VLC to play the video stream, and it's smooth.

As I've previously said, I don't read too much into this.

2. After deeper research to the MediaPortal software, we found it has a service and client. The service get the stream from outside via RTP protocol (stream box), and turn it to RTSP stream to it client.

This is partially right and partially wrong.

Yes, MediaPortal has a service ("TV Server" / "TVService") and a client ("MediaPortal").
Yes, the service is capable of receiving RTSP, RTP, HTTP and UDP streams.

No, the service does not normally use RTSP between client and server unless the client and server are on different machines (ie. what we call a multi-seat installation). Normally when the client and server are installed on the same machine the server writes the stream to files on disk (timeshift files / buffer), the client reads those files, and RTSP is not involved.

3. The issue happen on the client. While the client got some error packets, it couldn't handle it. The fault-tolerant machanism in it is not so perfect. As I do the experiment, you can find the log in path: C:\ProgramData\Team MediaPortal\MediaPortal TV Server\tvserver_streamingserver.log

This makes zero sense. Streaming server is a server component, not a client component. Furthermore, if the appliance were producing a good stream, the "fault-tolerant machanism" would be irrelevant.

4. When I use VLC to play the MediaPortal service stream: rtsp://192.168.2.123/stream2.0, it can totally work. (192.163.2.123 is my PC IP)

Again, I don't read much into this. The stream from TV Server is almost a simple proxy of the stream from your appliance. If VLC can play the stream directly from the appliance then it's no surprise that it can also play TV Server's stream.


In my opinion the focus should be squarely on the ability of MediaPortal [client] to play the stream. Only the client has to demux and decode the video and audio content, so only the client will be able to determine whether the appliance is producing a reasonable stream.

I'm noticing an option in the Client config: TsReader Options 'Don't drop discontinued packets...'

Could that change anything?

Doubt it. You're welcome to try it though.

What about the advanced option "force RTSP usage"?

This forces MP client to use the server's RTSP stream rather than reading directly from the time-shift files. It's more error prone and therefore I do not recommend it.