Channel changing and all that

[Graham]

Could you try the attached binaries and let me know if it helps with the StopOnChannelChange problem.

Yubba Dubba Doo

Channel changes is consistent with <StopOnChannelChange> True. Works every time and each change takes about 5 seconds. Well done.

For completeness, I tried <StopOnChannelChange> False and that still hangs on a mux change which is what I think that we both expected.

Thank You

Graham

[bgowland]

Channel changes is consistent with <StopOnChannelChange> True. Works every time and each change takes about 5 seconds. Well done.

Excellent, thanks. I'm not sure what my thinking was but I'd badly broken things somewhere along the way. I may be able to reduce the time between changes but probably not by much. As long as it's acceptable and stable, that's the main thing.

For completeness, I tried <StopOnChannelChange> False and that still hangs on a mux change which is what I think that we both expected.

Yep - still not sure if this is a Nova-t USB2 thing, the driver version or just the fact that not all systems are equal. If you get a chance to take the USB2 out of the loop, let me know what happens with it set to 'false' with the Nova-t PCi cards.

Thank You

You're welcome - I like happy customers.

Cheers,
Brian

[Graham]

If you get a chance to take the USB2 out of the loop, let me know what happens with it set to 'false' with the Nova-t PCi cards.

This is with
<StopOnChannelChange>False</StopOnChannelChange>
on a PCI card.

R1 (Mux B) ok
R2 (Mux B) ok
Q (Mux D) hangs

and

R1 ok
R2 ok
Heat (Mux A) hangs

Don't let the buggers get you down

Graham

[bgowland]

Well, if you want my professional opinion, I haven't got a clue. :confused:

