[nickr]

So if you don't do timeshift or recording, why not just watch your tv without a computer?

[TugboatBill]

I do both - record and watch live tv. We watch the local news (OTA) every evening, When a commercial starts we switch over to another channel for a few minutes (typically to a prev chaannel). I've been a tivo user almost since they first came out.

Slow channel changes is the reason I haven't even tried PVR in XBMC.

[sub3]

I watch a mixture of live tv and recordings.

Personally I'd want XBMC to do a great job with scheduling and recordings, and watching live tv with quick channel change times (< 3 seconds), and always ready to pause/rewind live tv etc. They are certainly the goals of my NextPVR application, and I'd like to be able to get the same in XBMC.

Having been in the "PVR development game" for nearly 10 years, developimg GB-PVR before creating NextPVR a few years ago, I know from years of feedback from users that live tv and channel change times are important. Not everyone wants to just watch recordings. A lot of people like to just channel surf - often they don't even want to look at what's on in the TV Guide and they'd prefer to sit there pressing CH+/- for a bit of mindless channel surfing. In the early days, when I had crappy channel change times, I used to try to sell people on the idea that didn't need quick channel change times. In the end I gave up on that view, and put in the hard work to give them what they wanted.

[opdenkamp]

@negge: if channel switching doesn't work in gotham when you press a number (in full screen mode), then this is a bug. register it on trac please

@TugboatBill: slow chanel switching totally depends on the backend/add-on that you're using. tvheadend and vdr will switch very fast, typically ~1 second. and i believe that fernetmenta improved it for other backends too now for gotham, but i never tested that myself.

[giaur]

tvheadend and vdr will switch very fast, typically ~1 second

Not really. 5-6 seconds in my case, 1/10 times xbmc freezes during channel switching and I need to choose other channel. You are right if you are saying about xbmc 11. But starting from Frodo things are much more worse, at least in my case sorry.

Some times ago I even asked this on forum, but there was not really answered - maybe it's not common issue, I have no idea.

[negge]

@negge: if channel switching doesn't work in gotham when you press a number (in full screen mode), then this is a bug. register it on trac please

With tvheadend a switch takes about 4 seconds for me. It always displays a still frame before it starts playing so I guess the switching time could improve (VLC switches about twice as fast).

---

And yeah, I'll file a bug report, just have to test the lastest master build first to see if the issue has been fixed.

[giaur]

Indeed. This is what I'm talking about. XBMC 11 was 1-2 second but not anymore. And the same issue wiht still frame before starting playback. Xbmc 11 (unofficial pvr branch) didn't have this.

[TugboatBill]

I've read a bit and it seems that fast channel changes isn't happening in the current release, no matter what back end is being used. It sounds like it'll be improved in the next release (something about the needed changes require too many mods to be included in a interim release or ?).

2 seconds will probably pass the WAF,, but 4+ won't.

[giaur]

It sounds like it'll be improved in the next release

I hope so. But currently latest xbmc 13 still has this problem.

[nickr]

At least for mythtv the channel change will always take some time - read up on the mythtv mailing list archives. But basically:

1. Most tuner card drivers do have some delay compared to the specialised chips in set top boxes or TVs

2. The Live TV stream is being recorded all the time (so you can pause, rewind, fast forward etc) and then retrieved from the disk by the frontend process (be that mythfrontend or xbmc) and played back. If the playback is too close to the recording then you run into problems where the playback process is starved of data and you get stuttering. There is therefore inherently a delay between "live" and what you see on the screen.

3. When you change a channel the system needs to: get the tuner card to physically tune to the new channel, select the streams you want to see & hear, close the existing recording file, open a new recording file, buffer enough to get over potential stuttering and serve up the new stream to the frontend. It is not a s simple as in a STB/Tv where you aren't recording. Some delay is inevitable.

However my point in starting this thread is that (IMHO) if you were using a PVR in the way it is intended, you wouldn't be channel surfing or even watching much Live TV, so you wouldn't care about channel change time

