Humax HDR-Fox T2 moved from UK to Australia

Brian Burch · Jan 28, 2015

af123 said:
You're right - the gory details are in
http://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.14.01_60/en_300468v011401p.pdf

Yuk! I haven't been there before...

af123 said:
Did you select the original network and TS ids from anywhere?

"select" isn't the right word. I "inherited" them from a successful auto-scan when in Brisbane. Having returned home to the Sunshine Coast I did not realise their significance for EPG data, so I left the existing (Brisbane) values alone while hacking channels.db to get the video and sound to work properly.

Only now am I sufficiently confident to work on the EPG. In other words, my current channels.db EPG data (whatever that might be) does not match dvbsnoop because the current values correspond to Brisbane, while my dvbsnoop data corresponds to the desired region of Sunshine Coast and are taken by dvbsnoop from the aerial.

I need to discover which fields in which tables to hack, given that my proposed ETI/EPG values are available from the aerial, according to the dvbsnoop ETI data for the five multiplexes.

af123 · Jan 28, 2015

It's possible to run dvbsnoop on a recording, so from one of mine from last week:

Code:

# dvbsnoop -s ts -if New_\ The\ 100_20150127_2100.ts -tssubdecode 18

  TS sub-decoding (17 packet(s) stored for PID 0x0012):
  Subdecoding takes 16 bytes from next TS packet
  =====================================================
  TS contains Section...
  SI packet (length=2838):
  PID:  18 (0x0012)  [= assigned for: DVB Event Information Table (EIT)]

  Guess table from table id...
  EIT-decoding....
  Table_ID: 81 (0x51)  [= Event Information Table (EIT) - actual transport stream, schedule]
  section_syntax_indicator: 1 (0x01)
  reserved_1: 1 (0x01)
  reserved_2: 3 (0x03)
  Section_length: 2835 (0x0b13)
  Service_ID: 8381 (0x20bd)  [=  --> refers to PMT program_number]
  reserved_3: 3 (0x03)
  Version_number: 21 (0x15)
  current_next_indicator: 1 (0x01)  [= valid now]
  Section_number: 80 (0x50)
  Last_Section_number: 248 (0xf8)
  Transport_stream_ID: 8217 (0x2019)
  Original_network_ID: 9018 (0x233a)  [= UK Digital Terrestrial Television | Independent Television Commission]
  Segment_last_Section_number: 80 (0x50)
  Last_table_id: 81 (0x51)  [= Event Information Table (EIT) - actual transport stream, schedule]

This is the MUX information in the database:

Code:

sqlite> select * from TBL_TS where ustsid = 8217;
  tsIdx = 1
  netIdx = 1
  bouqIdx = 0
  usTsId = 8217
  usOrgNetId = 9018
  ucTunerId = 255
  ucSearchFlag = 0
  eDeliType = 2
  ulFrequency = 658000
  ulSymbolRate =
  ePolarization =
  eFecCodeRate = 0
  eTransSpec =
  ePskMod = 2
  ePilot = 2
  eRollOff = 2
  eSatType =
  ucAntId =
  usNetworkId =
  eConstellation = 3
  eSpectrum =
  eBandwidth = 1
  eHierachy = 0
  eStream = 2
  eGuardInterval = 4
  eTransMode = 2
  eOffset = 0
  ucChanNum = 0
  ucLevel = 60
  ucQuality = 100
  eSystem = 0
  ulPlpId = 255
  ePreambleFormat = 0
  eMixed = 0
  ePilotPattern = 0
  eExtenedCarrier = 0
  ePAPRreduction = 0
  ulNumPlpBlocks = 0
  ucProgNum =
  eBand =
  ucOffset =
  eColorSystem =
  eAudioSystem =
  ucFineTuneFlag =
aucDefaultAuthority =
  ulFTAContentMgr = 0
  stRegionInfo =

and the service within that Mux:

Code:

