[ViX_Misc] Narrator voice on Virgin channels

[dsayers]

Maybe discuss the rules in here http://www.world-of-satellite.com/forumdisplay.php?14-Forum-Suggestions-amp-Feedback

 

[Ss66]

I have updated to the ABM 2.8 and most channels now OK but still have issue with SLyDisneyHD and BBC1HD,

Download dreambox edit, then manually edit the audio pids.This worked for me I tried chanalizer but that didn't work for me

 

[tosh2004]

Has the problem been solved, apart from the Disney channel, on Open ATV, but still remains on VIX?

I can confirm on VU+DUO2 openvix latest all working same as openatv

 

[gary64]

do u need to use os for it to work as ive update abm and im just getting black screens

 

[chris16v]

do u need to use os for it to work as ive update abm and im just getting black screens

dont go there Gary64 with just 2 posts. If you've read recent previous posts you'll see no talk about emulators are allowed, forum rules. The MOD is all over this if you even try

 

[gary64]

sorry about that

 

[chris16v]

sorry about that

have a look through the posts around page 12/13/14, see what people are suggesting. If you want to use the path of least resistance then ignore the PID fixes but make sure you have latest ABM 2.8, then after you rescan most HD channels with NAR issues should be in a better place than before. if they are still a problem then have a look on another forum, depends what you want.

 

[dlmlus]

Maybe too little too late for some:

www.virginmedia.com/V6upgrade

 

[ccs]

If allowed....

We strongly recommend you order your new Virgin TV V6 box as soon as possible. This is to ensure you’ll have enough time to install your new Virgin TV V6 box before you experience any loss of service on your older box.

 

[dsayers]

The above is about an issue thats going to happen in January not audio, lets save that for a few months lol

 

[JonMMM]

OK what is said below is not written by me but by Hackmax on another forum, all credit should go to him, I am just coping the post.

Well it's been a few days since the audio problems were introduced on Virgin Media and so far we've have only crappy suggestions
such as editing the PID's manually, hacks to ABM with a 'bodge' to replace scanned results with hard coded data... but so far nobody
has explained how original boxes seem unaffected or attempted to understand what the root cause is, knowledge which would required to fix the issue.

To understand the issue we need to first understand some basics.

Using a program like TSReader you can tune to the TP of the affected stream. In this post I will use TSID:28. The frequency this is
on will vary area by area but once found the channels & data will be the same. This transponder contains 2 services of interest:

- SyFy HD
- TCM HD

The reason these are interesting is they both show slightly different symptoms.

- SyFy HD has no audio at all
- TCM HD has audio, but with narrative.

What is happening is the E2 boxes are seeing the narrative audio tracks as normal (which are regular MPEG2 audio), but not seeing the regular audio which is broadcast in AC3 format.

SyFy HD only has a single AC3 audio track, so with this now 'invisible' to E2, we get no sound!

TCM HD has 2 tracks, the AC3 audio track that is 'invisible' to E2, and a regular MPEG2 audio narrative one that it can see - which it
then selects as default.

Using TSReader & a suitable capture you should tune to this TP (or load in some pre-made capture)

We first want to look at the PAT.

PAT on PID 0 (0x0)

Code:
PAT Version Number: 13
Transport Stream ID: 28 (0x001c)
NIT: [varies by area]

PMT PID 16 (0x0010) - Network
PMT PID 40 (0x0028) - Program 2801 Syfy HD
PMT PID 37 (0x0025) - Program 2802 Comedy Central HD
PMT PID 36 (0x0024) - Program 2803 alibi HD
PMT PID 45 (0x002d) - Program 2804 TCM HD
The PAT (Program Association Table) is stream of data sent on PID 1. It lists all the services on the current transponder, along with pointers
to each services PMT (Program Map Table). Each PMT contains data that is sent on it's own PID.

The PID of the PMT for TCM HD is: PID 45 (0x002d)

Code:
Program Number: 2804
PCR on PID 409 (0x0199)
PMT Version: 22
Service name: TCM HD

Stream Type: 0x02 MPEG-2 Video
Elementary Stream PID 409 (0x0199)

Stream Type: 0x06 Dolby AC3 Audio
Elementary Stream PID 431 (0x01af)

