EPG data format changes - who is responsible

Our product takes EPG data from the freeview DVB stream. Recently, the
order in which elements of the EPG data are returned changed. Although
the new order was still within the spec, our product broke; our fault,
and quickly fixed. However, I've been asked to find out who decides
when this sort of thing happens. Who's responsible for the format of
the EPG data within the stream?

--
Simon

wrote:
Our product takes EPG data from the freeview DVB stream. Recently, the
order in which elements of the EPG data are returned changed. Although
the new order was still within the spec, our product broke; our fault,
and quickly fixed. However, I've been asked to find out who decides
when this sort of thing happens. Who's responsible for the format of
the EPG data within the stream?

--
Simon

TDN (The Digital Network) is responsible for such things.

wrote:
Our product takes EPG data from the freeview DVB stream. Recently,
the order in which elements of the EPG data are returned changed.
Although the new order was still within the spec, our product broke;
our fault, and quickly fixed. However, I've been asked to find out
who decides when this sort of thing happens. Who's responsible for
the format of the EPG data within the stream?

If it's within the spec, why should you care? Or are you just getting ready
to pounce in the event they get it wrong?

If it's within the spec, why should you care? Or are you just getting
ready to pounce in the event they get it wrong?

In the computing world there are lots of specs. that say "do A or B or C or
...." where you find that 99.999% of the people only ever do A. So do you
spend time and resource on supporting B, C, D, ... which increases code size
and complexity? Difficult choice but the golden rule is normally "if it
ain't broke, don't fix it" so if the EPG were sending X, Y, Z and then
started sending X, Z, Y for no gain, I'd want to ask them why they're
farting about and ensuring that something, somewhere is going to break.

Of course it might be a prelude to rolling out a new feature that REQUIRES
X, Z, Y - but I'd still like to know.

Paul DS

Paul D.Smith wrote:
If it's within the spec, why should you care? Or are you just getting
ready to pounce in the event they get it wrong?

In the computing world there are lots of specs. that say "do A or B
or C or ..." where you find that 99.999% of the people only ever do
A. So do you spend time and resource on supporting B, C, D, ...
which increases code size and complexity? Difficult choice but the
golden rule is normally "if it ain't broke, don't fix it" so if the
EPG were sending X, Y, Z and then started sending X, Z, Y for no
gain, I'd want to ask them why they're farting about and ensuring
that something, somewhere is going to break.
Of course it might be a prelude to rolling out a new feature that
REQUIRES X, Z, Y - but I'd still like to know.

Well, I've never looked at the spec for the EPG data (I'd quite like to, if
it's freely available), but as long as it is clear that there is no implied
order to the elements then software which assumes that there is an implied
order is quite simply wrong (as the OP acknowledged). Reverse-engineering an
existing stream is a recipe for later unhappiness, and people shouldn't do
it.

Sorry, but I've fixed enough broken software to have little sympathy for the
attitude "well, that's how it used to work...". On the other hand, I've also
seen enough badly written specifications to have sympathy with the people
attempting to implement them (especially when it's me), so it would be
premature of me to pass judgement in this case!

wrote:
Our product takes EPG data from the freeview DVB stream. Recently, the
order in which elements of the EPG data are returned changed. Although
the new order was still within the spec, our product broke; our fault,
and quickly fixed. However, I've been asked to find out who decides
when this sort of thing happens. Who's responsible for the format of
the EPG data within the stream?

From experience, the beeb will always meet the spec (they did help
write it!).

Changes can only happen with all agreeing at The Digital Network (TDN)


Try a quick search on ETSI's front page http://www.etsi.org/ for epg
!!! Or have you got and are meeting those specs?

Dickie mint wrote:

Try a quick search on ETSI's front page http://www.etsi.org/ for epg
!!! Or have you got and are meeting those specs?

Ooops, sorry! Type epg into this search page :

http://pda.etsi.org/pda/queryform.asp

"Dickie mint" wrote in message
...
Dickie mint wrote:

Try a quick search on ETSI's front page http://www.etsi.org/ for epg !!!
Or have you got and are meeting those specs?

Ooops, sorry! Type epg into this search page :

http://pda.etsi.org/pda/queryform.asp

Hi Richard,

To simply the search on the ETSI site and as a good starting point I
recommend looking for "EN 300 468" (DVB spec for service information in DVB
systems) and "TR 191 211" (DVB guidelines on the implementation and usage of
Service Information). I think both these are freely available from the ETSI
site but may require a basic registration.

The problem is that these get modified by the "D-book" which defines the UK
specific rules of operation. I think this document is only available to
paid-up members of the DTG. http://www.dtg.org.uk/publications/books.html
However there are some freely available documents on that site including
"TDN Plan for UK DTT SI" but this, while interesting, looks like a basic
summary and I don't think will provide the level of detail required by the
OP.

However as a declared developer of UK DTT receiver/processing systems the OP
should already have, or urgently consider, membership of the DTG. As well
access to the specifications, and the knowledge base of other members, this
would probably provide the level of notification he seems to be seeking.

Glyn

Pyriform wrote:

Well, I've never looked at the spec for the EPG data (I'd quite like to,
if it's freely available), but as long as it is clear that there is no
implied order to the elements then software which assumes that there is
an implied order is quite simply wrong (as the OP acknowledged).
Reverse-engineering an existing stream is a recipe for later
unhappiness, and people shouldn't do it.

The document is part number a038 "Specification for Service Information
(SI) in Digital Video Broadcasting (DVB) Systems"; searching for that and
ETSI should find it.

Having written software to decode EPG data, I found the specification is
only a starting point - there are a huge number of possible options.
--
Dave

"GlynM" wrote in message
...

To simply the search on the ETSI site and as a good starting point I
recommend looking for "EN 300 468" (DVB spec for service information in
DVB systems) and "TR 191 211" (DVB guidelines on the implementation and
usage of Service Information).

Sorry, that should be TR 101 211.

G.