Is it Possible to Pause the Graph?

[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.

Edit: I also agree about the HDPVR being a recording device, but unfortunately it's the only way in the US to get all of our HD channels into a media center.

[mvallevand]

I also have fixed output at 720p. Will a fixed graph be an issue for me with a combination of 5:1 and 2:0 AC3? I'd actually prefer a longer start up if sub tuned the graph twice, so I don't see the channel change getting captured, those few seconds make for a video that isn't playable on a lot of boxes, so I end up having to cut the file. It's not really the correct channel anyway.

On my Pivos XS running XBMC the HDPVR startup time is actually a little faster. Part of the time might be in XBMC, davilla passes this to the h/w decoder.

00:01:41 T:1229513824 DEBUG: CAMLPlayer:rocess: URL=xb-http://172.16.3.2:8866/live?channel=961
00:01:45 T:1229513824 DEBUG: CAMLPlayer::GetActualFPS:m_video_fps(29.970030)
00:01:45 T:1229513824 DEBUG: Process - change configuration. 1920x1080. framerate: 29.97. format: BYPASS
00:01:45 T:1229513824 NOTICE: Display resolution DESKTOP : 1280x720 @ 60.00 - Full Screen (12)

Martin

[wileecoyote]

I also have fixed output at 720p. Will a fixed graph be an issue for me with a combination of 5:1 and 2:0 AC3?

On my Pivos XS running XBMC the HDPVR startup time is actually a little faster. Part of the time might be in XBMC, davilla passes this to the h/w decoder.

00:01:41 T:1229513824 DEBUG: CAMLPlayer:rocess: URL=xb-http://172.16.3.2:8866/live?channel=961
00:01:45 T:1229513824 DEBUG: CAMLPlayer::GetActualFPS:m_video_fps(29.970030)
00:01:45 T:1229513824 DEBUG: Process - change configuration. 1920x1080. framerate: 29.97. format: BYPASS
00:01:45 T:1229513824 NOTICE: Display resolution DESKTOP : 1280x720 @ 60.00 - Full Screen (12)

Martin

The question is how does NPVR handle in session audio changes? For instance, while watching a channel with DD and a commercial come on with 2.0 audio, does it work okay? It should be the same or very similar.

[sub]

Try installing the attached patch.

You'll also need to add the following two lines in the config.xml's <HDPVR> section:

<StopOnChannelChange>false</StopOnChannelChange>
<WaitLongerBeforeRecordingCapture>false</WaitLongerBeforeRecordingCapture>

After this you'll have two checkboxes available in the HDPVR device settings.

You can choose to not restart the graph on channel change, which will give a quicker channel change. I'd only suggest using this if you have your STB set to output a fixed resolution. Because STB channel changes happen asynchronouse you'll still see your STB changing channels sometime soon after NextPVR internally changes channels. It should dynamically cope with changes of audio format.

The other setting allows you to delay the start of recording capture, for those that want to try avoiding seeing the few seconds of the STB changing channels. This setting only applies to recordings, not live tv.

[sub]

The question is how does NPVR handle in session audio changes? For instance, while watching a channel with DD and a commercial come on with 2.0 audio, does it work okay? It should be the same or very similar.

NextPVR should cope with it. Not sure what XBMC's built in player will do though.

[sub]

I also have fixed output at 720p. Will a fixed graph be an issue for me with a combination of 5:1 and 2:0 AC3?

That should be ok.

I'd actually prefer a longer start up if sub tuned the graph twice, so I don't see the channel change getting captured, those few seconds make for a video that isn't playable on a lot of boxes, so I end up having to cut the file. It's not really the correct channel anyway.

The patch above will sort of help this problem for recordings. I'll try to add something like this for live tv, but you'll be getting a horrendously slow channel change time.

BTW, if you think channel changes are slow with the HDPVR, wait until you see the HDPVR2. Great encoder, but video takes a lot longer to make it through the device than it does with the HDPVR.

[mvallevand]

The patch above will sort of help this problem for recordings. I'll try to add something like this for live tv, but you'll be getting a horrendously slow channel change time.

Great thanks, I'll give it a try tonight. I hope it does more than a delay in recording, I tried that with by having my tuning program change and delay. but that only fixes the issue of capturing some of the earlier channel it doesn't address the fact that the graph always starts with the characteristics of the previous capture and then it syncs to the new source. It is readily apparent in TME That is why I thought the number of audio channel was an issue even with fixed 720p

BTW, if you think channel changes are slow with the HDPVR, wait until you see the HDPVR2. Great encoder, but video takes a lot longer to make it through the device than it does with the HDPVR.

I tried my first capture in C4Me yesterday and I agree about the quality and wondered why there was so much black space at the start of the recording. I have other c4me issues too, there is no audio in the recordings and the aspect ratio is wrong but that's another thread.

Martin

[wileecoyote]

Try installing the attached patch.

You'll also need to add the following two lines in the config.xml's <HDPVR> section:

<StopOnChannelChange>false</StopOnChannelChange>
<WaitLongerBeforeRecordingCapture>false</WaitLongerBeforeRecordingCapture>

After this you'll have two checkboxes available in the HDPVR device settings.

You can choose to not restart the graph on channel change, which will give a quicker channel change. I'd only suggest using this if you have your STB set to output a fixed resolution. Because STB channel changes happen asynchronouse you'll still see your STB changing channels sometime soon after NextPVR internally changes channels. It should dynamically cope with changes of audio format.

The other setting allows you to delay the start of recording capture, for those that want to try avoiding seeing the few seconds of the STB changing channels. This setting only applies to recordings, not live tv.

MUCH better, thanks Sub!!!

My channel change times are around 2-3 seconds now. Very acceptable in my opinion.

In looking at my logs though, I still notice a lot of winsock errors (Let me know if that should be a seperate thread.)

08:29:26 T:6100 DEBUG: AddOnLog: NextPVR PVR Client: ReadLiveStream
08:29:26 T:6100 ERROR: AddOnLog: NextPVR PVR Client: Socket::receive: (Winsock error=10035) WSA Error
08:29:27 T:6100 ERROR: Previous line repeats 887 times.
08:29:27 T:6100 DEBUG: ffmpeg[17D4]: [NULL] Current profile doesn't provide more RBSP data in PPS, skipping
08:29:27 T:6100 DEBUG: Previous line repeats 7 times.
08:29:27 T:6100 DEBUG: AddOnLog: NextPVR PVR Client: ReadLiveStream
08:29:27 T:6100 ERROR: AddOnLog: NextPVR PVR Client: Socket::receive: (Winsock error=10035) WSA Error
08:29:27 T:6100 ERROR: Previous line repeats 16 times.
08:29:27 T:6100 DEBUG: ffmpeg[17D4]: [NULL] Current profile doesn't provide more RBSP data in PPS, skipping
08:29:27 T:6100 DEBUG: Previous line repeats 6 times.

[mvallevand]

I couldn't wait to try so on my lunch break I installed it. Now XBMC is hanging for me (using my plugin on channel change) everytime at the channel change.

Martin

[mvallevand]

It is immediately going to the demux though so data is streaming very fast.

12:32:44 T:5736 NOTICE: Creating InputStream
12:32:45 T:5736 NOTICE: Creating Demuxer

Martin