It's still possible it's a Hauppauge driver thing (I'm using 1.219.x dated January 2007) but I'm not convinced. The log for the graph activity shows a timely change from R4 to both Q and heat and the signal statistics show the tuning is locked. In fact, the graph and the service both carry on happily as if there has been no problem.

It's pvrx2 which is deciding that things have come to a halt although it's still not clear why. If you change channel from R4 to Q or heat, does the mp3 file stop growing?

Clutching at straws...I did a search in config.xml and spotted these options which I'd forgotten about

Code:

<UseWindowsMediaPlayerForAudio>
<UseWindowsMediaPlayerForNetRadio>

Both of mine are set to False, how about you?

Cheers,
Brian

[Graham]

Clutching at straws...I did a search in config.xml and spotted these options which I'd forgotten about

Code:

<UseWindowsMediaPlayerForAudio>
<UseWindowsMediaPlayerForNetRadio>

Both of mine are set to False, how about you?

Good clutch

I was using the default values of true. Changing
<UseWindowsMediaPlayerForAudio>true</UseWindowsMediaPlayerForAudio> to false makes a difference to the graph but it still won't work.

My attempts to diagnose have given me a headache so I'm stopping till tomorrow. I have tried playing the mp3 file in Windows Media Player and that is the same as what I hear in PVRX2.

One more potential problem --- I use Nvidia PureVideo because it works best for me - I have Nvidia graphics. Using any audio decoder other Nvidia and the audio and video go out of sync. I suspect that the Nvidia audio decoder may not play mp3.

I'll look at all this again in the am.

[bgowland]

Good clutch

I was using the default values of true. Changing
<UseWindowsMediaPlayerForAudio>true</UseWindowsMediaPlayerForAudio> to false makes a difference to the graph but it still won't work.

I'd also be interested to know if the one for Net Radio makes a difference. The reason I have to name the mp3 buffer file 'gbnetradio' is that pvrx2 treats it differently to normal mp3 files. I think it might use the Net Radio playback logic.

I have tried playing the mp3 file in Windows Media Player and that is the same as what I hear in PVRX2.

As in, it stops at the point when you change to a different MUX?

Using any audio decoder other Nvidia and the audio and video go out of sync. I suspect that the Nvidia audio decoder may not play mp3.

DirectShow filters can be very picky about various things including hiccups in timing of AV streams etc. it is possible that it baulks at the longer time that it takes to switch tuning to a different mux. You could always try the MPA Decoder I use, temporarily. I think it has batch files to easily register/deregister it so it's just a double-click to swap it in and out.

I'll look at all this again in the am.

Thanks for your perseverance - it'd be nice to find a solution if possible. Otherwise it's a case of people havin to use the stop on channel change option for the time being at least. I think long term I'll look at putting my own playback code into the plugin but I want to crack on with the recording capability first.

Cheers,
Brian

[Graham]

Using ...

<settings>
<DisableScreenSaver>False</DisableScreenSaver>
<EnableGetNowNext>False</EnableGetNowNext>
<StopOnChannelChange>False</StopOnChannelChange>
<ScanFullEPG>False</ScanFullEPG>
</settings>

and Process Monitor from sysinternals.com.

Play R4
Start capture in Process Monitor
Change to channel on differernt mux
Stop capture

The process mon log shows amongst many other things that writing to the mp3 file stops when I switch channels.

I have fiddled with audio decoders and config.xml settings and none of that makes any difference. In my amateur opinion, PVRX2 sttings are nowt to do with the channel change issue.

As ever, logs, including process mon are attached.

Good luck

Graham

[bgowland]

and Process Monitor from sysinternals.com.

I'd forgotten all about Process Monitor - I used to use that and Registry Monitorr when I was in computer support. Nice tools.

Unfortunately I can't see anything that you haven't already spotted - writing to the mp3 file stops when the graph is paused before submitting the new tuning and never restarts despite the log showing the graph happily continues on its way.

The breakdown has to be somewhere between the MPEG-2 Demux and the file writer. The front half of the graph is obviously still functional as the log is showing that it has 'Found new radio events', i.e., it is still able to harvest EPG data therefore has a valid transport stream to tap in to.

I'll add some extra logging to see what's happening to the Demux when you change channels to a different MUX. I'll post some new binaries later for testing at your convenience if you're still game.

Cheers,
Brian

[Graham]

I'll post some new binaries later for testing at your convenience if you're still game.

Go for it.

As I understand it (i.e. almost not at all), the EPG has a stream all of its own within each mux and the NowNext is embedded within the radio stream. How might I test whether I am receiving the NowNext after a channel change? The presence or not of NowNext data might be a clue (or not).

Graham

PS The stop on channel change true version seems to work quite nicely so I doubt if anyone will mind if you put this on a back burner ... or ... if you keep plugging away then so will I.

[bgowland]

As I understand it (i.e. almost not at all), the EPG has a stream all of its own within each mux and the NowNext is embedded within the radio stream.

Things like the schedule (full EPG) and present/following (Now/Next) data are carried in 'tables' which aren't streamed as such, they're broadcast cyclically (until out of date) and are separate to AV streams. In other words, regardless of which channel on whatever MUX you're listening to, the EPG and Now/Next info for all channels and MUXs is still accessible. It does, however, require that things are locked to a valid tuning request.

How might I test whether I am receiving the NowNext after a channel change? The presence or not of NowNext data might be a clue (or not).

This (from your last logs) is how I know that despite the fact that the audio is no longer being written to the mp3 file, the BDA components are locked to something valid...

Code:

27/06/2008 14:05:25.546 DMSH: Message handler received: DVBTR_SUBMIT_NEW_TUNING
27/06/2008 14:05:25.546 DMSH: LCN: 714
27/06/2008 14:05:25.546 DMSH: Tuning: 842000 24576 26240
27/06/2008 14:05:25.546     PauseGraph: hr = 1
...
27/06/2008 14:05:26.171     SubmitNewTuning1() put_TuneRequest returned hr = 0
27/06/2008 14:05:27.218     SubmitNewTuning2() put_TuneRequest returned hr = 0
27/06/2008 14:05:27.218     Running graph...
27/06/2008 14:05:27.296     RunGraph hr = 0
...
27/06/2008 14:05:32.437 DMSH: Updating EpgDatabase
27/06/2008 14:05:32.437 DMSH: Entering UpdateEpgDataSet(): FullEpg True
27/06/2008 14:05:33.062     New radio events found
27/06/2008 14:05:33.265     New radio events found
27/06/2008 14:05:33.312     New radio events found

etc.

At that point in your log, the graph is no longer writing to the mp3 file but the BDA components are locked to something otherwise the 'New radio events found' wouldn't be being logged ('event' = programme in DVB speak).

I doubt if anyone will mind if you put this on a back burner ... or ... if you keep plugging away then so will I.

What I wanted to do would have only been a few lines of code but it appears DirectshowLib doesn't support the method I wanted. I've posted a query on the forum over there but it will have to go on back burner until I get a response. I'll keep you posted.

Cheers,
Brian