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).I'd be fascinated to understand more!
Current Single Seat
server: tuner -> TsWriter (remuxer) -> time-shift files
client: time-shift files -> TsReader (splitter/demuxer) -> decoders (codecs) -> outputs/renderers
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:
- For single seat, introduce some other mechanism/interface for transferring the "stream" from the server to the client.
- For multi-seat, in some way combine or co-ordinate TsWriter's remuxing functionality with streaming server's streaming functionality.
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.