Stream Type: 0x04 MPEG-2 Audio
Elementary Stream PID 441 (0x01b9)

Stream Type: 0x06 Teletext/VBI
Elementary Stream PID 451 (0x01c3)

Descriptor: CA Descriptor
CA System ID: 6209 (0x1841) Nagravision
CA PID 5039 (0x13af)

Descriptor: CA Descriptor
CA System ID: 6224 (0x1850) Nagravision
CA PID 6539 (0x198b)
Capture this to file - extract the single repeating packet.

The packet is the standard 188 bytes long. I've removed the tail padding (FF's) for clarity)

Code:
47 40 2D 1D 00 02 B0 6A 0A F4 ED 00 00 E1 99 F0
0C 09 04 18 41 F3 AF 09 04 18 50 F9 8B 02 E1 99
F0 10 06 01 02 0E 03 C0 C3 50 52 01 00 02 03 1A
44 5F 06 E1 AF F0 12 6A 02 CF 00 0A 04 65 6E 67
00 0E 03 C0 03 C0 52 01 03 04 E1 B9 F0 11 03 01
67 0A 04 4E 41 52 00 0E 03 C0 01 E0 52 01 04 06
E1 C3 F0 0A 56 05 65 6E 67 10 88 52 01 05 8F 87
62 7B
The first 5 bytes are headers - for simplicty we will ignore these. The 'payload' data (the stuff we interpret) starts after this.

02 - Table ID
B0 6A - A set of 16 bits broken up below.

0x1 : Section syntax indicator (1 bit)
0x0 : Private bit (1 bit)
0x3 : Reserved bits (2 bits)
0x0 : Section length unused bits (2 bits)
0x6A : Section length (10 bits)

Syntax section/Table data:

Code:
0A F4 ED 00 00 E1 99 F0 0C 09 04 18 41 F3 AF 09
04 18 50 F9 8B 02 E1 99 F0 10 06 01 02 0E 03 C0
C3 50 52 01 00 02 03 1A 44 5F 06 E1 AF F0 12 6A
02 CF 00 0A 04 65 6E 67 00 0E 03 C0 03 C0 52 01
03 04 E1 B9 F0 11 03 01 67 0A 04 4E 41 52 00 0E
03 C0 01 E0 52 01 04 06 E1 C3 F0 0A 56 05 65 6E
67 10 88 52 01 05 8F 87 62 7B
For the purpose of this post, I won't explain this here (if you really want to understand it ask later)

We now want to to break down this second level of payload.


0A F4 - Table ID extension
ED - A set of 16 bits broken up as.

0x3: Reserved bits (2 bits)
0x16: Version: 22 (5 bits)
0x1: Current/next indicator (1 bit)

00 Section number
00 Last section number

The verson number will change and could be different by the time you read this... It's just a 5 bit counter that wraps round whenever the packet
changes. DVB devices can use this to know if the packet has changed from the version it already has.

This packet only has 1 section (Section ID: 0)

Code:
E1 99 F0 0C 09 04 18 41 F3 AF 09 04 18 50 F9
8B 02 E1 99 F0 10 06 01 02 0E 03 C0 C3 50 52
01 00 02 03 1A 44 5F 06 E1 AF F0 12 6A 02 CF
00 0A 04 65 6E 67 00 0E 03 C0 03 C0 52 01 03
04 E1 B9 F0 11 03 01 67 0A 04 4E 41 52 00 0E
03 C0 01 E0 52 01 04 06 E1 C3 F0 0A 56 05 65
6E 67 10 88 52 01 05 8F 87 62 7B
We now want to to break down this third level of payload.

E1 99 PCR on PID: 409 (0x0199)
F0 0C Length of data to follow (0C) - Top 4 bits are reserved so set to 1, then 2 off

So what we end up with following this is a series of 'Descriptors'.

Descriptors are blocks of 'configuration' data.

They are structured as follows:

Code:
<TAG BYTE> <TAG DATA LENGTH BYTE> <TAG DATA>
Each 'Tag' byte has a specific meaning, for example tag 0x09 is used to specify the ECM PID. As there are 2 versions of Nagravision currently present, we would expect 2 Tag 0x09's, one for each encryption system.

Some code must be written to parse this tags.

So lets look at the 2 simple ECM cases...

