Is it Possible to Pause the Graph?

[wileecoyote]

I know with MediaPortal they have a setting in the TV Server setup to allow you to pause the graph instead of stopping. This makes for faster start/channel changing times.

Since channels start and change just fine it is just an enhancement, no rush on this one (I'm just sure people will talk about it though. Some reason people are very finicky about channel change times.)

[sub]

It wouldn't make any difference to channel change times, since NextPVR doesn't stop the graph when this happens. In theory it could make starting live tv slightly quicker first time around, but it would mean no other app could use the tuner inbetween NextPVR uses of it. I'm not sure it'd be worth doing.

[wileecoyote]

Oh, okay. I have tested the NPVR client a little this evening and noticed the HD-PVR times are about the same (6 seconds between changes.) The HDHomeRun is around 2-3 seconds. I wonder if the long change times on the HD-PVR is a setup issue on the server? Is this normal for the HD-PVR/Colossus? On the old setup MediaPortal/ForTheRecord change times are around 1-2 seconds.

[sub]

Ah, yeah - sorry, I haven't looked at the issue you mentioned the other day where the HDPVR was stopping and restarting the graph each channel change. It's not supposed to.

[wileecoyote]

No worries I know you are extremely busy. I just wanted to start a thread here to keep it on "focus" so to speak

[mvallevand]

Five seconds is normal for me on the hdpvr from channel to channel, but I can see 3 digits change on the stb so the tuning itself isn't fast. I've noticed that xbmc starting the file is slower than my NMT

It's not a valid test because this is wifi but the delay shows in xbmc.log between these lines

21:28:07 T:4236 NOTICE: Creating InputStream
...
21:28:13 T:4236 NOTICE: Creating Demuxer

Martin

[sub]

wilee, do you have your set top box set to output a fixed resolution?

I now remember that we stopped and started the HDPVR on channel change for a couple of reasons.
- in the early days the HDPVR drivers often used to lockup if it's ir blaster was used while it was capturing
- also there was a risk the resolution would change, which used to result in broken files coming from the HDPVR (where the first few seconds were one resolution, then the STB would eventually start delivering the new resolution, and you'd end up with streams with both).

I might be able to add an option to not stop HDPVR on channel change, and we'll see if it helps.

I've always seen the HDPVR style devices as a good device for recording, but pretty poor for live tv since you need to depend on slow ir blasters etc.

[mvallevand]

So my 5-6 seconds for the hdpvr is pretty consistent vs 1-2 seconds for 1080i ATSC

Code:

22:51:07 T:7012  NOTICE: Creating InputStream
22:51:13 T:7012  NOTICE: Creating Demuxer

22:51:24 T:2356  NOTICE: Creating InputStream
22:51:30 T:2356  NOTICE: Creating Demuxer

22:51:42 T:712  NOTICE: Creating InputStream
22:51:48 T:712  NOTICE: Creating Demuxer

22:53:51 T:6104  NOTICE: Creating InputStream
22:53:56 T:6104  NOTICE: Creating Demuxer

22:54:07 T:6232  NOTICE: Creating InputStream
22:54:13 T:6232  NOTICE: Creating Demuxer

22:55:51 T:6044  NOTICE: Creating InputStream
22:55:52 T:6044  NOTICE: Creating Demuxer

22:56:03 T:6476  NOTICE: Creating InputStream
22:56:04 T:6476  NOTICE: Creating Demuxer

22:56:10 T:3676  NOTICE: Creating InputStream
22:56:11 T:3676  NOTICE: Creating Demuxer

22:56:17 T:6780  NOTICE: Creating InputStream
22:56:19 T:6780  NOTICE: Creating Demuxer

Note this is from a wired XBMC client and HDPVR performance is still way better than for an NextPVR client

Code:

2012-09-25 23:04:16.621    [DEBUG][1]    OnKeyDown() called: Return
...
2012-09-25 23:04:27.722    [DEBUG][1]    RenderDemux()
...
2012-09-25 23:04:30.247    [DEBUG][1]    PLAYING_LIVETV
2012-09-25 23:04:30.247    [DEBUG][1]    StartLiveTV@done
2012-09-25 23:04:30.250    [DEBUG][1]    OnKeyDown() done. Took 13628.779296875 ms
2012-09-25 23:04:30.256    [DEBUG][1]    GetEventCode() returned: 0x000d

Martin

[mvallevand]

Here are the same tests on OpenElec on my Ion which were actually better than my i7 h4000 with a win7 64 client

Code:

18:15:24 T:140710121039616  NOTICE: Creating InputStream
18:15:30 T:140710121039616  NOTICE: Creating Demuxer

18:16:13 T:140710032434944  NOTICE: Creating InputStream
18:16:18 T:140710032434944  NOTICE: Creating Demuxer

23:18:16 T:140709274683136  NOTICE: Creating InputStream
23:18:21 T:140709274683136  NOTICE: Creating Demuxer

23:24:13 T:140709302630144  NOTICE: Creating InputStream
23:24:13 T:140709302630144  NOTICE: Creating Demuxer

23:24:20 T:140710032434944  NOTICE: Creating InputStream
23:24:20 T:140710032434944  NOTICE: Creating Demuxer

23:24:31 T:140709302630144  NOTICE: Creating InputStream
23:24:31 T:140709302630144  NOTICE: Creating Demuxer

Martin

[wileecoyote]

wilee, do you have your set top box set to output a fixed resolution?

I now remember that we stopped and started the HDPVR on channel change for a couple of reasons.
- in the early days the HDPVR drivers often used to lockup if it's ir blaster was used while it was capturing
- also there was a risk the resolution would change, which used to result in broken files coming from the HDPVR (where the first few seconds were one resolution, then the STB would eventually start delivering the new resolution, and you'd end up with streams with both).

I might be able to add an option to not stop HDPVR on channel change, and we'll see if it helps.

I've always seen the HDPVR style devices as a good device for recording, but pretty poor for live tv since you need to depend on slow ir blasters etc.

Yes, I have the STB set to a resolution of 1280x720 specifically because of the issue you mentioned.

We could try it and see if it works correctly, if not we can remove it.