sqlite> select * from TBL_SVC where ussvcid = 8381;
  svcIdx = 6
  usLcn = 33
  szSvcName = ITV +1
  usSvcId = 8381
  eSvcType = 1
  eVideoType = 1
  eCasType = 1
  ucVideoCodec = 1
  ucAudioCodec = 1
  usPmtPid = 1900
  usVideoPid = 1901
  usAudioPid = 1902
  usPcrPid = 1901
  usTtxPid = 8192
  tsIdx = 1
  prvIdx = 1
  ucSearchFlag = 0
  eOrgDeliType = 2
  ucAudUserSetFlag = 0
  ucSubttlUserFlag = 0
  ucSubttlIdx = 255
  ucLocked = 0
  hSvc = 65542
  usAudioAuxPid = 8192
  ucSatType = 0
  ucSoundMode = 0
  ucAudioAuxCodec = 0
  usDolbyPid = 8192
  ucChListPriority = 0
  ucAntIdx = 0
  usOnId = 9018
  usTsId = 8217
  ucModifiedName = 0
  ucDolbyFlag = 0
  ucLcnFlag = 1
  ucVisibleSvcFlag = 1
  ucDolbyCodec = 0
  eOrgSvcType = 1
ulRatingPassedEventId = 4294967295
  eSection = 16
  eSvcOpType = 1
  eUserFlag1 = 2
  usOrgLcn = 0
  aucDefaultAuthority = www.itv.com
  ulFTAContentMgr = 0
  ucGuidanceType = 255
  ucGuidanceMode = 0
  szGuidanceStr =
  stRegionInfo =

Border · Jan 28, 2015

I get signals from two countries. The EPG displayed depends on the active channel also. Two differences I have seen in the channel.dB file if it is any help are:

Country 1 : (Free view) usOnId value 9018 and ucLcnFlag = 1

Country 2 : usOnId value 8564 and ucLcnFlag = 0

When watching transmission from Country 1 only the EPG from Country one is visible and watching country 2 only EPG from country 2 visible. Could the ucLcnFlag be relevant?

Border · Jan 28, 2015

Border said:
Could the ucLcnFlag be relevant?

Having the ucLcnFlag set to 0 is possibly the reason the LCNs from Country 2 are in the 800's on my hdr and irrelevant here sorry.

However the only other consistent differences between the 2 countries on my TBL_SCV is the usOnId field which is also the usOrgNetId and for Freeview corresponds also to the Original_network_Id field in post #43 above.

The only time both EPGs display simultaneously is on startup....provided that I power down with one provider (Country 2) and on start up ensure a lcn from the other provider (Country 1) selected. I use the power-on package to select the start up channel.

This only lasts until a channel change or playing a recorded show ends. After this the EPG just shows the channels of the active signal i.e. either country1(freeview usOnId 9018) or country2 (usOnId 8564).

Two questions if you could answer might solve the OPs EPG problem.
1 Why on startup can both countries EPG show, and what changes after a channel change?
2 Could you change the box/EPG fields eg usOnId or are they locked in humaxtv process? My very uneducated guess is that on startup the processes running have no 'affiliated' Original_network_Id then some thing (eg channel change) triggers humaxtv to 'affiliate' itself to one (or other) original_network_id .

I hope the OP succeeds with his quest !!

grahamlthompson · Jan 29, 2015

Brian Burch said:
Thanks very much for explaining how it works in the UK. Clearly, my presumption was wrong. Equally clearly, the co-operative scheme you describe has significant advantages (for the ordinary user) over the piecemeal scheme adopted in Australia. There is obviously a trade-off in the time taken to fully populate the guide, and presumably the "owner" of each UK multiplex could (would?) give priority for transmission of data for its own segment of the global EPG...

You are probably thinking of ota software updates. These are only carried on a single multiplex.

Owen Smith · Jan 29, 2015

If you auto tuned successfully in Brisbane, why can't you do a new auto tune on the Sunshine Coast?

Border · Jan 30, 2015

Brian Burch said:
There does not seem to be any series-link information

Series link depends on the network.

If any one is interested some differences between how Freeview and other Network series link are below

Freeview :