Code:
09 Tag - 0x09 - Conditional access system and EMM/ECM PID
04 Tag Length - 0x04
18 41 CAID for ROM180 Cards
F3 AF ECM PID: 0x13AF
Followed by:

Code:
09 Tag 0x09: - Conditional access system and EMM/ECM PID
04 Tag Length - 0x04
18 50 CAID for Tivo/V6 Cardless
F9 8B ECM PID: 0x198B
Nothing to complicated.

Tag 09 has 4 bytes that follow: 2 that specifiy the CAID this is relevent too, and 2 that contain the PID to look for incoming ECM's on.

Ok, following this we have a section what we call the ES_Info, which contain tags to specify the bits that make up what you see (the video PID, the audo PID's, teletext PID's etc.)

There are a number of these - which we can see in TSReader as follows:

Code:
Stream Type: 0x02 MPEG-2 Video
Elementary Stream PID 409 (0x0199)

Stream Type: 0x06 Dolby AC3 Audio
Elementary Stream PID 431 (0x01af)

Stream Type: 0x04 MPEG-2 Audio
Elementary Stream PID 441 (0x01b9)

Stream Type: 0x06 Teletext/VBI
Elementary Stream PID 451 (0x01c3)
We want to look at the AC3 one, which as you can see is clearly listed - but E2 boxes don't see it (hence 'invisible')

Code:
Elementary Stream PID 131 (0x0083) Dolby AC3 Audio
Descriptor: AC3 Audio Descriptor
Flags: AC3 Type: True BSID: True Main ID: False ASVC: False
AC3 Type: 0
BSID: 10
Descriptor: ISO639 Language Descriptor
Language: eng
Audio type: undefined
Descriptor: Maximum Bitrate Descriptor
Maximum bitrate: 48000 bytes per second
Descriptor: Stream Identifier Descriptor
03
So lets look at our raw hex ES info entry:

Code:
06 Stream Type: 0x06 Dolby AC3 Audio
E1 AF PID: 431 (0x01AF)
F0 12 ES_info_length

6A Tag 0x6A: AC-3_descriptor
02 Tag Length: 0x02
CF 00

0A Tag: 0x0A: ISO_639_LANGUAGE_DESCRIPTOR
04 Tag Length: 0x04
65 6E 67 ISO_639_language_descriptor ('eng')
00

0E Tag: 0x0E - Maximum Bitrate Indicator
03 Tag Length: 0x03
C0 03 C0

52 Tag: 0x52: Stream Identifier Descriptor
01 Tag Length: 0x01
03 Stream Identifier Descriptor
This ES_Info is made up of a number of tags, 0x06 been the initial tag, and some sub-tags 0x6A, 0x0A, 0x52

Now this is where the problem is: The tag 0x6A is malformed.

"It specifies a data length of 0x02, which we see the 2 bytes 0xCF and 0x00"

If we use the DVB specification to look at the structure of the AC3 descriptor:

Code:
AC-3_descriptor() {
descriptor_tag 8 uimsbf
descriptor_length 8 uimsbf
component_type_flag 1 bslbf
bsid_flag 1 bslbf
mainid_flag 1 bslbf
asvc_flag 1 bslbf
reserved_flags 4 bslbf
if (component_type_flag == 1) { 8 uimsbf
component_type
}
if (bsid_flag == 1){ 8 uimsbf
bsid
}
if (mainid_flag == 1){ 8 uimsbf
mainid
}
if (asvc_flag == 1){ 8 uimsbf
asvc
}
for(i=0;i<N;i++){ 8 uimsbf
additional_info_byte
}
}

We can see if starts with a tag (0x6A) and length (0x02 in our case)

The next byte that follows this is what is a byte that contains a series of flag.
The lower 4 bits are all reserved (set to 1) so this leaves the upper 4 bits which are defined as follows:

Code:
component_type_flag: This 1-bit field is mandatory. It should be set to "1" to include the optional component_type field in the descriptor.

bsid_flag: This 1-bit field is mandatory. It should be set to "1" to include the optional bsid field in the descriptor.

mainid_flag: This 1-bit field is mandatory. It should be set to "1" to include the optional mainid field in the descriptor.

asvc_flag: This 1-bit field is mandatory. It should be set to "1" to include the optional asvc field in the descriptor.
So for each bit that is set to 1, and extra byte must be included/processed