[sub3]

At least for mythtv the channel change will always take some time - read up on the mythtv mailing list archives. But basically:

1. Most tuner card drivers do have some delay compared to the specialised chips in set top boxes or TVs

2. The Live TV stream is being recorded all the time (so you can pause, rewind, fast forward etc) and then retrieved from the disk by the frontend process (be that mythfrontend or xbmc) and played back. If the playback is too close to the recording then you run into problems where the playback process is starved of data and you get stuttering. There is therefore inherently a delay between "live" and what you see on the screen.

3. When you change a channel the system needs to: get the tuner card to physically tune to the new channel, select the streams you want to see & hear, close the existing recording file, open a new recording file, buffer enough to get over potential stuttering and serve up the new stream to the frontend. It is not a s simple as in a STB/Tv where you aren't recording. Some delay is inevitable.

These shouldn't mean too much to how long channel changing is taking though.

With my DVB-S tuner, NextPVR is doing these same things (including always recording to disk, switching files, buffering etc), and it is delivering data to XBMC about a second after user tries to change channels. With Frodo it was then taking XBMC another 6-7 seconds or show video, most of which was ffmpeg sampling the stream looking for the audio/video streams, giving you a channel change time of about 7-8 seconds. We know this can definitely be improved upon because the custom build margro posted got my channel changes down to a total of about 1.5-2.0 seconds (ie, no changes to NextPVR or addon, just XBMC changes). I'm sure MythTV users will also benefit from these changes once they make it into the main stream builds.

Sure, the times will vary a bit depending on tuner and source stream, but there is no reason you shouldn't expect channel change times less than 4 seconds.

[giaur]

But older xbmc was able to switch channels much more faster (in my case). So?

[negge]

Just tested with a timer last night, for me it takes 2,5 seconds to see the first frame, then another 0,7 seconds for video starts playing. On unencrypted channels it's about one second less, so I can't really complain here. There's no practical difference between SD and HD for me. I'd much rather see developer time spent on fixing the remaining bugs with the PVR functionality instead of trying too hard to chase down channel switching times, especially since it's highly backend-specific (as are certain other bugs of course).

[sub3]

Just tested with a timer last night, for me it takes 2,5 seconds to see the first frame, then another 0,7 seconds for video starts playing. On unencrypted channels it's about one second less, so I can't really complain here. There's no practical difference between SD and HD for me. I'd much rather see developer time spent on fixing the remaining bugs with the PVR functionality instead of trying too hard to chase down channel switching times, especially since it's highly backend-specific (as are certain other bugs of course).

You're using tvheadend though, so won't see the problem. tvheadend and vdr work differently from the other pvr addons (by delivering pre-demuxed streams) so don't have the issue with slow channel change times. I'm pretty sure you'll find the users of every other pvr addon do think it's worth while that more effort is spent improving the channel change time - ideally along the lines of margro's change.

[negge]

Just tested with a timer last night, for me it takes 2,5 seconds to see the first frame, then another 0,7 seconds for video starts playing. On unencrypted channels it's about one second less, so I can't really complain here. There's no practical difference between SD and HD for me. I'd much rather see developer time spent on fixing the remaining bugs with the PVR functionality instead of trying too hard to chase down channel switching times, especially since it's highly backend-specific (as are certain other bugs of course).

You're using tvheadend though, so won't see the problem. tvheadend and vdr work differently from the other pvr addons (by delivering pre-demuxed streams) so don't have the issue with slow channel change times. I'm pretty sure you'll find the users of every other pvr addon do think it's worth while that more effort is spent improving the channel change time - ideally along the lines of margro's change.

After trying to set up NextPVR on a friends computer and ultimately having to give up, I'd say those who insist on getting PVR stuff to work on Windows will have to deal with the consequences. From what I've read, VDR is very good though I still recommend tvheadend to anyone who asks.