Reply to thread

Message: <blockquote data-quote="mm1352000" data-source="post: 1157225" data-attributes="member: 82144">Hello and welcome mitchellmedia <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" />I must say: to have read all 112 pages shows extreme dedication! <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" />Your summary of the situation generally matches my memory pretty well. However there are a few key pieces of information which I'm not sure if you have understood correctly. I'm going to try to explain them below. It's been a very long time since this problem has been mentioned, so please forgive and correct me if I don't get the details 100% right.First, the files/streams that the Colossus and TV Server are producing are 100% compliant with the relevant technical standards. I'm very confident there's nothing "hostile" or dodgy about them. I'd expect any reasonable hardware or software to be able to play them.Second, my recollection is that MediaPortal was only having trouble with live streams, and that the problem was caused by the STB's channel change delay. For a certain period of time the STB and/or Colossus was not producing any output. This was causing MediaPortal's TsReader (and/or TV Server's streaming server) to give up on playing/delivering the stream. That STB channel change delay doesn't apply when playing recordings, so I wouldn't expect problems playing recordings.With regard to mitigating or eliminating the problem...1. My recollection is that there was only trouble with client-only installations. If MediaPortal and TV Server were installed on the same PC then there was no problem.2. I further recall that using UNC paths instead of the default RTSP streaming (previously a "debug" setting, now an <a href="http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/141_Configuration/MediaPortal_Configuration/22_TV/Advanced_Options" target="_blank">advanced setting</a>) as the "time-shifting protocol" eliminated the problem for at least some people. At the time using UNC paths introduced another problem (something related to the caching behaviour of the Windows implementation of the SMB file sharing protocol). However, my understanding is that the UNC paths problem has subsequently been eliminated, making it a viable solution.3. As indicated in previous discussions about this problem, I'm very reluctant to introduce a delay in the TV Server tuning process for various reasons. A fixed delay is an effective solution, but rather crude. A variable delay is more desirable, but very complex (if not impossible) to implement within the current code framework.4. A month or two ago I updated the library that MediaPortal and TV Server use for RTSP streaming. This is the first update of that particular component in more than 5 years. The update hasn't yet been integrated into a release, but I am able to provide patches.Until today I had assumed the problem had been resolved. After all, I haven't seen any reports or references for years. Of course problems don't just solve themselves. My standing assumption would be that the problem was eliminated by the steady stream of TsReader improvements that have come in since the posts you referred to.That brings me to another point: I had always thought that this problem was a MediaPortal (TsReader) problem rather than a TV Server problem. I couldn't and still can't prove that; it's just an informed opinion. However, your successful test with VLC seems to support that opinion. I mean: if the problem was with TV Server or the files/streams it produces, surely VLC wouldn't work.As a logical consequence of the above opinions, I'm inclined to think that the problem you're experiencing is due to limitations or issues in OpenELEC rather than an issue in TV Server. Again, I have no way to prove that except the circumstantial evidence which is outlined above.What can I do to help?Unfortunately I have zero experience with OpenELEC. That means I'm unable to help debug the problem properly.The only thing I feel able to do for you that might help is point you to the streaming server patch that I mentioned in (4) above. It's here:<a href="https://forum.team-mediaportal.com/threads/no-connection-could-be-made-because-the-target-machine-actively-refused-it.129178/page-10#post-1148645" target="_blank">https://forum.team-mediaportal.com/threads/no-connection-could-be-made-because-the-target-machine-actively-refused-it.129178/page-10#post-1148645</a>To install it, stop the TV Server, download and extract the replacement DLL into your TV Server install directory (don't forget to take a backup first!) then start the TV Server again. I have no idea if it will help or not.You mentioned that you think the solution would be to add a delay in the TV Server tuning process. Considering that TV Server currently doesn't appear to be at fault, I'm currently not willing to do that. Sorry. It isn't my intention to frustrate. Note that if you're really desperate, you may be able to hack the code for yourself. I already provided directions here:<a href="https://forum.team-mediaportal.com/threads/hauppauge-hd-pvr-colossus-support.94850/page-30#post-747830" target="_blank">https://forum.team-mediaportal.com/threads/hauppauge-hd-pvr-colossus-support.94850/page-30#post-747830</a>The relevant code is here:<a href="https://github.com/MediaPortal/MediaPortal-1/blob/master/TvEngine3/TVLibrary/TVLibrary/Implementations/Analog/Graphs/HDPVR/HDPVRChannel.cs#L149" target="_blank">https://github.com/MediaPortal/MediaPortal-1/blob/master/TvEngine3/TVLibrary/TVLibrary/Implementations/Analog/Graphs/HDPVR/HDPVRChannel.cs#L149</a>Regards,mm</blockquote>

Verification