CRIDs

[prl]

I've been having a bit of a play with CRID extraction in the T series EIT EPG code.

The basics are quite simple, and getting the per show CRID data is pretty easy.

There are a couple of problems, potential and immediate.

The potential problem is that per-program CRIDs have two forms, an immediate one, where the CRID string is present in the EIT data for a show. The second is where the CRID is indirect. In the indirect form the per-show data has a tag that references a separate table containing the actual CRIDs, the Content Identifier Table (CIT).

In Canberra, at least, only the direct form seems to be used, which simplifies the extraction, but it means that I don't have any way to test code that might handle indirect CRIDs. If indirect CRIDs were to be used at some time, the code would need to be extended to handle them (or at least have to be debugged).

The immediate problem is that the form of CRIDs used in Australia can be abbreviated. A full CRID is in the form
crid://authority.name/identifying_information#metadata_location

The CRID can be abbreviated by dropping the scheme and '//' (crid://) so that it becomes
authority.name/identifying_information#metadata_location

It can be further abbreviated by transmitting the authority information elsewhere, so that the CRID data in the EPG is stripped down to:
/identifying_information#metadata_location

Adding the "crid://" back in the first abbreviated form is trivial.

In general, the "elsewhere" that can carry the authority name for the second abbreviated form is in any of: Network Information Table (NIT) , Bouquet Association Table (BAT) or Service Description Table (SDT). The FreeTV Operating Practice OP-72 only mentions authority names being carried in the NIT and SDT. I think these tables are only decoded during a service scan.

That means that to expand CRIDs properly, the authority data would need to be extracted at scan time and put into one of the scan tables (probably lamedb).

In Canberra, only SBS uses full CRIDs in the EIT EPG. All the others use the second abbreviated form. No-one seems to use the first, simpler, abbreviated form.

The format of the identifying_information seems to be different enough between the broadcasters that it would be possible (though a huge hack) to use the abbreviated CRID forms as-is.

[IanB]

A maybe slight gotcha is that Freeview advocated that CRID's be scrambled. I have it on fairly good authority that the scrambling algorithm is stable, i.e. A given string or prefix string will always be the same. So a given show's name and an individual episode are still sub-string comparable.

[prl]

A maybe slight gotcha is that Freeview advocated that CRID's be scrambled. I have it on fairly good authority that the scrambling algorithm is stable, i.e. A given string or prefix string will always be the same. So a given show's name and an individual episode are still sub-string comparable.

If what's meant by "scrambled" is that it's not easy to extract the show name from the CRID, that certainly seems to be correct, but that's just what I'd expect. A hash or some sort of network-specific mapping.

But in most cases where they are used, a show has two attached CRIDs, one for the show, and one for the series. For some broadcasters there seems to be a reasonably clear relationship between the two:
Network: <Title> <series CRID> <episode CRID>

ABC: <The Jungle Book> </ZX9477A> </ZX9477A011S00>
SBS: <Spanish News> <crid://canberra.sbshd.sbs.au/199869> <crid://canberra.sbshd.sbs.au/S61561520161118>
SCA: <Hyde & Seek> 32 </16462> </16462D1_8>
Prime: <The Neighbors> </TkVJRw> </TkVJRwEMDA0>
WIN: <Shopping, Travel, Entertainment, Lifestyle> </8278EE1339104373A8D9C48A148> </2E6F8E49812D4A17AAAFBB49CC6>

SBS and WIN Canberra stand out as having no apparent relationship between a series CRID and an episode CRID in that series. WIN Canberra also seems to have very few CRIDs, and even those are misused, using the same episode CRIDs for different event ids on the same service (and presumably same authority name).

Prime also has very few CRIDs.

SBS has some oddball CRIDs too, where there's only an episode CRID, and it doesn't seem to be well-formed: certainly having a random and varying UUID as the authority name looks odd. These shows don't have normal CRIDs (and they don't have a series CRID):
<SBS Chill> <crid://887cdb5a-ceb9-4b21-a0bd-e0d9dff7ad7b>
<Living Black> <crid://55c2c07d-34f4-4591-acac-7e1302aa81dc>

I'm not sure what it's like in metro areas, but certainly in Canberra, WIN and Prim CRIDs are pretty much worthless, because there's virtually no coverage.

But where CRIDs for both episode and title are available, it doesn't really matter whether there's an obvious relationship between them or not, as long as it's stable.

OP-72 also has a code for "recommendation" CRIDs, but no-one seems to provide them.

[IanSav]

Hi Prl,

My contact at Channel 7 has suggested that the CRID data should simply be considered as sets of matchable strings. Don't try the evaluate or look up the CRIDs. Simply note the show and episode CRID data and then use that data to match other events in the EPG. His suggestion is that we can achieve relatively reliable AutoTimer / series link type recordings by using the data provided and not trying to decode or resolve it.

Once you have a program CRID, say "/ZX9477A" for "The Jungle Book" on ABC, then any time you see a CRID of "/ZX9477A" you are looking at another instance of the same show "The Jungle Book" the CRID data is unique so the name used in the EPG doesn't matter. This solves the problem of TV stations adorning their program names will various bits of unwanted "decoration".

Where the program CRIDs for various episodes of a show are the same then you are looking at the same show. When you look at the content CRID, say "/ZX9477A011S00" for the specific episode of "The Jungle Book" then if ever you see that content CRID appear again in the EPG then you know that this is exactly the same episode as the previous occurrence. If the content CRIDs don't match then you are looking at a different episode.

I believe that the CRIDs are the same for each of the LCN from a single broadcaster but will be different for the same show on different broadcasters. If you want to match shows across broadcasters then you will need to go through the process of fully resolving the CRIDs as you discussed in your original post.

As a first pass I believe that the CRID matching as I discussed above would be a significant improvement to the AutoTimer system we currently have. Users would simply need to select a show from the EPG list and then the AutoTimer can scan the EPG looking for the same program CRID to identify all occurrences of the same program. Then the episode CRID can be used to see if this is a repeat or new episode. Recording events can then be appropriately created and maintained.

Another benefit of using CRIDs, even in this simplified way, is that every time an AutoTimer scan is run it can detect changes to scheduling and then match the CRID data held in the timers events to add, delete or update existing timers to match updated TV schedules. If the timer system wants to be really smart it can also check the CRID data before starting the timer recording to check that the event that is about to be recorded is still the same event that the user nominated to record and is not a last minute replacement. TV Stations like to swap shows at the last minute.

Regards,
Ian.

[prl]

... My contact at Channel 7 has suggested that the CRID data should simply be considered as sets of matchable strings. Don't try the evaluate or look up the CRIDs. Simply note the show and episode CRID data and then use that data to match other events in the EPG. His suggestion is that we can achieve relatively reliable AutoTimer / series link type recordings by using the data provided and not trying to decode or resolve it.

