No audio/video on one DVB-C channel

[pankov]

Hello.

I'm a long time DVBViewer user and it's been one of my favorite applications since the beginning. I've been using it for watching/recording DVB-C and DVB-S/S2 channels without any problems for a long time but two days ago I lost the audio ... and the picture ... on one particular channel. It's the Discovery Science from my cable provider (DVB-C). Currently this channel is detected as having two additional audio streams which I kind of doubt cause on the TV I can't find them but it could be a problem on my TV. The main channel is named "Discovery Science" and the two sub-channels (audio streams) are called "Discovery Science (1)" and "Discovery Science (2)". The problem is that if I tune the main channel or the first sub-channel I get no video or audio. The second sub-channel gives me picture but still no audio. I find it very strange that changing audio stream can cause the video to disappear but I'm not the specialist here. Even more strange is that I used TransEdit's Analyzer and it doesn't detect this second audio stream (PID 1923) at all (see attached .csv). I guess something is confusing DVBViewer's and TransEdit scanners.

 

I've attached a cut down version of my channels.dat file and the .csv export from TransEdit Analyzer.

I can also provide access to my Recording Service or directly to the PC either via VNC or TeamViewer.

 

I hope somebody will be able to help me because this is one of my favorite channels and I really miss it.

support.zip

channels.dat.zip

ESTNET 698000.csv.zip

[pankov]

Guys,

do you need more info about the problem or you are simply on vacation (lucky you) and will look at my problem later?

[Griga]

TransEdit's Analyzer doesn't detect this second audio stream (PID 1923) at all

It's not in the PID list, which means, the stream wasn't broadcasted at this time. However, the scanner doesn't check which streams are actually broadcasted and how they are broadcasted. It relies on the PMT (Program Map Table). So better have a look at the left side of the Analyzer Window and the content of the PAT -> Service = XXXXX - Discovery Science -> PMT node. Export the service node as XML and post/attach it here.

 

BTW: The CSV file shows that the Discovery Science streams (MPEG2 Video + 2 x MPEG Audio) weren't encrypted at this time (no $ mark resp. displayed in black in the PID list), but in your channellist Discovery Science is flagged as encrypted, which may cause confusion, because DVBViewer resp. the CAM will try to decrypt it.

[pankov]

Griga,

10x for your attention.

 

Here are two .xml export (of the whole transponder and only of Disc.Sci. channel) so you can compare a working with non working channel.

I've also attached a screenshot of the scanner window. This time the channel is marked as encrypted - I don't know why it wasn't so the last time.

 

btw

you can see that there are some blank white cells in the lang. column. Even if I Add/Update them they are left white - like there is a difference to the channel list.

It's a mini ... even micro ... issue but I thought it's better to let you know.

698MHz Analyzer+Scanner.zip

[Griga]

According to the PMT there are three MPEG audio streams without any language assignment, and the whole stuff is encrypted (conditional access descriptor present). That's what the scanner reads.

 

However, the PMT content is not always reliable. Some broadcasters are handling it a bit carelessly. Streams may be unencrypted, though there is a conditional access descriptor present. Since on some channels the number of audio tracks may vary (depending on the audio tracks provided by the source) they may be temporarily switched off, though they are still listed in the PMT. By comparing the PMT content and the PID list you can detect such discrepancies.

 

DVBViewer never deletes audio tracks from the channellist once they have been detected. However, the Channel -> Auto Update function (if enabled) always keeps track of the PMT. It automatically adds tracks that are not yet present in the channellist, and if you try to switch over to an audio track that is not available, DVBViewer will auto-switch to a track that is listed in the PMT. Usually it works pretty well, provided the information in the PMT is correct. That's something you must check.

 

Concerning the issues described in your first post... maybe your CAM gets confused by a wrong PMT content (just a guess). Decrypting heavily relies on it.

[pankov]

Griga,

10x again for your time, but I'll need some more of it.

I think ... but not 100% sure ... that I understand what you say but let me confirm it.

You say that my cable provider is somehow messing up the signal. The question is how can I avoid being affected by it?

I've tried deleting the additional audio tracks but DVBViewer keeps adding them. So the question is - how can I disable the "Auto update" function?

And I'm still puzzled by the fact that if I switch from a 16:9 channel to this Discovery Science which is 4:3 DVBViewer changes it's size as if it detects the video stream and knows that it's 4:3 but can't decode it. And even more strange is that I get perfect video but no audio when I select the third audio track (PID 1923) - how is DVBViewer (Rec. Service to be precise) able to decrypt it but not the audio? Why is this not working on the other audio tracks?

 

I apologize for all these questions but I really miss this channel as it's one of my favorite ones and I doubt my provider will ever react to my complains

[Griga]

I've tried deleting the additional audio tracks but DVBViewer keeps adding them.

Because they are listed in the PMT. Use TransEdit to check if they are actually broadcasted.

 

how can I disable the "Auto update" function?

Channel menu.

 

And I'm still puzzled by the fact that if I switch from a 16:9 channel to this Discovery Science which is 4:3 DVBViewer changes it's size as if it detects the video stream and knows that it's 4:3 but can't decode it.

Indicates that it gets decoded. For further diagnosis have a look at the DVBViewer Filter Property Page.

[pankov]

1. From what I see only the first two are actually broadcasted (has data)

... or did you mean simply to use the TransEdit scanner?

 

2. Channel menu -> 10x - I know I've seen it somewhere but I usually have the menu hidden so I've missed it

 

3. I've looked at DVBViewer Filter and here are some screenshots

This is what I get on the main audio track

and from time to time the filter state changes from Running to Stopped.

And even more rarely everything changes to this

When I change to the third audio track I get the following

 

So is there anything I can do or I'm simply screwed by my provider?

[Griga]

The third track is the one that is in the PMT, but not broadcasted, correct?

 

Obviously the Discovery Science streams are still unencrypted. Have you already tried to untick the "Encrypted" checkbox in the DVBViewer channel editor?

 

Seems there are scores of timestamp discontinuities in the audio streams, for whatever reason, indicating corrupted data. If it's not the broadcaster's fault, it's due to your CAM, I guess. The discontinuities trigger error messages sent by the DVBViewer Filter to the host application, that in return tries to clear things by stopping and restarting playback. In your case it is happening so fast that playback never really starts.

 

You can let the DVBViewer Filter ignore these errors by unticking "Check Timestamp Continuity" -> Apply and a channel change (or some other action that implies playback stop/run). However, since DirectShow doesn't like discontinuous timestamps at all, playback may still be spoiled. That's why the DVBViewer Filter & DVBViewer try to handle such errors.

[pankov]

Griga,

you are great

 

Now let's answer your questions:

1. Yes, the "third track" is the one in the PMT, but not broadcasted.

2. I did try unchecking the "Encrypted" check box but it didn't make any difference.

 

But your final suggestion - unchecking "Check Timestamp Continuity" made all the difference. Now it works perfectly - no breaks no discontinuities ... a little slow start after channel change but it's bearable and definitely better than black screen or no sound

Now the question is - what I loose with "Check Timestamp Continuity" ucnchecked? If it's that important I guess the best solution will be to have it on "per channel" bases but I can only hope you'll implement such an option only for me.

 

Today I tried another thing - recording this channel and see if the recording plays fine. And strangely or not it does play fine. So does this mean that it's only DVBViewer/DVBViewer Filter that's affected? If you want I can provide a recording for you to check it out.

Edited July 17, 2011 by pankov