[Finished] Improvements to Live TV playback rate matching - for testing (1 Viewer)

[azzuro]

@Owlsroost
i can't build you last commit :
Error 222 error C2039: 'OnBitRateChanged' : is not a member of 'ITSReaderCallback' D:\svnroot\1.Mediaportal\MediaPortal-1\DirectShowFilters\TsReader\source\TsReader.cpp 776 1 TsReader

 

[azzuro]

//Make compatible with MP1.11 and later versions if defined
#define BITRATE_REPORT

on tsreader.h must be reverted.

 

[Owlsroost]

@Owlsroost
i can't build you last commit :
Error 222 error C2039: 'OnBitRateChanged' : is not a member of 'ITSReaderCallback' D:\svnroot\1.Mediaportal\MediaPortal-1\DirectShowFilters\TsReader\source\TsReader.cpp 776 1 TsReader

Oops - should be fixed now...

 

[HTPCSourcer]

Hi,

Switching from UNC to RTSP (and using your files from posting #1) has cured my issue of short pauses at Live TV under Windows 10 - at the price of annoyingly long channel switch times . Except for this I am very happy with Live TV experience, which is otherwise running absolutely stable.

Notwithstanding, a channel change time of 7-9 seconds, compared to some 3 seconds under UNC (when switching from encrypted channel A to encrypted channel B), is definitely a long time. Is there a chance to tune settings, e.g. reduce buffer times etc., to reduce the channel switching time?

 

[Owlsroost]

Is there a chance to tune settings, e.g. reduce buffer times etc., to reduce the channel switching time?

I'm working on it

 

[azzuro]

Great! I like that

 

[Owlsroost]

Is there a chance to tune settings, e.g. reduce buffer times etc., to reduce the channel switching time?

Please try the attached files (TsReader.ax for the clients, all the others for the server) - installation instructions in the first post in the thread.

You should get shorter channel change (zapping) times when using RTSP with these versions - please test and report back

If you have problems with them, I need both the client and server logs.

 

[HTPCSourcer]

This is definitely much better . I would say that it saves 2-3 seconds,

 

[HTPCSourcer]

Hi @Owlsroost ,

Does your build in posting #1 include the recent tsreader logging bug fix ([MP1-4788] - TsReader logging thread is not closed on filter destruction) ?

Regarding the zapping time, can you give some insight into what elements in RTSP use govern the channel switch time? Is there any furthr optimization potential or are we talking minor opportunities only?

What I found interesting is that sometimes the channel change time is really fast. I have not systematically analyzed the situation and it might simply be due to switching over from one channel to the another on the same transponder, i.e. without the need to load another card. Anybody else tested the latest versions?

 

[Owlsroost]

Does your build in posting #1 include the recent tsreader logging bug fix ([MP1-4788] - TsReader logging thread is not closed on filter destruction) ?

Yes, it does.

Regarding the zapping time, can you give some insight into what elements in RTSP use govern the channel switch time? Is there any furthr optimization potential or are we talking minor opportunities only?

Mostly it's mixture of less accurate 'seeking' in RTSP mode and TsReader having to wait for data from the new channel to arrive in real time (instead of being able to read through the timeshift buffer data faster than real time when it's searching for the new MPEG header information, as it does when directly reading the timeshift file).

Yes, I think there is potential for further optimization, but I don't think it's ever going to be as fast as with UNC paths.

What I found interesting is that sometimes the channel change time is really fast. I have not systematically analyzed the situation and it might simply be due to switching over from one channel to the another on the same transponder, i.e. without the need to load another card.

I'm interested in log files for the fast and slow changes (I need both the client and sever logs, so I can relate what's happening at both ends of the system).