[sizanx]

Hey,

Atm when you change channel, the connection stops, and then connects again with the new channel = takes a long time to change channel (I am using it over the internet, tv server is in another city, however i'ts a 100 mbit server and I have a 100 mbit connection).

So I was thinking wouldn't it be possible to keep the connection by changing the channel on the server rather than caching new video/audio on the client, using fx mediaportal's timeshift function?

The only problem I can think of is that if the server is connected by more than 1, the stream will be the same for everybody = guy1 changes to channel1, guy2 will also be watching channel1.
However if it's possible then maybe it can cut away some excess/irritating waiting. It could maybe be a seperate plugin/addon.

I hope I am not proposing a stupid suggestion

Btw I'm using Margro's XBMC Eden RC1.

[margro]

Your suggestion is certainly not stupid and it would indeed lower the channel switching time.
However it is a bit more complicated than just switching the channel at the backend side.
The complicated part is that the amount of streams (audio, video, teletext subs) and the type SD or HD could change.
This means that XBMC needs to tell ffmpeg to reopen the RTSP stream and redo the stream detection. Here lies exactly the problem with the channel switch time. Most of the time is spend by the ffmpeg library to detect the streams when the stream origin is RTSP. (and I don't know why).
When I just assume that the streams stay the same, it works sometimes, but most of the times XBMC just stops the playback (already tested).

With respect to your situation:
You could also use the TSreader plugin for RTSP playback. Just disable the options "Play recordings directly (no streaming)" and "Direct playback from Timeshift buffer (no rtsp)" and the addon should use the Live555 library for RTSP playback. This is still faster than the ffmpeg route.