Some technical insight on TVserver engine anyone? (1 Viewer)

[da-anda]

Hi there,

I'm interested in some technical insight of TVserver. I'm no coder, but I'd like to know how stuff is handled in the background to better understand why things are as they are, and to give qualified feedback and improvement suggestions.

On reason why I'm asking is, that I'm interested in disabling default timeshift for TV-server. I know (read several times) that it's not possible in TV-server "due to it's architecture", but why in detail, what part of the architecture? I can't imagine that it's due to multicast, because you can also provide a multicast stream over the network without timeshift buffer, can't you? Is it for multiple TV-card support to easier keep track of the different streams?

The reason why I'd like to disable it is to get a far better zapping experience without using RAM-discs that slow down hibernation etc..

I'd also like to know how the zapping process itself is working - is the current stream killed and MP connects to a new stream, or is it one continuous stream only switching the data source on TV-servers side?

How are multicasts handled? Is every client getting it's own version of the stream (as I read that reconnecting to a RTSP-stream will show the stream right from the beginning of timeshift and not from current live state)? If so, what is the reason for that? Technical limitations or something?

Thanks.

 

[Mew]

Hi da-anda

I believe for live television the TV Service in TV Server works by using TsWriter to write the TV stream from the TV card to the timeshift buffer files.

The MediaPortal TV Plugin then uses TsReader to read the buffer file at any point behind the point it is currently being written. If you are watching "live" television then it is a fraction of a second after that part of the file that was just written. I think the WinTV software that comes with my Hauppauge PVR-150 does a similar thing so it can pause live TV.

If you disabled the timeshift and stopped TsWriter there would be nothing for TsReader to read so no TV to display. To change the way this works you would need a complete replacement for the TsWriter and TsReader system currently used.

This is my understanding at a very high level from reading the forums over the last couple of years. I am sure that someone will correct me of add more detail if I am wrong. I am not sure how the processes work in your other questions.

Mew

 

[da-anda]

Hi Mew,

thanks for the explanation, but I thought that MP is connecting to the TVserver over a RTSP-stream provided by TVserver - so no direct access to the timeshift buffers TS-file and no reason for the file itself either.
If a temporary file for liveTV would be needed due to the architecture (for what reason ever), my opinion would be to keep that buffer-file at about 100 MB (configurable) and keep it directly in RAM (RAM-drive or maybe permanently preallocated on a small CF-card). If a user is pressing the pause-button and is activating timeshift, this buffer would be written to HDD and expanded according to the settings in configuration - so timeshifthandling would be the same then. In this case, you would not need much RAM and still get a pretty fast zapping experience, no disturbing HDD noise and also save some power.

 

[tourettes]

thanks for the explanation, but I thought that MP is connecting to the TVserver over a RTSP-stream provided by TVserver - so no direct access to the timeshift buffers TS-file and no reason for the file itself either.

Live555 library that we use for RTSP is lighting fast (and using RTSP has few limitations...). From performance point of view it is slower than the local HD buffers.

If a temporary file for liveTV would be needed due to the architecture (for what reason ever), my opinion would be to keep that buffer-file at about 100 MB (configurable) and keep it directly in RAM (RAM-drive or maybe permanently preallocated on a small CF-card). If a user is pressing the pause-button and is activating timeshift, this buffer would be written to HDD and expanded according to the settings in configuration - so timeshifthandling would be the same then. In this case, you would not need much RAM and still get a pretty fast zapping experience, no disturbing HDD noise and also save some power.

This would make the code much more complicated without no actual benefit.

• HDs that are used in HTPC should be noiseless (Otherwise your hardware setup isn't a good one )
  
• HDs are most likely going to spin / run even if timeshifting is not placed on them as OS and MP itself are still requiring those (so no saved power here)
  
• Zapping speed won't get any benefit if the buffer is located in RAM. HD is not the bottleneck (not even if you have old hard disk)

 

[da-anda]

This would make the code much more complicated without no actual benefit.

• HDs that are used in HTPC should be noiseless (Otherwise your hardware setup isn't a good one )
  
• HDs are most likely going to spin / run even if timeshifting is not placed on them as OS and MP itself are still requiring those (so no saved power here)
  
• Zapping speed won't get any benefit if the buffer is located in RAM. HD is not the bottleneck (not even if you have old hard disk)

• HDs can be silent, but not noiseless
• if you're using something like EPU from ASUS or enhanced powersaving controls, HDs might be shut down if not used. If you're f.e. watching a blockbuster lasting 2.5 hours in liveTV, neither the OS (no interaction with the OS, so no read/write stuff to be done) nor MP or TVserver would need access to the HD.
• why are some users then reporting that the zapping speed has improved after using a ramdisk for timeshift? I haven't tested it myself, as I don't have enough RAM currently. So what's the bottleneck then? The RTSP stuff itself?

You seem to have quite some knowledge of TVserver - can you also answer my other questions? The one about how zapping is done (reconnecting to a new stream or not etc.). Thanks.

 

[slarve]

Why is zapping speed so slow on a HTPC (about 2-3 sek) when a Dreambox uses under 1 sek? The hardware is superior in my HTPC compared to a Dreambox... Is it microsoft and windows XP's fault?

 

[da-anda]

I think it's more the architecture of TVserver than the hardware. Some other TV software with simmilar functionality (multicasting, epg grabber, timeshift, recording scheduler, etc.) on Windows is quite faster than TVserver - so it's neither the hardware nor the OS. TVserver itself is slow in zapping.

 

[tourettes]

I think it's more the architecture of TVserver than the hardware. Some other TV software with simmilar functionality (multicasting, epg grabber, timeshift, recording scheduler, etc.) on Windows is quite faster than TVserver - so it's neither the hardware nor the OS. TVserver itself is slow in zapping.

Not quite true, for example 1.0 TVE3 version on my HTPC works pretty fast.

zapping inside a mux -> 0.5 seconds
zapping between different muxes -> approx 1 second

Zapping speed will be always a "compromise" between
- HW
- drivers
- software (this is something we can improve)
- broadcaster (how stream contains GOPs)

 

[da-anda]

Zapping speed will be always a "compromise" between
- HW
- drivers
- software (this is something we can improve)
- broadcaster (how stream contains GOPs)

yes, but other software is behaving faster with the same hardware, drivers, and streams - so it has to be a software issue, right? I don't want to blame TVserver or anything, but there is for sure other software around that's acting faster (DVB Dream or ProgDVB - a buddy of mine is using one of those as TVserver is to slow for him (2-4 sec)). I personally have stopped my HTPC project for now, due to lack of time, and use my good old pimped dbox2 again