[KoMiKo]

Hi guis,

there are many threads about problems with slow channel change when using PVR in XBMC in Windows. I did try some test:
My setup: ASUS E45M1-M PRO, 8 GB RAM, SSD disk. TBS6981 DVB-S2 Dual Tuner PCIe Card. Windows 7 (tested also with W8, but zapping was slightly slower).

Tested on SD channels on the same satellite, results are average of more tests

Results:

1/ DVBviewer 5.0
- free channels: 1,1 sec
- scrambled channels: 1,43 sec

2/ DVBViewer Recording Service 1.23.1 as backend
a/ DVBviewer 5.0 as frontend
- free channels: 1,47 sec
- scrambled channels: 2,29 sec
b/ XBMC 12 as frontend
- free channels: 3,43 sec
- scrambled channels: 4,45 sec

3/ NextPVR 2.5.9 as backend
a/ NextPVR 2.5.9 as frontend
- free channels: 2,2 sec
- scrambled channels: not tested
b/ XBMC 12 as frontend
- free channels: 7,6 sec
- scrambled channels: not tested

Can you place here your results including your setup, as this can be good informations for other users.

If possible, focus on Windows applications, as there are more problems with long zapping time.

[Frank_aspen]

Setup:
Front End: QC AMD, 3GB, HD4200 HDMI, HDD -- XBMC Nightly
Back End:Virtual QC,4GB, NPVR
Tuner: Comcast -- HDHR -- Unencrypted QAM Only

Speed NPVR on VM --
3 Seconds Initial
1 to 2 seconds CC

Speed XBMC on Front End
1-8 Seconds initial --Seems to depend on which channel I choose, if tuner was previously on channel
3-8 Seconds CC -- Seems to vary by resolution of channel

[basco]

you should make a distinction between HD and SD channels.

[opdenkamp]

completely depends on the backend and add-on that you're using. typically a channel switch with tvheadend takes less than a second.

@KoMiKo: i've removed the lines about decryption from your post. please read the sticky topic about this

[KoMiKo]

completely depends on the backend and add-on that you're using. typically a channel switch with tvheadend takes less than a second

And this is why I posted this thread - let the others to send some info, what backend and add-on has short zapping time
Slow zapping is one of often discussing problem when using Windows, where TVHeadend cannot be used.

...@KoMiKo: i've removed the lines about decryption from your post. please read the sticky topic about this

OK, you are right. Just to defence myself: I'm using legal card and I pay subscription.

[opdenkamp]

sure, so do lots of people. but even though you may pay for your subscription, the software that you're using to do the decryption is not legal in lots of countries, so it's not allowed to discuss it here.

[Frank_aspen]

completely depends on the backend and add-on that you're using. typically a channel switch with tvheadend takes less than a second.

@KoMiKo: i've removed the lines about decryption from your post. please read the sticky topic about this

Thanks! I've been trying to avoid *nix but since my ultimate goal is to use rPI with a VM back end sounds like it's worth the time investment.

[fetzerch]

completely depends on the backend and add-on that you're using. typically a channel switch with tvheadend takes less than a second.

@KoMiKo: i've removed the lines about decryption from your post. please read the sticky topic about this

From my experience and from the info I collected in the forums, addons that handle demuxing themselves (tvheandend, vdr-vnsi)
are much faster in changing channels than addons that only pass mpeg-ts streams to xbmc.

I did some measurements for the MythTV addon and when changing the channel the code gets stuck in avformat_find_stream_info for about 5 seconds.
Other users reported this as well: http://forum.xbmc.org/showthread.php?tid...pid1188372

Imo it would be very nice if we could get this sorted out directly in xbmc, because it would speed up channel switching for many addons.
Is there a ffmpeg experienced team member that could help there? Or is the general suggestion to handle demuxing in the addons.
(which would probably lead to code duplication)

Thanks,
Christian

[FernetMenta]

I will continue work on this pr after we have updated ffmeg
https://github.com/xbmc/xbmc/pull/1757

Once we observe pmt changes on ts streams I think we can skip avformat_find_stream_info at least for live tv.

[fetzerch]

Thanks, that sounds good!

I don't know if it helps, but it might make sense to have a quick look into the mythtv sources at https://github.com/MythTV/mythtv/tree/ma...nal/FFmpeg
They are using ffmpeg and most likely have optimized it for live tv usage. Maybe there are some interesting patches.

[FernetMenta]

I already had a look there. Indeed, the myth guys patched ffmpeg in order to get pmt changes. We have discussed this method in the team but agreed on something better which is already accepted upstream:

https://github.com/FFmpeg/FFmpeg/commit/...73f7b49702

[sub3]

Great. I was thinking I'd need to move my NextPVR addon to demuxing the stream itself to improve the channel change times, but hopefully this change will save me from having to do that.

I think it's a good idea to solve this slow avformat_find_stream_info stage in XBMC, rather than complicate all the addons to try working around the issue.

[VTCop]

How could I take advantage of that FFMPEG commitment on my XBMC installation?

Must I install a XBMC nightly build? Is it included into XBMC internal FFMPEG or will I need to do some patch?

Thanks

My:
I want to improve my zapping speed.
I have two XBMC machines, one Ubuntu 12.10 and one W7, both with Frodo.

[h3llsp4wn]

I guess we will have to wait till the next major release?

By the way - I guess it´s one of the pain points atm. So if someone can prepare a compiled version for xbmc including this patch, that would be great.

Cheers,

h3ll

[FernetMenta]

The work on this is not completed yet. I need to finish some other tasks before I'll get back to this.