[Help Us!] RTSP streaming library update (1 Viewer)

[Charlie TV]

Hi

I ran it and all has been well. Just now I got an error message about out of space when changing channel on the client. I waited and then tried again and it appeared to work. I grabbed logs as attached.

Cheers

 

[mm1352000]

You're right - no sign of errors there. Interestingly there are also no signs that the TsReader change is having any effect. I would have known by the presence of certain log entries... but those tell-tale entries are completely absent.

Previously I had thought that the duration of the streaming - which ties in with the too-complex-to-fully-explain "PCR roll-over" mentioned in my previous reply - was the sole determinant of what you were seeing. Comparing the duration of this test with the previous test, we have:
[2016-01-10 10:20:43,732] [Log ] [MPMain ] [INFO ] - TVHome.ViewChannelAndCheck(): View channel=BBC ONE HD
...
[2016-01-11 04:23:55,015] [Log ] [MPMain ] [DEBUG] - VMR9Helper: Playing -> Repainting, Frames 0

[2016-01-12 20:28:01,235] [Log ] [MPMain ] [INFO ] - TVHome.ViewChannelAndCheck(): View channel=BBC TWO HD
...
[2016-01-13 17:41:34,746] [Log ] [MPMain ] [INFO ] - TVHome.ViewChannelAndCheck(): View channel=BBC ONE HD

...so ~18 hours vs. ~21 hours. If my previous theory was correct then a longer test should have run into the same issue as the previous test and either passed (due to the TsReader change) or failed with the same symptoms... but to have no issues and no effect from my change makes no sense.


Considering the technicalities of PCR roll-overs...

A [hopefully!] simple way to understand what I'm talking about is to imagine that there are 2 timers associated with the stream. These timers are used as references for decoding and syncing the video, audio, subtitles etc. correctly. Each timer counts from 0 to ((2^33) - 1) [let's call it PCR-max for ease of explanation], and then rolls-over and starts at 0 again. Timer 1 is the broadcaster's timer. It could be anywhere between 0 and PCR-max when you start streaming. Timer 2 is TV Server's timer. It always starts at 0 when you start streaming. These timers [should!] count up at a consistent rate, such that it takes approximately 26.5 hours to get back to where they started from (ie. if a timer starts at 0, it will take 26.5 hours before it gets back to 0).

In the previous log files the issue seemed to start when the broadcaster's clock rolled over... though I was unable to be certain of that due to the limited history in the TsWriter log.

In these log files I can confirm that the broadcaster clock rolled over:
[2016-01-12 20:28:31,592] [743d818] [157c] - Recorder: TIMESHIFT Info : Next broadcaster program clock reference rollover : 0 days 17:00:00 0

...and like clockwork, 17 hours later:
[2016-01-13 13:28:33,074] [743d818] [157c] - Recorder: TIMESHIFT Info : Normal broadcaster program clock reference rollover passed !
[2016-01-13 13:28:33,074] [743d818] [157c] - Recorder: TIMESHIFT Info : Normal broadcaster program clock reference rollover passed !

As you've said there were no apparent problems. This essentially destroys my previous theory.

It's unfortunate that the latest test didn't quite get to the 26.5 hour mark when the TV Server clock would have been expected to roll over. That would have been interesting to see/test. However, 21 hours with a broadcaster PCR roll-over should have been enough to trigger the problem.

 

[mm1352000]

Note to readers...
Some posts in thread were copied and/or moved to a new thread:
https://forum.team-mediaportal.com/...files-cause-failure-to-change-channel.133512/

 

[1gkar]

Just updated client system to W10 & installed latest version of MP (1.13).

Constant 'unable to stream' error boxes. Upon updating respective server/client files as described, the system works perfectly.

All functions of both LiveTV & recordedTV playback are as good as can be expected (1-3 sec). LiveTV takes about 5 seconds to load. Channel changes are very good (3 sec). FF &rew (both Live & recorded TV) are also good, with a minimal slowdown (1 sec), whilst audio syncs. Also, checked server recording TV: fine.

Don't know if this is relevant, but I use version 0.7.26.0 of mediaindo.dll as all later versions are too slow to load videos across my wireless (TP-Link Archer C5) network.

A big thanks to all who have participated in this update: I can lie back & watch from the comfort of my bed

 

[mm1352000]

Thanks for the feedback.
If you could, sometime this evening (or ASAP) could you please export your log files (Watchdog option 3). I'd just like to see if I can figure out what the cause of the "unable to stream" was. No problem if you can't. Just thought it might be interesting/useful...

 

[1gkar]

I had already compiled logs with both TSReader.ax usage. Just in case.

 

[mm1352000]

Thanks. Looks like it was some kind of server side error...

 

[1gkar]

Hope the logs can assist for future builds. You guys do so much for everyone in the Mediaportal community.

 

[Owlsroost]

I'm wondering whether it would be smarter/helpful/possible to port (or even share) code from TsReader. FileReader, MultiFileReader, TsDuration, TsFileSeek... those classes are common to both projects, and if I'm not wrong they're also the classes that are responsible for low-level buffer and PCR handling. Do you think that would be feasible and/or appropriate?

Yes, that would be a good place to start from. In fact the StreamingServer version that is in my merged experimental branch - https://github.com/MediaPortal/MediaPortal-1/tree/EXP-Upgrade_555_MM_Owlsroost - already has the MultiFileReader code from TsReader (the version in that branch) ported to it. I've not looked at it in detail, but I think the classes you mention were originally the same code - they have just diverged over the years - so porting across the TsReader version should be feasible/probably a good idea.

I'll put it on my list of 'things to look at'

I've now ported the duration measuring and file seeking code from TsReader into the StreamingServer code in this branch - https://github.com/MediaPortal/MediaPortal-1/tree/EXP-Upgrade_555_MM_Owlsroost (and modified the PCR processing code in 'TsMPEG2TransportStreamFramer.cpp' a little). See https://forum.team-mediaportal.com/...tv-playback-rate-matching-for-testing.130394/ for the latest test binaries.

 

[1gkar]

Just a quick note to inform the devs I have upgraded my main HTPC to W10 with none of the above issues. It appears to work out of the box.