Ability to watch the TV stream directly without the timeshift buffer delay? (2 Viewers)

[mm1352000]

I'd be fascinated to understand more!

The chains below are somewhat simplified and assume use of MediaPortal [client] rather than KODI. The KODI server chain is as per the multi-seat chain; the KODI client chain is unknown to me, but presumably it involves similar elements (splitter/demuxer, decoders, renderers).

Current Single Seat
server: tuner -> TsWriter (remuxer) -> time-shift files
client: time-shift files -> TsReader (splitter/demuxer) -> decoders (codecs) -> outputs/renderers

Current Multi-Seat
server: tuner -> TsWriter (remuxer) -> time-shift files -> streaming server -> RTSP network stream
client: RTSP network stream -> TsReader (splitter/demuxer) -> decoders (codecs) -> outputs/renderers

[edit: I should clarify that only TsWriter, streaming server and TsReader are MediaPortal elements. The rest are "third-party". Some are also configurable.]

If you remove the time-shift files, you have to:

1. For single seat, introduce some other mechanism/interface for transferring the "stream" from the server to the client.
2. For multi-seat, in some way combine or co-ordinate TsWriter's remuxing functionality with streaming server's streaming functionality.

One could imagine dealing with #1 by using RTSP network streams as the interface between client and server for both single seat and multi-seat. In fact it's possible to force that through settings in MP Configuration now... though annedotally my understanding is that it's slower and more error prone, particularly when seeking (skip, FF, RW). That would leave the [significant] challenge of #2.

These things aren't too difficult to explain conceptually... but, trust me, they're far from easy to implement in practice! Even more challenging (in my opinion) would be implementing the switch between "live" and time-shifting mode with zero content loss using the pause mechanism you suggested. That would require a level of synchronisation/coupling between client and server that simply doesn't even exist right now. For single seat the server currently has absolutely no knowledge of client "movement" (pause, play, skipping, FF, RW) within the time-shift buffer; client and server operate absolutely independently except for the start and stop commands.

 

[mm1352000]

Does that possibly suggest that the delay is not being caused by the timeshift buffer file after all, but is to do with other factors (the capture device itself, maybe?)

I did say:

1. That MediaPortal was only the last link in a chain of buffers, including the tuner.
2. That the most significant portion of the delay introduced by MediaPortal was likely to be the time-shift file link. That says nothing about the relative contribution of MediaPortal's contribution to the overall delay.

...so, that's a big Yes.


By way of a general comment...
In the first post you mentioned that you noticed the difference between the timing of your neighbour's fireworks and the countdown on your MediaPortal/KODI-fed TV. This is highly imprecise when you consider that you're attempting to quantify a time difference that's likely to be of the order of a few seconds. I mean, you seem to be making some fairly significant assumptions:

• that the timing of the TV countdown on the channel you're viewing is accurate (ie. zero/negligible transmission delay etc.)
  
• that your neighbours were timing their fireworks off the same TV countdown (ie. same channel or whatever) as you
• that your neighbours' lighting of their fireworks fuses was timed such that the fireworks would go off at exactly midnight, relative to the TV countdown

Given your admission that your previous "8 second" comment was an estimate, I think I now need to ask what your measurement methodology is. Don't get me wrong: your questions are very reasonable, and there will be a delay introduced by MediaPortal. I just think that if we're going to get into comparitive measurements, a consistent methodology is a necessity.

 

[CyberSimian]

The delay on my system is half a second.

Another datum: my Sony TV can do "picture in picture", so it is easy to display the output from the Sony's TV tuner with the picture from an HDMI input connected to my HTPC running MP1. Doing that for a UK DVB-T2 channel gives an MP delay of 2 seconds.

-- from CyberSimian in the UK

 

[mm1352000]

Thanks @CyberSimian
A lot of TVs suffer from "input lag" especially if post-processing is enabled. This adds to the difficulty in obtaining an accurate measurement of the lag introduced by MediaPortal.

 

[Chris Melville]

mm1352000 - thank you so much for taking the time to explain the chain of events. It's interesting to hear a developer's insight.