I never intended to use them any other way. The only reason I looked at the structure was to answer IanB's concerns about them being scrambled. The answer there is that the "series" part is always "scrambled" in some way, in that it's intended to be an opaque reference. However episode CRIDs from some broadcasters seem to divide neatly into "series" and "episode" parts, and the episode information seems to sometimes have a reasonably transparent interpretation as some sort of season/episode information.

But none of that can be relied on, because it doesn't hold for all broadcasters.

Once you have a program CRID, say "/ZX9477A" for "The Jungle Book" on ABC, then any time you see a CRID of "/ZX9477A" you are looking at another instance of the same show "The Jungle Book" the CRID data is unique so the name used in the EPG doesn't matter. This solves the problem of TV stations adorning their program names will various bits of unwanted "decoration".

Where the program CRIDs for various episodes of a show are the same then you are looking at the same show. When you look at the content CRID, say "/ZX9477A011S00" for the specific episode of "The Jungle Book" then if ever you see that content CRID appear again in the EPG then you know that this is exactly the same episode as the previous occurrence. If the content CRIDs don't match then you are looking at a different episode.

Thanks for the confirmation. That's exactly the way I envisaged they might be used.

I believe that the CRIDs are the same for each of the LCN from a single broadcaster but will be different for the same show on different broadcasters.

That's evident from just the inconsistent form of CRIDs across the broadcasters.

If you want to match shows across broadcasters then you will need to go through the process of fully resolving the CRIDs as you discussed in your original post.

That wasn't the intent of the post, and I don't think it's possible in in general, even where it might be possible to decode the series/episode information..

[prl]

I've been able to extract the default authority part of the CRIDs from the Service Description Table (SDT). There don't appear to be any default authority entries in the Transport stream descriptor loop of the Network Information Table NIT. I haven't found a way yet to check for them in the first (network_descriptors) loop of the NIT, but I may not have looked hard enough. I haven't looked at whether it's possible to extract them from the Bouquet Association Table (BAT) yet.

Anyway, the default authorities in Canberra are:
'SCA' 'Nine Canberra' <canberra.1.sca.au>
'SCA' '9HD Canberra' <canberra.7.sca.au>
'SCA' 'Nine Canberra' <canberra.6.sca.au>
'SCA' '9Gem' <canberra.2.sca.au>
'SCA' '9Go!' <canberra.3.sca.au>
'SCA' '9Life' <canberra.8.sca.au>
'SCA' 'To Be Advised' <canberra.4.sca.au>
'SCA' 'Aspire' <canberra.5.sca.au>
'ABC' 'ABC News 24' <CRID://canberraabcnews24.abc.net.au>
'ABC' 'ABC' <CRID://canberra2.abc.net.au>
'ABC' 'ABC2/KIDS' <CRID://canberra22.abc.net.au>
'ABC' 'ABC' <CRID://canberra21.abc.net.au>
'ABC' 'ABC ME' <CRID://canberra23.abc.net.au>
'WIN Television' 'WIN Canberra' <CRID://can.sr1.win.au>
'WIN Television' 'WIN Canberra HD' <CRID://can.sr4.win.au>
'WIN Television' 'ONE Canberra' <CRID://can.sr2.win.au>
'WIN Television' 'ELEVEN Canberra' <CRID://can.sr3.win.au>
'WIN Television' 'WIN NETWORK' <CRID://can.sr5.win.au>
'WIN Television' 'TVSN' <CRID://can.sr7.win.au>
'WIN Television' 'GOLD' <CRID://can.sr6.win.au>
'PRIME' 'PRIME7 Canberra' <crid://can.6.primetv.com.au>
'PRIME' 'PRIME7 Canberra' <crid://can.6.primetv.com.au>
'PRIME' 'PRIME7 Canberra' <crid://can.6.primetv.com.au>
'PRIME' '7TWO Canberra' <crid://can.62.primetv.com.au>
'PRIME' '7mate Canberra' <crid://can.63.primetv.com.au>
'PRIME' 'ishoptv' <crid://can.65.primetv.com.au>
'PRIME' 'RACING.COM' <crid://can.68.primetv.com.au>

CRIDs don't appear to be being provided for the ABC and SBS "radio" services.

[IanSav]

Hi Prl,

I believe that the CRIDs are the same for each of the LCN from a single broadcaster but will be different for the same show on different broadcasters.

That's evident from just the inconsistent form of CRIDs across the broadcasters.

If you want to match shows across broadcasters then you will need to go through the process of fully resolving the CRIDs as you discussed in your original post.

That wasn't the intent of the post, and I don't think it's possible in in general, even where it might be possible to decode the series/episode information..

The problem of hiding and obfuscation of the CRID data is a result of Freeview enforcing their will on the various broadcasters. Some stations have now done away with hiding and/or fiddling with the CRID data but others are still giving in to the anti social directive of obfuscation. My Seven contact doesn't expect open and unified presentation of CRID data any time soon. He was please to report that at least all stations now populate the CRID data fields. (If I remember the conversation correctly Seven was the last channel to give in and publish the data in the open.)

Regards,
Ian.

[prl]

I'm not sure what you expect to be in CRIDs. Apart from the apparently malformed SBS CRIDs that I mentioned earlier, what's in the CRIDs that I've looked at is pretty much what I'd expect. An obscure (or partly obscure) unique reference, that's intended only to be used as a unique reference.

OP-72 restricts the data part of the CRID to 29 characters, including the '/'. It's really only practical to put in some sort of handle in there. The OP-72 restriction comes from FreeTV, not Freeview.

To me, it certainly doesn't seem to be the the case, no matter what your Seven contact says, that "all stations" have populated CRID data. Prime Canberra, a Seven affiliate, doesn't appear to, to any usable extent. Neither does WIN.

[IanSav]

Hi Prl,

I'm not sure what you expect to be in CRIDs. Apart from the apparently malformed SBS CRIDs that I mentioned earlier, what's in the CRIDs that I've looked at is pretty much what I'd expect. An obscure (or partly obscure) unique reference, that's intended only to be used as a unique reference.

With CRIDs I expect to get a token that will allow correct timer selection of programs that are not affected by programs with similar names or silly changes to the title as assigned by the TV stations.

To me, it certainly doesn't seem to be the the case, no matter what your Seven contact says, that "all stations" have populated CRID data. Prime Canberra, a Seven affiliate, doesn't appear to, to any usable extent. Neither does WIN.

I don't think that affiliates are under the same directives as the networks. I can ask my contact about this if you like.

Regards,
Ian.

[prl]

...

I'm not sure what you expect to be in CRIDs. Apart from the apparently malformed SBS CRIDs that I mentioned earlier, what's in the CRIDs that I've looked at is pretty much what I'd expect. An obscure (or partly obscure) unique reference, that's intended only to be used as a unique reference.

With CRIDs I expect to get a token that will allow correct timer selection of programs that are not affected by programs with similar names or silly changes to the title as assigned by the TV stations.

Then why your apparent concern about "hiding and obfuscation of the CRID data" being a "problem". I think that the potential problem is one of consistency, not of how the CRID data is derived.