The upper 4 bits of 0xCF in binary are 1100, so this specifies that the the component_type and bsid are set, requiring 2 more data bytes after the 0xCF - but we only have 1 extra byte remaining (a value of 0x00)

So what happens?

Well the 0x00 gets interpreted as the component_type field, and the next byte after is is 0x0A. This is the start of the next descriptor, this gets interpreted as the bsid field.

In TSReader we see this:

Code:
Flags: AC3 Type: True BSID: True Main ID: False ASVC: False
AC3 Type: 0
BSID: 10
AC3 Type is the component_type field, and BSID is 10 in decimal, which in hex is 0x0A (that tag byte of the following descriptor).

At this point we have overflowed the end of the tag 0x6A... so what happens next?

Well this is down to the parser code. After processing the tag 0x6A, how do we locate the next tag:

2 ways:

1. Assume the next tag starts after the end of the first tag. This is what should happen in normal case.
2. Take the start of the current tag on, and add '2 + the value of <TAG DATA LENGTH>.

If the parser code follows option 1 - then it will start trying to parse the next tag 1 byte to late, and will interpret it as nonsense, and end up discarding it - which is what I suspect E2 is doing.

If the parser code follows option 2 - then the next tag will start at the correct position. The byte 0x0A will be 're-used', as it's both the data at the end of the last tag and the tag byte of the next descriptor. The remaining tags which specify the language ('eng') etc. will be processed correctly.

This is probably accidental rather than by design. My guess is the bsid bit it not supposed to be set... but since it is this is what happens.

I refer to these tags as 'overlapped' tags. I guess E2 cannot handle these overlapped tags correctly, where as official boxes can.

There are some simple code hacks that could allow the parser of E2 to code with these malformed overlapped tags correctly, or they could do a propper job. Thats assuming they do anything at all.

I find it funny that VM try so hard to secure there system, then during a routine upgrade accidently break all the E2 Linux boxes, I really don't know if I should congratulate them on this or slap them for a dirty interpretation of the DVB specification.

I'd like to say sorry to Rat but I did say he probably would not understand my post

Hackmax

 

[Ss66]

Ok so most of the above is way above my head. But does this give us some hope on the impending changes due on the horizon come the end of Jan 2018

 

[JonMMM]

They are 2 different issues, this is all about the problems with Audio on HD channels which is effecting us now.

We dont know what will happen in January so there are no plans for it

 

[eattheliving]

Hi everyone,
Just a quickie.

Can anyone confirm if the last ABM cfg update has fixed bbc1 hd and Disney hd nar please on vix image?

 

[lincsat]

I've just noticed that ABM now flags the altered channels as FTA. I've tried amending the provider file to flag as encrypted but the channels are not then amended on the lamedb. I'm wondering if the FTA flag is causing the issue with multiple channels.

 

[grantsmith82]

please can someone help point me in the right direction for ABM 2.8 that works on open PLI.

 

[tomsta79]

ive done all this with e-channelizer still no audio at all on some channels on my vu duo 2 with newest image and updated config . and abm 2.8

 

[addy73]

hi, iv managed to change to oscam and got the chanels to work but since this business my pic keeps freezing really bad, sometimes the sound will keep playing, othertimes the sound will go off but the pic is ok, can someone just tell me if this is because of whatevers going on or is it something totally different, cheers

 

[samsid]

ive done all this with e-channelizer still no audio at all on some channels on my vu duo 2 with newest image and updated config . and abm 2.8

when you edit the details with e-channeliser, before you write to the box, put enigma2 to sleep with telnet command init 4 , now write the changes to box,then enigma2
should restart & you should have your audio back, if it doesn't restart , telnet init 3

 

[stuhar]

AB Update

when you edit the details with e-channeliser, before you write to the box, put enigma2 to sleep with telnet command init 4 , now write the changes to box,then enigma2
should restart & you should have your audio back, if it doesn't restart , telnet init 3

as of yesterday update was released to the cable_uk_virgin.xml by OE-alliance this does work for the channels that have no ac3 but on the other channels you have no picture so its not working correctly a work in progress I had to revert back to the original. I have changed the audio pids with dreambox editor but when sent to the box no change in the audio channels available and the picture goes blank as well.