One could imagine dealing with #1 by using RTSP network streams as the interface between client and server for both single seat and multi-seat. In fact it's possible to force that through settings in MP Configuration now.

How would one do that?

Even more challenging (in my opinion) would be implementing the switch between "live" and time-shifting mode with zero content loss using the pause mechanism you suggested.

I acknowledged that it would involve content loss

In the first post you mentioned that you noticed the difference between the timing of your neighbour's fireworks and the countdown on your MediaPortal/KODI-fed TV.

That was only an illustration, for the purpose of painting a picture - not a serious exercise in timing. I have timed it by looking at my time-synched iPhone in comparison with the onscreen clock on BBC News. The only reason I described 8 seconds as an estimate was because last time I checked the timing, I didn't note down precisely how many seconds it was: only that it was perhaps just under 10 seconds.

Thanks @CyberSimian
A lot of TVs suffer from "input lag" especially if post-processing is enabled. This adds to the difficulty in obtaining an accurate measurement of the lag introduced by MediaPortal.

My most recent timing check (7 seconds) was on my desktop PC, using a monitor with a DisplayPort connection at 60fps. Not a TV with post-processing.

Anyway - given the discussions thus far, I am now starting to believe that the biggest culprits for the delays are probably my capture devices. On my desktop computer this is a USB tuner stick. On my downstairs, HTPC this is a PCI-E capture card. Both experience 7-8 second delays in live TV. Both are running as single-seat installations (even though I have a home network, I don't stream TV through it).

 

[Chris Melville]

The delay on my system is half a second.

Just out of interest, what's your setup? What capture/tuner device are you using?

 

[HTPCSourcer]

what's your setup?

Check out my System Specs. My timeshift files reside on a RAM disk.

The "half a second statement" stems from an experience before yesterday when I was watching the same show as my wife on a standard TV with integrated SAT tuner vs my wife in the living on a MP2 client (HTPC1 in the sys specs). I was hearing the echo from the living about half a second later...

I plan to quantify the delay by taking a look at the main news show at 8PM where they display a digital clock for a few seconds before 8:00:00. I'll compare this time display to the Windows digital clock that is based on internet time for a better assessment of time delay.

 

[HTPCSourcer]

I took another look into the subject by comparing a time display on Live TV to the internet time on my PC:

Live TV is lagging some 6 sec on my system, however, Live TV on a standard TV set with an in-built SAT receiver has a 5 sec lag. It appears that the 5 sec is a common value for SAT TV, subject to the broadcaster's signal processing.

 

[mm1352000]

by comparing a time display on Live TV to the internet time on my PC:

I don't think you can assume that these will match. AFAIK most broadcasters don't take transmission delay into account... and if they do, it has to be an estimate.

Transmission delay - the time it takes for the signal to get from the last studio output, through the transmitter encoding/processing, to the transmitter, over the physical medium (air, cable, whatever) and then finally to the receiver - varies from receiver to receiver because the physical distance from the transmitter to each receiver is slightly different. Difference in distance translates to difference in time. The broadcaster can make the time absolutely accurate (ie. clock displayed on TV matches time at receiver location) for one receiver... but because all other receivers that are a different distance from the transmitter will have some [slight] inaccuracy.

however, Live TV on a standard TV set with an in-built SAT receiver has a 5 sec lag.

Yes, all receivers have different internal processing lag. As previously indicated, I don't think MP's processing lag is unreasonable. Yes, maybe it could be less if the time-shift buffer files were taken out of the chain... but that's the design we chose, and designers for all devices make such choices.

 

[CyberSimian]

Yes, maybe it could be less if the time-shift buffer files were taken out of the chain... but that's the design we chose, and designers for all devices make such choices.

The reason that I like MP (and my Humax DVR) is precisely because they do write to the time shift buffer when watching live TV, thereby enabling the ability to pause and rewind live TV.

My Sony TV can also pause and rewind live TV, but it is necessary for the user to initiate writing to the timeshift buffer by pressing a button on the remote control. So it is completely useless for rewatching something unexpected that has just happened on live TV.

-- from CyberSimian in the UK