One consistency problem is that the CRID authority names seem to be defined too narrowly. Is it really the case that CRID://canberra2.abc.net.au and CRID://canberra22.abc.net.au are distinct CRID authorities? Would a series that appears on ABC and then is repeated on ABC2 really have its CRID data independently re-generated by a distinct naming authority? Surely not, but that's what the usage implies to me. And that's not just ABC: all the Canberra CRID authority names are channel- and region-specific.

To me, it certainly doesn't seem to be the the case, no matter what your Seven contact says, that "all stations" have populated CRID data. Prime Canberra, a Seven affiliate, doesn't appear to, to any usable extent. Neither does WIN.

I don't think that affiliates are under the same directives as the networks. I can ask my contact about this if you like. ...

Perhaps "all stations" means "all stations in eastern mainland state capitals"?

[prl]

OP-72 says:

When the content_identifier_descriptor is used within the EIT, the same sub-table loop should also include a private_data_specifier_descriptor (tax 0x5F) with a private_data_specfier value of 0x000032000 to indicate that the CRIDs carried within the EIT conform to the usage described in this document and is specific to Australian Broadcasters.

The value given for the private_data_specfier value for Australian CRIDs seems to have a typo (it's a 32-bit value, but 9 hex digits are shown), and it's not in the table of Australian CRID private_data_specfier value below the para. They have values in the range 0x00003200 .. 0x0000320F. I think that "tax 0x5f" is a typo for "tag 0x5f".

None of the broadcasters appear to put this private data descriptor in the EIT. Some put the values in the first descriptor loop of the NIT instead. ABC uses 0x00003201 (the ABC-specific value). SBS, SCA and WIN use the generic Australian 0x00003200 value. Prime puts in a private value in that descriptor loop of 0x0000233A. I have no idea what the Prime private data value is supposed to represent.

[IanSav]

Hi Prl,

Then why your apparent concern about "hiding and obfuscation of the CRID data" being a "problem". I think that the potential problem is one of consistency, not of how the CRID data is derived.

My comment was an explanation and not an expression of concern.

Perhaps "all stations" means "all stations in eastern mainland state capitals"?

I suspect that it means all stations owned by the network.

Regards,
Ian.

[IanB]

As far as my scrambled remark, yes the intent was to say the data might only be useful as a unique handle or hash value. And any useful op_72 attributes may possibly be opaque to us. i.e. agreement with what you have subsequently said.

I think the best use we might be able to get is an added OR condition with the Title match, i.e. if a program crid is present and it matches a program crid we have previous interest in, then yes match, e.g. series linking.

And for the episode crid, we might be able to get is an added AND condition with the duplicate/repeated episode description match, i.e. if it matches an episode crid we have previous interest in, then this is possibly a duplicate/repeated episode.

Of course there is no guarantee either field is correctly provided/used.

Same programs might conceivably have different program crids although it may be fairly unlikely different programs will ever have the same crid.

And different episodes might conceivably have the same episode crids, probably a case of all episodes get the same crid just like all episode get the same lame description or conceivably every episode gets a different crid even if they are a duplicate/repeated.

I guess we need to survey the data.

Sigh!

[MrQuade]

I think the best use we might be able to get is an added OR condition with the Title match, i.e. if a program crid is present and it matches a program crid we have previous interest in, then yes match, e.g. series linking.

Agreed. Defintely a good idea to treat is as supplementary data only. The fact that prl is finding his Win and Prime data to be inconsistently applied means that, region depending, the data is simply not to be trusted completely.

[IanSav]

Hi,

All my test scans of Melbourne broadcasts showed that CRID data was supplied. The data appeared to be consistent and usable for program and episode matching.

Regards,
Ian.

[prl]

... Same programs might conceivably have different program crids[ although it may be fairly unlikely different programs will ever have the same crid.

OP-72 explicitly allows there to be multiple CRIDs for different programs (from Annex A (Informative) of OP-72).

A CRID is the output of the search and selection process and is an unambiguous identifier that refers to a piece of content, however multiple CRIDs may refer to that same piece of content.

[my emphasis]

Viewing the whole CRID, the current authority naming scheme guarantees that the CRID will be different for the same item or series shown on two different services (or on the same service in different regions). We could hope, though, that the authorities aren't as distinct as their naming suggests, and that within one broadcaster the CRID data would be the same for the same series or item even if the authority was different. It could go either way with naming between a network and its affiliates.

Between different broadcasters, I think that is pretty much guaranteed that the same shows will have different CRID data.

And different episodes might conceivably have the same episode crids, probably a case of all episodes get the same crid just like all episode get the same lame description or conceivably every episode gets a different crid even if they are a duplicate/repeated.

According to the annex (quote above), that shouldn't happen. But it is only informative, not mandatory, and I know that other "should" parts of the main body of OP-72 appear to be being ignored.

I guess we need to survey the data.

Sigh!

Unfortunately, yes.

[prl]

... All my test scans of Melbourne broadcasts showed that CRID data was supplied. The data appeared to be consistent and usable for program and episode matching. ...

That's my impression from the Canberra data, too. I haven't had a close look to see whether repeats of the same episode get the same CRID data part, especially when repeated on a service with a different authority name from the original (e.g. an ABC <CRID://canberra2.abc.net.au> program being "encored" on ABC2 <CRID://canberra22.abc.net.au>).

[IanSav]

Hi Prl,

That's my impression from the Canberra data, too. I haven't had a close look to see whether repeats of the same episode get the same CRID data part, especially when repeated on a service with a different authority name from the original (e.g. an ABC <CRID://canberra2.abc.net.au> program being "encored" on ABC2 <CRID://canberra22.abc.net.au>).

My testing showed that a repeat episode of a program had identical program and episode CRIDs. In my sample data I only had repeats on the same channel. I did not find any data for a repeat from one LCN to another on the same broadcaster.

Regards,
Ian.

[prl]

I'll have a dig around and see if I can find anything to confirm it. Unfortunately, though, one broadcaster's practices may not be the same as another's.

[IanSav]

Hi Prl,

Unfortunately, though, one broadcaster's practices may not be the same as another's.

Agreed.

That is the wonderful thing about standards. There are so many from which to choose and so many to ignore.

Regards,
Ian.

[prl]

More fun and games with CRIDS... This time, inconsistent application of default authorities:

Code: Select all

<serviceref> <service name> <CRID default authority>
<1:0:1:781:327A:3273:EEEE0000:0:0:0:> <WIN Canberra> <crid://can.sr1.win.au>
<1:0:1:784:327A:3273:EEEE0000:0:0:0:> <WIN Canberra> <>
<1:0:1:782:327A:3273:EEEE0000:0:0:0:> <ONE Canberra> <crid://can.sr2.win.au>
<1:0:1:785:327A:3273:EEEE0000:0:0:0:> <ONE Canberra> <>

Just as well that WIN services don't carry any useful amount of CRID data anyway

[prl]

Here's a snapshot of the CRID data for Canberra. Neither WIN nor PRIME carry a useful amount of CRID-tagged EPG data.

The format is:
crid SID:TSID:ONID type begin_time <CRID> <service_name> <event_name>

Type can be "series", "episode" or "recommendation", but only series" and "episode" appear in the data.

[prl]

Progress so far:

• I can extract CRID default authorities from the Service Description Table (SDT) during a scan and add them to the eService entries in the eServiceReference->eService map in eDVBDB.
• The per-service CRID default authorities are saved in the services section of lamedb in a way that's forward and backward compatible. Old lamedb files without default authority entries can be read in the new code, and the old code can read a lamedb code with default authority entries and ignore them. When the old code writes lamedb on shutdown, the default authority entries are removed. To set up for using CRIDs, a re-scan needs to be done.
• I can assemble fully-specified CRIDs in the EPG code, using the default authority data when necessary.
• I know how to enter the CRID data into the EPG, but I haven't implemented it yet.
• I haven't looked at how to make the CRID data available to the wider UI once the data is available in the EPG.

I've tried to minimise the changes to the API, but some changes are needed. For example,

Code: Select all

eventData::eventData(const eit_event_struct* e, int size, int _type, int tsidonid)

needs to have an SID argument (so that the CRID default authority for a service can be looked up if necessary).

It can be done either by changing the interface to:

Code: Select all

eventData::eventData(const eit_event_struct* e, int size, int _type, int tsidonid, int sid=0)

which is source-compatible, but not binary compatible, or by adding a new eventData constructor

Code: Select all

eventData::eventData(const eit_event_struct* e, int size, int _type, int tsidonid, int sid)

and retaining the old one, which is binary compatible. I'm not sure which way to go.

eDVBService needs a new data member, and again, there are decisions to be made about where to place the new member for whether binary compatibility can be maintained.

There will probably be other issues about maintaining binary compatibility, and I'm not certain it can be done for the whole set of changes.

[prl]

I've got end-to-end CRID functionality now:

and for recordings:

CRIDs aren't really intended to be displayed like that, but I'll probably keep the Converters.EventName interface anyway.

I ended up having to move where I normalise the CRIDs that aren't transmitted in full. It meant more changes to calls to the functions that do it, but it was the only way I could think of to handle CRIDs in Now/Next EPG items. They're special.

[IanB]

Great work!

Now I see why you were futzing around getting the CRID default authority. We are almost certainly not going to be interested in the authority part, from correlating the Melbourne data we are going to only ever be interested in the value part of the data and then only as an opaque handle.

And for the 5 broadcasters in Melbourne that do CRID data (C31 does not) so far both the program and episode values are useful within all lcn's for that broadcaster, at least so far with the programs they do show on multiple lcn's.

Yeah only SBS do seem to include a fully formed CRID value with unique authority part for each lcn, so we are probably going to need to strip that to make our unique opaque handles. With the others, 3 just have a mashed string starting with a "/", and nein has some form of human compatible data semi matching the program title.

Not sure why the now/next needs to be "special". From the broadcast data stream the now and next are just 2 specific examples of the more general 7 day epg data. Mostly they are actually identical to the equivalent epg entry and when they do differ it is in the start time and duration values, but this is rare.


Off topic observation :- For the now and next data what is actually more interesting than any included start time and duration (which are often wrong) is the times that the data toggles in the broadcast data stream.

[prl]

Great work!

Thanks.

Now I see why you were futzing around getting the CRID default authority. We are almost certainly not going to be interested in the authority part, from correlating the Melbourne data we are going to only ever be interested in the value part of the data and then only as an opaque handle.

IMO the networks have totally misunderstood what the authority part of the CRID is intended for.

Not sure why the now/next needs to be "special".

It's not particularly special of itself. Its handling in the enigma2 code is different from the handling of other EPG data.

For the now and next data what is actually more interesting than any included start time and duration (which are often wrong) is the times that the data toggles in the broadcast data stream.

That's true, but when the code fetches a CRID, I want it to always have the same form, whether it's fetched from the EPG or from the separate now/next event data.

[IanB]

IMO the networks have totally misunderstood what the authority part of the CRID is intended for.

But what added value can you see, if any from whatever authority part you may find?

Not sure why the now/next needs to be "special".

It's not particularly special of itself. Its handling in the enigma2 code is different from the handling of other EPG data.

Yes, sigh!

Off topic observation :- For the now and next data what is actually more interesting than any included start time and duration (which are often wrong) is the times that the data toggles in the broadcast data stream.

That's true, but when the code fetches a CRID, I want it to always have the same form, whether it's fetched from the EPG or from the separate now/next event data.

I don't understand how the now/next stream transitions effect your use of the data presentation.
Do you have a source code reference?

[IanSav]

Hi Prl,

Congratulations on such a great job. Hopefully your efforts will grant us CRID based recording timers in next to no time.

I think it would be helpful for comparison and display purposes if there are two presentations of the CRID data. I am thinking of something like:

• Event_CRID: Fully resolved event CRID. (e.g. "crid://nine.com.au/CYSH")
• Event_CRID_Long: Same as previous.
• Event_CRID_Authority: Authority component of the event CRID. (e.g. "crid://nine.com.au/")
• Event_CRID_Short: Event component of the event CRID. (e.g. "CYSH")
• Episode_CRID: Fully resolved episode. CRID (e.g. "crid://nine.com.au/CYSH_16_11")
• Episode_CRID_Long: Same as previous.
• Episode_CRID_Authority: Authority component of the episode CRID. (e.g. "crid://nine.com.au/")
• Episode_CRID_Short: Episode component of the episode CRID. (e.g. "CYSH_16_11")

I believe that the "Event_CRID_Authority" and "Episode_CRID_Authority" should be the same so they may simply become the one value "Authority_CRID".

From what I have noted of the Melbourne data some level of manipulation of the raw data will be required to produce data that looks like the examples above.

Regards,
Ian.

[prl]

...
Yeah only SBS do seem to include a fully formed CRID value with unique authority part for each lcn, so we are probably going to need to strip that to make our unique opaque handles. With the others, 3 just have a mashed string starting with a "/", and nein has some form of human compatible data semi matching the program title.
...

I'm considering making the changes available upstream if people in, say, OpenVIX are interested. If that's to happen, I think it's best for the low-level (C++) code to return fully qualified CRIDs. Who knows, other places may well use authority names in a more sensible manner.

[IanSav]

Hi Prl,

I'm considering making the changes available upstream if people in, say, OpenVIX are interested.

This is definitely off topic but please consider also sending your help system, information screen improvements and all your other fixes and improvements upstream as well.

Not only does this benefit the OE-Alliance community as a whole it will also make future merges easier for PeterU.

Regards,
Ian.

[prl]

Hi Prl,

I'm considering making the changes available upstream if people in, say, OpenVIX are interested.

This is definitely off topic but please consider also sending your help system, information screen improvements and all your other fixes and improvements upstream as well.
...

The improvements to the help system wouldn't be too hard to offer upstream, but they need to be accompanied by a lot of work in changing ActionMaps to add descriptions (and especially description functions that reflect the current actions of configurable buttons) and ActionMap descriptive names (which are used as the section headings in the Help screens).

The information screens changes could probably be sent upstream reasonably easily, but they may need modification to work in the upstream environments.

As for sending all my improvements upstream, that's a rather big ask, and one that runs into a lot of problems in testing the changes in the upstream environment.

One problem in all of that is that the branches in which the changes were developed are long gone, so offering the branches as a starting point for a merge to upstream may be difficult.

[IanSav]

Hi Prl,

Sorry, I didn't appreciate the effort that would be required. Your improvements to the code are very valuable. I will try suggesting that the OpenViX developers have a look at your efforts with a view to replicating your improvements into the OpenViX and OE-Alliance builds.

Regards,
Ian.

[prl]

... Congratulations on such a great job. Hopefully your efforts will grant us CRID based recording timers in next to no time.

Thanks.

CRID AutoTimers will need a bit of thinking about to implement. In particular, they'll need to operated smoothly and simply in CRID-rich environments and CRID-poor environments (yes, I'm looking at you, Prime and Win).

I think it would be helpful for comparison and display purposes if there are two presentations of the CRID data. I am thinking of something like:

• Event_CRID: Fully resolved event CRID. (e.g. "crid://nine.com.au/CYSH")
• Event_CRID_Long: Same as previous.
• Event_CRID_Authority: Authority component of the event CRID. (e.g. "crid://nine.com.au/")
• Event_CRID_Short: Event component of the event CRID. (e.g. "CYSH")
• Episode_CRID: Fully resolved episode. CRID (e.g. "crid://nine.com.au/CYSH_16_11")
• Episode_CRID_Long: Same as previous.
• Episode_CRID_Authority: Authority component of the episode CRID. (e.g. "crid://nine.com.au/")
• Episode_CRID_Short: Episode component of the episode CRID. (e.g. "CYSH_16_11")

I believe that the "Event_CRID_Authority" and "Episode_CRID_Authority" should be the same so they may simply become the one value "Authority_CRID".

Is that a proposal for Converters.EventName? If so, I'm actually not sure why you'd want a rich variety of presentation methods for display of CRIDs. I can't think of too many places where you's want to display CRIDs anyway.

IMO the low-level (C++) code should deliver the CRID type (episode, series, recommendation) and the fully qualified CRID, and perhaps the CRID location (EPG or CIT) as well, though by the time the CRID has been fully qualified, the location is not really relevant. It's all further slightly complicated by FreeTV deciding (for no reason given in OP-72), that while ETSI TS 102 323 uses the CRID types 0x01, 0x02 & 0x03, Australia should use 0x31, 0x32 & 0x33 (at least in a consistent order).

From what I have noted of the Melbourne data some level of manipulation of the raw data will be required to produce data that looks like the examples above. ...

It might be useful to start gathering a list of CRID Authority Names to try to work out a good common form for comparison. The problem is that the names seem to have been chosen to be over-specific and it may be difficult to tease out what the meaningful parts are of a CRID Authority Name.

In Canberra, there's:
canberra.1.sca.au
canberra.7.sca.au
canberra.6.sca.au
canberra.2.sca.au
canberra.3.sca.au
canberra.8.sca.au
canberra.4.sca.au
canberra.5.sca.au
CRID://canberraabcnews24.abc.net.au
CRID://canberra2.abc.net.au
CRID://canberra22.abc.net.au
CRID://canberra21.abc.net.au
CRID://canberra23.abc.net.au
CRID://can.sr1.win.au
CRID://can.sr4.win.au
CRID://can.sr2.win.au
CRID://can.sr3.win.au
CRID://can.sr5.win.au
CRID://can.sr7.win.au
CRID://can.sr6.win.au
crid://can.6.primetv.com.au
crid://can.62.primetv.com.au
crid://can.63.primetv.com.au
crid://can.65.primetv.com.au
crid://can.68.primetv.com.au
crid://canberra.sbshd.sbs.au
crid://canberra.sbsone.sbs.au
crid://canberra.sbsthree.sbs.au
crid://canberra.sbstwo.sbs.au
crid://canberra.sbshd.sbs.au
crid://canberra.sbsone.sbs.au
crid://canberra.sbsthree.sbs.au
crid://canberra.sbstwo.sbs.au

So, for example, there's even variation in the number of domain name components that identify a broadcaster, 3 for ABC (abc.net.au) and 2 for everyone else in canberra. The rest of the naming hierarchy is a bit of a mess, too. What was the ABC thinking of with "canberra22", etc? At least everyone else is more-or-less consistent with a "region.channel" prefix.

But there are still questions about consistency: is there a real difference between, say, canberra.1.sca.au and wollongong.1.sca.au*? Do canberra.7.sca.au (Nine HD Canberra) and melbourne.9hd.nine.au* (Nine HD Melbourne) really represent different naming authorities for CRIDs? Similarly, are melbourne.9hd.nine.au* (Nine HD Melbourne) and sydney.9hd.nine.au* (Nine HD Sydney) really different naming authorities? Are affiliate CRID data parts taken direct from their network partner? Always? Sometimes? Always for partner-generated material, but independently assigned for the affiliate's own product? What happens when grand affiliate swaps happen like the recent WIN/SCA swap?

Would it be more accurate to just change them all to crid:://hww.com.au/, or are the CRID data parts actually assigned by the networks rather than the aggregator? Would something more like crid:://nine.hww.com.au/ reflect reality better?

* Invented, but hopefully plausible and representative.

[prl]

IMO the networks have totally misunderstood what the authority part of the CRID is intended for.

But what added value can you see, if any from whatever authority part you may find?

I see only negative added value in the current authority names (see my post just above this reply). I think that at least for Australian use, AutoTimer and similar CRID uses would probably work best by comparing just the data part of the CRID and ignoring the authority name altogether. The only wrinkle in that is that SBS Radio uses bizarre CRIDs that have no data part, and are just "crid://uuid", so that every SBS Radio CRID has its own authority name, and no CRID data. An authority unto itself, perhaps.

Off topic observation :- For the now and next data what is actually more interesting than any included start time and duration (which are often wrong) is the times that the data toggles in the broadcast data stream.

That's true, but when the code fetches a CRID, I want it to always have the same form, whether it's fetched from the EPG or from the separate now/next event data.

I don't understand how the now/next stream transitions effect your use of the data presentation.
Do you have a source code reference?

They don't directly. The code has a permanent "listener" for Now/Next data. When new Now/Next data arrives, the m_event_now and m_event_next fields in eDVBServiceEITHandler are updated. These are the "special" places where the Now/Next data is stored. When the update happens, any functions that have connected to eDVBServiceEITHandler::m_eit_changed are called. Those calls, for example, trigger the "start/end" marks in recordings.

The example display code just reats the "now" event data in eDVBServiceEITHandler when an EventView screen is opened in live TV.

The whole thing is further complicated by eDVBServicePlay::updateEpgCacheNowNext() which sets Now/Next from the EPG if normal Now/Next updates aren't happening.

[IanSav]

Hi Prl,

Is that a proposal for Converters.EventName? If so, I'm actually not sure why you'd want a rich variety of presentation methods for display of CRIDs. I can't think of too many places where you's want to display CRIDs anyway.

Yes, I was thinking of the Converter context. It is a selfish desire to make the data conveniently available mostly for testing and verification purposes.

It might be useful to start gathering a list of CRID Authority Names to try to work out a good common form for comparison. The problem is that the names seem to have been chosen to be over-specific and it may be difficult to tease out what the meaningful parts are of a CRID Authority Name.

Do you have a tool that can collect the authority data form all broadcasters in an area. What I am thinking is to harvest data in a similar manner we used to collect tuning data for the picons.

I use the DVBViewer diagnostic tool to get access to the data but it is not a simple tast. Other users are probably unable to get access to the data without assistance.

But there are still questions about consistency: is there a real difference between, say, canberra.1.sca.au and wollongong.1.sca.au*? Do canberra.7.sca.au (Nine HD Canberra) and melbourne.9hd.nine.au* (Nine HD Melbourne) really represent different naming authorities for CRIDs? Similarly, are melbourne.9hd.nine.au* (Nine HD Melbourne) and sydney.9hd.nine.au* (Nine HD Sydney) really different naming authorities? Are affiliate CRID data parts taken direct from their network partner? Always? Sometimes? Always for partner-generated material, but independently assigned for the affiliate's own product? What happens when grand affiliate swaps happen like the recent WIN/SCA swap?

Would it be more accurate to just change them all to crid:://hww.com.au/, or are the CRID data parts actually assigned by the networks rather than the aggregator? Would something more like crid:://nine.hww.com.au/ reflect reality better?

* Invented, but hopefully plausible and representative.

In Melbourne we have:

• ABC LCNs use:
  • ABC (LCN-2): "CRID://melbourne2.abc.net.au"
  • ABC (LCN-21): "CRID://melbourne21.abc.net.au"
  • ABC2/KIDS (LCN-22): "CRID://melbourne22.abc.net.au"
  • ABC ME (LCN-23): "CRID://melbourne23.abc.net.au"
  • ABC NNews 24 (LCN-24): "CRID://melbourneabcnews24.abc.net.au"
• Seven Network LCNs use "crid://seven.net.au"
• Nine Network Australia LCNs use "crid://nine.com.au"
• Ten Melbourne LCNs use:
  • ONE (LCN-1): "crid://melbourne.onehd.ten.au"
  • Ten Digital (LCN-10): "crid://melbourne.ten.ten.au"
  • ELEVEN (LCN-11): "crid://melbourne.11.ten.au"
  • ONE (LCN-12): "crid://melbourne.onehd12.ten.au"
  • TEN HD (LCN-13): "crid://melbourne.ten.ten.au"
  • TVSN (LCN:14): "crid://melbourne.tvsn.ten.au"
  • SpreeTV (LCN-15): "crid://melbourne.spree.ten.au"
• SBS LCNs use:
  • SBS ONE (LCN-3): "crid://melbourne.sbsone.sbs.au"
  • SBS HD (LCN-30): "crid://melbourne.sbshd.sbs.au"
  • SBS VICELAND (LCN-32): "crid://melbourne.sbstwo.sbs.au"
  • Food Network (LCN-33): "crid://melbourne.sbsthree.sbs.au"
  • NITV (LCN-34): "crid://melbourne.nitv.sbs.au"
  • SBS Radio also uses the CRID fields but the data is not standard / uniform.
• C31 has an authority of "crid://C31.community.com.au" but does not supply CRID data for its programs.

Regards,
Ian.

[prl]

Hi Prl,

Is that a proposal for Converters.EventName? If so, I'm actually not sure why you'd want a rich variety of presentation methods for display of CRIDs. I can't think of too many places where you's want to display CRIDs anyway.

Yes, I was thinking of the Converter context. It is a selfish desire to make the data conveniently available mostly for testing and verification purposes.

The interface you proposed seems at once both unnecessarily large, because it contains functions not needed for testing, and too restrictive because it doesn't allow for the three types of CRID, two of which (series and episode) seem to be used on all EPG events that have CRID data. For testing, I'd have thought that the fully qualified CRID would give all the information necessary. The current code allows for:

Code: Select all

<convert type="EventName">CridSeries</convert>
<convert type="EventName">CridEpisode</convert>
<convert type="EventName">CridRecommendation</convert>

If there is more than one CRID of the type requested, only the first one is returned.

It might be useful to start gathering a list of CRID Authority Names to try to work out a good common form for comparison. ....

Do you have a tool that can collect the authority data form all broadcasters in an area. What I am thinking is to harvest data in a similar manner we used to collect tuning data for the picons.

I use the DVBViewer diagnostic tool to get access to the data but it is not a simple tast. Other users are probably unable to get access to the data without assistance.

There's an implicit tool, the lamedb file. After a scan with the CRID additions to the firmware, lamedb service entries look like this:
0213:eeee0000:0211:1010:1:0
ABC
p:ABC,c:000200,c:01028a,c:020240,c:030080,a:crid%3a//canberra21.abc.net.au

That doesn't give the SBS authority names, because they don't use the default authority mechanism, but they appear to be consistent, and the only thing that seems to vary is the "region" part of the authority name. SBS still uses "canberra.sbstwo.sbs.au" as the authority name for Viceland.

...
In Melbourne we have:

• ...
• Seven Network LCNs use "crid://seven.net.au"
• Nine Network Australia LCNs use "crid://nine.com.au"
  ...

...

At least they seem to have worked out what a sensible authority name looks like.

SBS Radio also uses the CRID fields but the data is not standard / uniform.

Yes, as I noted above, the SBS Radio CRIDs all seem to be in the form "crid//uuid", which seems not to be a form compatible with OP-72 or ETSI TS 102 822. It looks like the "authority_name/" part just just been omitted. SBS Radio only has episode CRIDs in their EPG.

[IanSav]

Hi Prl,

The interface you proposed seems at once both unnecessarily large, because it contains functions not needed for testing, and too restrictive because it doesn't allow for the three types of CRID, two of which (series and episode) seem to be used on all EPG events that have CRID data. For testing, I'd have thought that the fully qualified CRID would give all the information necessary. The current code allows for:

Code: Select all

<convert type="EventName">CridSeries</convert>
<convert type="EventName">CridEpisode</convert>
<convert type="EventName">CridRecommendation</convert>

If there is more than one CRID of the type requested, only the first one is returned.

So what will these strings look like?

Regards,
Ian.

[prl]

Hi Prl,

The interface you proposed seems at once both unnecessarily large, because it contains functions not needed for testing, and too restrictive because it doesn't allow for the three types of CRID, two of which (series and episode) seem to be used on all EPG events that have CRID data. For testing, I'd have thought that the fully qualified CRID would give all the information necessary. The current code allows for:

Code: Select all

<convert type="EventName">CridSeries</convert>
<convert type="EventName">CridEpisode</convert>
<convert type="EventName">CridRecommendation</convert>

If there is more than one CRID of the type requested, only the first one is returned.

So what will these strings look like?
...

Like fully qualified CRIDs, as you can see in the screenshots I posted.

[IanSav]

Hi Prl,

Like fully qualified CRIDs, as you can see in the screenshots I posted.

Okay. That is why I wanted some converter options that can pick apart the elements of the CRID for display.

Based on your proposal I will adjust my request as follows. For an event CRID of "crid://station.com.au/programname" and an episode CRID of "crid://station.com.au/episodeid":

• "CridAuthority" would be "crid://station.com.au/"
• "CridEvent" would be "crid://station.com.au/programname"
  "CridSeries" would be more consistently named as "CridEvent". Not all CRIDs are for series events, but every CRID is for an event.
• "CridEventShort" would be "programname"
• "CridEpisode" would be "crid://station.com.au/episodeid"
• "CridEpisode" would be "episodeid"
• "CridRecommendation" would be "crid://station.com.au/recommend"
• "CridRecommendationShort" would be "recommend"
  I have not encountered any "CridRecommendation" type entries so I have no idea how the data looks. Have you seen this entry on any of your broadcasters.

Regards,
Ian.

[prl]

I haven't seen any CRID recommendations in the Canberra data.

It might be cleaner to implement what you want as an option on the item being extracted, so:
"CridEpisode" and "CridEpisode,Full" give "crid://station.com.au/programname"
"CridEpisode,Authority" gives "station.com.au"
"CridEpisode,Path" gives "/programname"
and similarly or "CridSeries" and "CridRecommendation, returning the same respective parts for the series and recommendation CRIDs.

I'm still not convinced that it's necessary, though.

"CridSeries" would be more consistently named as "CridEvent". Not all CRIDs are for series events, but every CRID is for an event.

I'm not sure what you mean there about series CRIDs. A series CRID is attached to an event, but it is not "for an event". It marks that event as part of a series of events (which may contain only a single event, e.g. for a movie).

From OP 72:

• 0x31(event CRID) references the item of content that this event is an instance of.
  0x32 (series CRID) references a series that this event belongs to.
  0x33 (recommendation CRID) references a recommendation. This CRID can be a group or a single item of content.

So I would expect a recommendation for a series to be the series CRID for a series and a recommendation for a single event to be the event CRID for the event. The CRID lookup mechanism would have to resolve them appropriately.

[IanB]

For an event CRID of "crid://station.com.au/programname" and an episode CRID of "crid://station.com.au/episodeid"

Given the ease which people tend to extend their interpretation of the data beyond that which is actually there, we should aim to avoid any subconscious hints that may lead to future disappointment.

In our discussions we should avoid internet like references, crids are not web addresses, do not use web like addresses in examples.

The data part is at best a pseudo references more likely an opaque string of characters, "programname" implies a meaningful program name. "eventid" and "episodeid" better convey the idea of a hash value or index value.

To limit undue expectations I suggest we use something like :-

• For the series CRID refer as "crid://station.au/seriesid"
• For the episode CRID refer as "crid://station.au/episodeid"

Edit: changed event to series, doh!

[prl]

What's an "event CRID"?

There are episode, series and recommendation CRIDs. Their intended purpose is held in a content identifier descriptor, but not in the CRID itself. The crid type/intended use is held in the crid_type field of the content identifier descriptor.

Actual event instances are referenced by locators, not by CRIDs. A locator for a specific DVB event has the form:
dvb://<original_network_id>.[<transport_stream>].<service_id>;<event_id> [~time_duration]

A locator can be the result of CRID content resolution. It is envisaged that the AutoTimer system would become a CRID content resolver, but its output would be in the form of one-off timers, not DVB-T locators in the syntax above, but a one-off timer can be readily converted into that locator syntax (and with the help of the EPG, the locator can be converted into a timer).

As an example of CRIDs other than series or recommendation CRIDs being episode, not event labels, here are the CRIDs for Hard Quiz on ABC services for the week 20-26 Nov:

Code: Select all

<ABC> <Hard Quiz> 2016-11-23T20:01 <crid://canberra2.abc.net.au/le1531v006s00>
<ABC> <Hard Quiz> 2016-11-23T20:01 <crid://canberra21.abc.net.au/le1531v006s00>
<ABC2/KIDS> <Hard Quiz> 2016-11-24T20:30 <crid://canberra22.abc.net.au/le1531v006s00>
<ABC> <Hard Quiz> 2016-11-25T22:20 <crid://canberra2.abc.net.au/le1531v006s00>
<ABC> <Hard Quiz> 2016-11-25T22:20 <crid://canberra21.abc.net.au/le1531v006s00>

They are:

• simulcast of Hard Quiz on LCNs 2 & 21 (ABC) 2016-11-23T20:01,
  "encore" of Hard Quiz on LCN 22 (ABC2/KIDS) 2016-11-24T20:30 and
  "encore" simulcast of Hard Quiz LCNs 2 & 21 (ABC) 2016-11-25T22:20.

The authority name part changes with the LCN, but the data part is the same no matter which event it is or which LCN. They are episode, not event, CRIDs.

[IanSav]

Hi Prl,

It might be cleaner to implement what you want as an option on the item being extracted, so:
"CridEpisode" and "CridEpisode,Full" give "crid://station.com.au/programname"
"CridEpisode,Authority" gives "station.com.au"
"CridEpisode,Path" gives "/programname"
and similarly or "CridSeries" and "CridRecommendation, returning the same respective parts for the series and recommendation CRIDs.

Rather than "Path" can we have "Data", as IanB commented, this is not a web address.

"CridSeries" would be more consistently named as "CridEvent". Not all CRIDs are for series events, but every CRID is for an event.

I'm not sure what you mean there about series CRIDs. A series CRID is attached to an event, but it is not "for an event". It marks that event as part of a series of events (which may contain only a single event, e.g. for a movie).

What I was trying to say, in a very clumsy way, was that the word "Series" should be replaced with the word "Event" in the converter names. The word "Event" is likely to be better understood. All programs are "Events" but not all programs are part of a "Series". Yes, technically a program can be a "Series" of one "Episode" but I think this would be unnatural and confusing.

So I would expect a recommendation for a series to be the series CRID for a series and a recommendation for a single event to be the event CRID for the event. The CRID lookup mechanism would have to resolve them appropriately.

Yes, I guessed that if you are a fan of "Doctor Who" then you may get recommendations of "Torchwood", "Class", "The Sarah Jane Adventures" etc.

This is a service our broadcasters are unlikely to offer us. IceTV on the other hand may want to populate such a field.

Regards,
Ian.

[IanSav]

Hi Prl,

...

Code: Select all

<ABC> <Hard Quiz> 2016-11-23T20:01 <crid://CRID://canberra2.abc.net.au/le1531v006s00>
<ABC> <Hard Quiz> 2016-11-23T20:01 <crid://CRID://canberra21.abc.net.au/le1531v006s00>
<ABC2/KIDS> <Hard Quiz> 2016-11-24T20:30 <crid://CRID://canberra22.abc.net.au/le1531v006s00>
<ABC> <Hard Quiz> 2016-11-25T22:20 <crid://CRID://canberra2.abc.net.au/le1531v006s00>
<ABC> <Hard Quiz> 2016-11-25T22:20 <crid://CRID://canberra21.abc.net.au/le1531v006s00>

...

It looks wrong to see "crid://CRID://". Would it be appropriate / correct to condense this down to "crid://".

Regards,
Ian.

[prl]

Hi Prl,

It might be cleaner to implement what you want as an option on the item being extracted, so:
"CridEpisode" and "CridEpisode,Full" give "crid://station.com.au/programname"
"CridEpisode,Authority" gives "station.com.au"
"CridEpisode,Path" gives "/programname"
and similarly or "CridSeries" and "CridRecommendation, returning the same respective parts for the series and recommendation CRIDs.

Rather than "Path" can we have "Data", as IanB commented, this is not a web address.

I'm easy either way, but I was unaware that a URI can't have a path. Especially since a URL is an instance of a URI and RFC 3986 refers to that part of a URI as a path.

The path component contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical query component (Section 3.4), serves to identify a resource within the scope of the URI's scheme and naming authority (if any).

A hierarchical naming scheme is not necessarily a URL. Oddly enough, though:

The syntax of an authority name is:
<DNS name>

<DNS name> is a registered Internet domain name or a delegated sub-domain within such a domain.

So a CRID is perhaps more like a URL than one might initially think.

"CridSeries" would be more consistently named as "CridEvent". Not all CRIDs are for series events, but every CRID is for an event.

I'm not sure what you mean there about series CRIDs. A series CRID is attached to an event, but it is not "for an event". It marks that event as part of a series of events (which may contain only a single event, e.g. for a movie).

What I was trying to say, in a very clumsy way, was that the word "Series" should be replaced with the word "Event" in the converter names. The word "Event" is likely to be better understood. All programs are "Events" but not all programs are part of a "Series". Yes, technically a program can be a "Series" of one "Episode" but I think this would be unnatural and confusing.

Neither a series nor an episode CRID refers to a single event. Both refer to a set of events, and the all events they refer to need not even be able to be resolved (a series CRID certainly refers to events not yet in the EPG, and an episode CRID could also refer to a re-run of the show in a year's time). The CRID model allows for, for example, a series CRID to be issued before the series is even scheduled so that PVRs can be set to record the series before the series actually appears in schedules (or has even been scheduled by the broadcaster).

So I would expect a recommendation for a series to be the series CRID for a series and a recommendation for a single event to be the event CRID for the event. The CRID lookup mechanism would have to resolve them appropriately.

Yes, I guessed that if you are a fan of "Doctor Who" then you may get recommendations of "Torchwood", "Class", "The Sarah Jane Adventures" etc.

This is a service our broadcasters are unlikely to offer us. IceTV on the other hand may want to populate such a field. ...

FreeTV (which is after all created by the broadcasters) left provision for Recommendations in OP-72. I have no idea how likely it is that any of them would implement it. It seems a reasonable tool for cross-promotion or for promoting upcoming shows, though the latter would need some way to provide informtion about shows not yet in the EPG.

IceTV had an individual recommendations service in their Web pages for a while. I complained about how bad I thought it was on the IceTV forum at the time (for example, it included in its list of recommendations shows I'd already marked for recording or as favourites). They stopped providing it after a while, and said they were going to do something themselves at some point. That hasn't happened so far, and there doesn't seem to be any provision for it in the published IceTV API.

[IanB]

To limit undue expectations I suggest we use something like :-

For the event CRID refer as "crid://station.au/eventid"
For the episode CRID refer as "crid://station.au/episodeid"

What's an "event CRID"?

There are episode, series and recommendation CRIDs. ...

Ah yes caught in my own excess to avoid "programname"

Doh! event and episode are the same thing, i.e. type 0x31, unique for a given episode of a show. Episode would be the preferred term.

I should have called it a series crid, i.e. type 0x32, common for all episode of a show.

I'll edit my post to avoid future confusion.

[prl]

No, episode and event are not the same thing. The same episode CRID can be attached to different events

Hi Prl,

...

Code: Select all

<ABC> <Hard Quiz> 2016-11-23T20:01 <crid://CRID://canberra2.abc.net.au/le1531v006s00>
<ABC> <Hard Quiz> 2016-11-23T20:01 <crid://CRID://canberra21.abc.net.au/le1531v006s00>
<ABC2/KIDS> <Hard Quiz> 2016-11-24T20:30 <crid://CRID://canberra22.abc.net.au/le1531v006s00>
<ABC> <Hard Quiz> 2016-11-25T22:20 <crid://CRID://canberra2.abc.net.au/le1531v006s00>
<ABC> <Hard Quiz> 2016-11-25T22:20 <crid://CRID://canberra21.abc.net.au/le1531v006s00>

...

It looks wrong to see "crid://CRID://". Would it be appropriate / correct to condense this down to "crid://".

Regards,
Ian.

.
It is wrong, and it is a bug, since fixed. I've edited my post.

[prl]

...
Doh! event and episode are the same thing, i.e. type 0x31, unique for a given episode of a show. Episode would be the preferred term.
...

No, an event and an episode are not the same.

Here's an example. Five Hard Quiz events, one episode data tag. Three different CRIDs because of the weird authority naming that some broadcasters are using. IMO it should be the same episode CRID for all of them (something like crid://abc.net.au/le1531v006s00).

Code: Select all

<ABC> <Hard Quiz> 2016-11-23T20:01 <crid://canberra2.abc.net.au/le1531v006s00>
<ABC> <Hard Quiz> 2016-11-23T20:01 <crid://canberra21.abc.net.au/le1531v006s00>
<ABC2/KIDS> <Hard Quiz> 2016-11-24T20:30 <crid://canberra22.abc.net.au/le1531v006s00>
<ABC> <Hard Quiz> 2016-11-25T22:20 <crid://canberra2.abc.net.au/le1531v006s00>
<ABC> <Hard Quiz> 2016-11-25T22:20 <crid://canberra21.abc.net.au/le1531v006s00>

In the DVB-T world, an event can be described by a locator, and you would use a CRID resolver to find the locators that match an episode (or, indeed, a series) CRID.

[IanB]

No, episode and event are not the same thing. The same episode CRID can be attached to different events

Fair enough, to clarify an episode crid will be what we are interested for detecting episode repeats. It will need the authority part striped to be useful here in oz.

And an event crid is the unique instance of that crid on that lcn (described by a locator).