Code:

                  DVB-DescriptorTag: 84 (0x54)  [= content_descriptor]
                  descriptor_length: 2 (0x02)
                     Content_nibble_level_1: 3 (0x03)
                     Content_nibble_level_2: 0 (0x00)
                        [= show/game show (general)]
                     User_nibble_1: 0 (0x00)
                     User_nibble_2: 0 (0x00)


                  DVB-DescriptorTag: 95 (0x5f)  [= private_data_specifier_descriptor]
                  descriptor_length: 4 (0x04)
                  PrivateDataSpecifier: 9018 (0x0000233a)  [= Independent Television Commission ]

                  DVB-DescriptorTag: 137 (0x89)  [= User defined/ATSC reserved]
                  descriptor_length: 27 (0x1b)
                  Descriptor-data:
                       0000:  00 65 6e 67 43 6f 6e 74  61 69 6e 73 20 61 64 75   .engContains adu
                       0010:  6c 74 20 68 75 6d 6f 75  72 2e 20                  lt humour.

                  DVB-DescriptorTag: 118 (0x76)  [= content_identifier_descriptor]
                  descriptor_length: 9 (0x09)
                  crid_type: 49 (0x31)  [= user defined]
                  crid_location: 0 (0x00)  [= Carried explicitly within descriptor]
                  crid_len: 7 (0x07)
                  crid_bytes:
                       0000:  2f 34 4a 35 45 54 34                               /4J5ET4


                  DVB-DescriptorTag: 118 (0x76)  [= content_identifier_descriptor]
                  descriptor_length: 9 (0x09)
                  crid_type: 50 (0x32)  [= user defined]
                  crid_location: 0 (0x00)  [= Carried explicitly within descriptor]
                  crid_len: 7 (0x07)
                  crid_bytes:
                       0000:  2f 4d 34 35 52 4a 37                               /M45RJ7

Note the line :
crid_type: 49 (0x31)
and compare with the other network/country transmission below :

This is from another European Network, which the Humax HDR doesn’t recognise series link data on the EPG :

Code:

DVB-DescriptorTag: 84 (0x54)  [= content_descriptor]
                  descriptor_length: 2 (0x02)
                     Content_nibble_level_1: 0 (0x00)
                     Content_nibble_level_2: 0 (0x00)
                        [= reserved]
                     User_nibble_1: 0 (0x00)
                     User_nibble_2: 0 (0x00)


                  DVB-DescriptorTag: 118 (0x76)  [= content_identifier_descriptor]
                  descriptor_length: 22 (0x16)
                  crid_type: 1 (0x01)  [= CRID references the item of content that this event is an instance of]
                  crid_location: 0 (0x00)  [= Carried explicitly within descriptor]
                  crid_len: 8 (0x08)
                  crid_bytes:
                       0000:  2f 35 36 32 38 30 32 33                            /5628023

                  crid_type: 2 (0x02)  [= CRID references a series that this event belongs to]
                  crid_location: 0 (0x00)  [= Carried explicitly within descriptor]
                  crid_len: 10 (0x0a)
                  crid_bytes:
                       0000:  2f 31 34 31 37 30 32 37  37 34                     /141702774

Note the lines in the above example
crid_type: 1 (0x01)
crid_type: 2 (0x02)
in the above example the humax HDR is unable to read this information, even if the Country / Settings in the secret menu are changed.

Owen Smith · Jan 30, 2015

Why oh why is there not one worldwide standard for Series Link? Sigh.

af123 · Jan 30, 2015

That's a mis-reading of the spec by one or other party, 49 being the ASCII code for the digit 1.
No idea which one is right!

Edit: Didn't I write the epgpatch package to correct something else different coming from this provider... memory is going!

Owen Smith · Jan 30, 2015

af123 said:
That's a mis-reading of the spec by one or other party, 49 being the ASCII code for the digit 1.

Then the spec was ambiguous. All it takes is a few encoded examples or clear documentation on how everything is to be encoded to avoid that sort of thing.

(And to think that people complained about ASN.1. It was completely unambiguous how to encode things.)

raydon · Jan 30, 2015

This is an extract from the New Zealand Freeview transmission spec which I believe is largely based on UK D-Book spec. It throws a little light 0n CRID Type numbers.

Code:

7.1.3 CRID Types
A content identifier descriptor can indicate the type of CRID that is carried therein. There are 2 types of CRID on the Freeview DVB-T Network:-
A Series CRID – to group together an arbitrary selection of content (e.g. a series)
A programme CRID – to identify a specific piece of content (e.g. programme)
In order to safeguard against potential legacy issues that may arise if a full TV-Anytime service is deployed on the Freeview NZ DVB-T Network the following user private CRID types (Which follow D Book [23] types) are to be used:
crid_type :-
0x31 DTG programme CRID (equivalent to type 0x01)
0x32 DTG series CRID (a restriction of type 0x02 to be used only for series)
A PVR should ignore all other CRID types.

TV-Anytime CRIDS are defined in ETSI TS 102 323 section 12.1.4 table 116 as:

Code:

