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.
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.I sent you a PM.
As I've previously said, I don't read too much into this.1. It's not the stream box that's the issue, we used VLC to play the video stream, and it's smooth.
This is partially right and partially wrong.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 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.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
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.4. When I use VLC to play the MediaPortal service stream: rtsp://192.168.2.123/stream2.0, it can totally work. (22.214.171.124 is my PC IP)
Doubt it. You're welcome to try it though.I'm noticing an option in the Client config: TsReader Options 'Don't drop discontinued packets...'
Could that change anything?
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.What about the advanced option "force RTSP usage"?