[cflorian]

Fedora 18
XMBC v12
vnsiserver 0.9.0 (Protocol 3)
vdr (1.7.31/1.7.31)

I'm stuck on this problem and would appreciate any suggestions. All live TV channels work fine except for two which have no audio. XMBC audio config screen shows that there are no streams available for these channels. My channels.conf shows two audio PIDs. Here is an example of one of the problematic channels:

250-3 CBLT-DT Toronto HD;(null):509000:M10:A:0:49=2:52=eng@4,53=es@4;52=@106,53=@106:0:0:3:0:0:0

I do get audio for this channel with Kaffeine or by using mplayer/streamdev. However, when I connect with XBMC, I see the following in the VDR logs:

Mar 30 06:13:03 mediahub1 vdr: [971] changing pids of channel 3 from 49+49=2:52=eng@4,53=es@4;52=@106,53=@106:0:0 to 49+49=2:0:0:0
Mar 30 06:13:03 mediahub1 vdr: [11285] changing pids of channel 3 from 49+49=2:52=eng@4,53=es@4;52=@106,53=@106:0:0 to 49+49=2:0:0:0

This only happens when vnsi-client switches to this channel. I've tweaked just about every setting I could find. I've also tried to cleared the sqllite dbase for the plugin config.

Any help would be appreciated.

[FernetMenta]

0.9.0 is a rather old version. It may already have been fixed in 0.9.1

[cflorian]

Thanks for the reply.

I pulled the latest xbmc and xbmc-pvr-addons from git and recompiled (was using the stock FC18 packages before). vdr now shows:

# vdr --version
vdr (1.7.31/1.7.31) - The Video Disk Recorder
vnsiserver3 (0.9.1) - VDR-Network-Streaming-Interface (VNSI) Server
streamdev-server (0.6.0) - VDR Streaming Server
remote (0.5.0) - Remote control

But the problem remains. Same two channels do not have audio. One thing that I did notice that is odd. In XBMC, when I go to System/System Info/PVR Service, it shows:

PVR Backend: VDR-Network-Streaming-Interface (VNSI) Server
Version:0.9.0 (Protocol: 3)

Should this now show version 0.9.1?

[charlie0440]

He said to try the newer vnsi which is protocol 4. Read the first post of the vnsi4 thread

[FernetMenta]

Nope, I said vnsi3. Please post a xmbc debug log and vdr syslog. If you provide a 1-2 minute recording I can check whether vnsi4 works.

[FernetMenta]

52=eng@4,53=es@4;52=@106,53=@106

The problem is duplicate PIDs for audio. I don't think this is valid for pmt. Since the pmt was generated by vdr it might be a vdr issue. Could you upgrade to vdr version 2 and check if this issue still exists?

[FernetMenta]

ATSC does not have mpeg2 audio. Interestingly the language code is set on this identifier. I will provide a fix for vnsi4.

[cflorian]

I don't know whether it was upgrading to vdr2/vnsi4 that did it or changing the /etc/vdr/setup.conf/StandardCompliance to 1, but it works great now for both bad channels. Thanks very much for your prompt assistance.

[cflorian]

I've found another issue, but this time with recordings, on any channel. I've pulled all the latest changes and recompiled and live TV still works great, including audio.

When viewing a recording, picture freezes and stutters as the audio icon in the overlay flips from mp1 to mp2 to mp3, then back again.

StandardsCompliance is still set to 1 - which I've verified was the origin of the earlier problem with live TV.

I can PM you a sample of the recording if you want. Just let me know.

Thanks.

[FernetMenta]

Yes, please send a sample. But I think this is not related to vnsi because recordings use ffmpeg parser.

[cflorian]

Yes, I used ffmeg -i to check out the .ts file and it seemed to indicate a problem with the audio streams - which would point to vdr itself. But I would still appreciate it if you could take a look as I know next to nothing about this stuff.

I will PM you the file and associated logs.

Thanks again.

[FernetMenta]

I think ffmpeg faces the same problem I just fixed in vnsi parsers. Those channels have duplicate pids in the program map table. I gave ac3 precedence over mpeg2 (which does not exist for ATSC). This is why it works now for vnsi.

I tried your sample with another player and it works fine. Means that ffmpeg can't cope with the issue but maybe should. You can also blame vdr because it just relays the bad pmt instead of filtering the problem.

[cflorian]

Thanks for checking. I'll submit a bug report to vdr first and see what they come back with.

Thanks again for your help.

[cflorian]

I figured out how to fix this. I changed the vdr setup.conf file to use ChannelUpdate=2 (was 0) and now vdr correctly interprets the streams as AC3.

[FernetMenta]

Good news. So you channels.conf was the problem. What has created it?