0x01 CRID references the item of content that this event is an instance of.
0x02 CRID references a series that this event belongs to.
0x03 CRID references a recommendation. This CRID can be a group or a single item of content.
0x04 to 0x1F DVB reserved.
0x20 to 0x3F User private

Two specs, deliberately different, so it looks like both are right.

Owen Smith · Jan 30, 2015

I can't see what legacy issues they were worried about. The UK deployed Series Link with many existing DVB-T receivers already in service and I don't recall it breaking any of them.

raydon · Jan 31, 2015

Receiver only or PVR ?

Owen Smith · Jan 31, 2015

raydon said:
Receiver only or PVR ?

I'm talking about anything capable of receiving DVB-T, this includes PVRs, TVs, receive only STBs, USB sticks for PCs, the lot. Did any of them break when Series Link was rolled out? Because that seems to be what the aussies were worried about.

(But surely any new PID is as likely or unlikely to break things, so I still fail to see the point of being non standard.)

raydon · Jan 31, 2015

So what is the "standard" ? I think it was more a question of when historically, that series linking was first rolled out, who rolled it out, and on which particular platform. I'm not sufficiently well versed on the evolution of digital broadcasting to make any kind of judgement. Surely there is be no need for series linking on anything but PVR's ? Is a conflict possible because they would both be using the same 0x76 "content_identifier_descriptor" ? Was there a UK TV provider already using the TV-Anytime format EPG, or any other EPG format using series linking before Freesat/Freeview was rolled out ? I really don't know. What system is used by Sky TV who were probably the first ?

prpr · Jan 31, 2015

As I understand it (which is possibly not very well), the UK uses (private) CRID types 0x31, 0x32, 0x33 (programme, series, recommendation respectively) and all other types should be ignored by compliant receivers.
The full TV-Anytime format uses 0x1, 0x2, 0x3, so by implication the UK doesn't use a full TV-Anytime EPG. I have no idea what that means really.

raydon · Jan 31, 2015

prpr said:
As I understand it (which is possibly not very well), the UK uses (private) CRID types 0x31, 0x32, 0x33 (programme, series, recommendation respectively) and all other types should be ignored by compliant receivers.
The full TV-Anytime format uses 0x1, 0x2, 0x3, so by implication the UK doesn't use a full TV-Anytime EPG. I have no idea what that means really.

I agree that is the case, but Owen's point seems to be that there was no reason to have used private CRIDs in the first place, and instead there should be only one International standard (TV-Anytime ?). But who dictates the rules when there is no precedent. Which is why I asked "What is the standard ?" The format that is broadcast first ?

Owen Smith · Jan 31, 2015

raydon said:
I agree that is the case, but Owen seem to believe there was no reason to have used private CRIDs in the first place, and there should be only one International standard (TV-Anytime ?). But who dictates the rules when there is no precedent. Which is why I asked "What is the standard ?" The format that is broadcast first ?

The value of a single International Standard is that equipment works everywhere. I write software for a living, and this kind of lack of agreed standards is the bane of my life. We're always having to adapt software so that it works according to standard Y as well as the closely related standard X it was written to. Not to mention what happens when the standards are mutually incompatible so you need configuration to handle both. It's ridiculous and it helps no-one.

raydon · Jan 31, 2015

Agreed, and understood. It would be great if the DTG were to throw away the D-Book, but we're too far down that particular road to change direction now.

I think commercial interest plays a big part in these decisions. A bit like the Betamax v VHS format war of the early taped recording days.

Brian Burch · Feb 2, 2015

Owen Smith said:
If you auto tuned successfully in Brisbane, why can't you do a new auto tune on the Sunshine Coast?

This was my original point, which I will return to eventually. Basically, the hidden menu "country" parameters for Australia are totally broken, so you have to set the country to Germany before it will successfully autotune in Brisbane.

It works in Brisbane because the Germany parameters use 7MHz bandwidth for the VHF channels where the Brisbane transmitters are found. The Germany parameters switch to 8MHz bandwidth in the UHF, but Australia uses 7MHz for ALL its multiplexes. This means the autotune in the Sunshine Coast is looking at the wrong frequencies and it never detects the actual transmissions.

In other words, this isn't just a Sunshine Coast problem. It will apply to any Australian DTV transmitter that uses the UHF band.

Humax HDR-Fox T2 moved from UK to Australia

Member

Administrator

Member

Member

Well-Known Member

Well-Known Member

Member

Well-Known Member

Administrator

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Member