CRIDs

[Grumpy_Geoff]

Here's a alpha patch (one for each Beyonwiz model) of the that collects CRID information and inserts it in the EPG (broadcast EPG only, not IceTV).

Is this any different to the one I ran last December? Do you need me to run it again for Perth data?

Only in minor ways, and only to see whether anything has improved/got worse. I only got into this because Adoxa wanted CRID source code to play with.

Here's the new Perth CRID scan results.
Seven Network CRID event data now present due to "missing authority" inclusion.
Still no West TV CRIDs.
Event data result was sorted by ONID/TSID/SID, and then by date/time, and duplicates were removed. If you want the original then let me know.

CRID_Perth_Aug2018.zip

(137.47 KiB) Downloaded 78 times

Cheers,
Geoff

[adoxa]

Here's the new Perth CRID scan results.

ABC, SBS and Seven are the same as Rockhampton/CQ, but Nine and Ten are different. Nine Perth has a (mostly) four-letter series CRID, with the episode CRID containing that plus an episode number, a season/year and episode number, or what looks to be a production number. Nine/SCA has a five-digit series code, with the episode CRID containing that and season/year and episode numbers. Ten Perth has a five-digit series CRID, with the episode CRID containing that plus a number that relates to episode (i.e. it's not an episode number, but it does generally increase). WIN has no CRID data (and the data present in Freeview is mostly just hex digits). Oh, and Nine Perth has a single authority and series CRID, whereas SCA has an authority and series CRID for each channel.

[prl]

I've started coding the extraction of the default authority from the NIT, where Seven stashes it in some locations.

[prl]

I've started coding the extraction of the default authority from the NIT, where Seven stashes it in some locations.

It's done and doesn't crash on a scan in Canberra, but a scan in Canberra doesn't test the new code

Adoxa, what's your preference for to test this? Shall I just check the changes into Crid-dev?

[adoxa]

Adoxa, what's your preference for to test this? Shall I just check the changes into Crid-dev?

Yes please, I can just pull from that. Can't say when I'll test it though, if not late tonight should be tomorrow.

[prl]

Adoxa, what's your preference for to test this? Shall I just check the changes into Crid-dev?

Yes please, I can just pull from that. Can't say when I'll test it though, if not late tonight should be tomorrow.

That's fine. I'm in no rush. I've got plenty of other stuff on my plate

[prl]

Adoxa, what's your preference for to test this? Shall I just check the changes into Crid-dev?

Yes please, I can just pull from that. Can't say when I'll test it though, if not late tonight should be tomorrow.

That's fine. I'm in no rush. I've got plenty of other stuff on my plate

Done.

[adoxa]

It worked: [eDVBScan] NIT TS da <crid://seven.net.au>. Just a minor thing: add the da case along with the "later" private case, as descr<73> is now processed.

[prl]

It worked: [eDVBScan] NIT TS da <crid://seven.net.au>.

Great to hear.

Just a minor thing: add the da case along with the "later" private case, as descr<73> is now processed.

I don't follow what you're suggesting. The two added case DEFAULT_AUTHORITY_DESCRIPTOR instances extract the da from two different places in the NIT and do two slightly different things with them (one is the network default and the other is the transport stream default).

[adoxa]

Code: Select all

					case DEFAULT_AUTHORITY_DESCRIPTOR:
					case PRIVATE_DATA_SPECIFIER_DESCRIPTOR:
					{
						// later, when we have the namespace
						break;
					}
					default:
						SCAN_eDebug("[eDVBScan] descr<%x>", (*desc)->getTag());
						break;

Add the first line to prevent the debug string.

[prl]

Ah. Good idea.

[IanSav]

Hi,

I finally had a chance to install the CRID code and modify OverlayHD to suit. The only broadcaster showing any CRIDs for me is the Nine Network. All the others are CRID free zones. Is that expected for Melbourne?

Regards,
Ian.

[prl]

Hi,

I finally had a chance to install the CRID code and modify OverlayHD to suit. The only broadcaster showing any CRIDs for me is the Nine Network. All the others are CRID free zones. Is that expected for Melbourne?

Regards,
Ian.

Did you do this?

After installing, you need to rescan, otherwise the CRIDs won't have their correct form on most channels. Part of the scan process needed for getting correct CRID forms on Seven Melbourne are untested, and the scan could crash if there's a bug in that untested code. The conditions for testing it don't exist in Canberra broadcasts.
...
Once the scan completes, the EPG needs to be cleared and refilled. A simple way to clear it is to do MENU>IceTV>Enable IceTV, MENU>IceTV>Disable IceTV.

Then simply step through viewing a channel from each broadcaster, staying on each channel for long enough for the EPG for the broadcaster to fill, about a minute or so.

Then CRID data should be visible in the modified EPG and media selection screens as noted above.

The CRIDs are in the EPG but won't be loaded into the EPG until the old EPG data without them has been replaced by new EPG data that now contains them.

[IanSav]

Hi Prl,

I missed the IceTV ON/OFF step. Doing that now.

Thanks.

Regards,
Ian.

[prl]

Updated alpha with CRID extraction.

The new version includes the code to fetch the CRID default authority from the Network Information Table (NTI) as well as from the Service Description Table (SDT). This helps get CRIDs in the correct form from Seven in some locations.

I've also added CRID display to the Channel selection screen, and given the same CRID displays to the Full-Metal-Wizard skin as easy-skin-aus-hd.

The installation instructions are the same as for the first version, with just a small change to the names of the ZIP files. You must uninstall the first version of the patch with the first version's uninstaller.sh script before installing the new version.

You still need to rescan, clear the EPG and reload it as in the installation instructions for the first version.

The list of files printed when the patch is installed has changed from the first version:

Code: Select all

root@beyonwizu4:~# find /usr/bin /usr/share/enigma2 /usr/lib/enigma2 -name \*.bak
/usr/bin/enigma2.bak
/usr/share/enigma2/Full-Metal-Wizard/skin_epg.xml.bak
/usr/share/enigma2/Full-Metal-Wizard/skin_videos.xml.bak
/usr/share/enigma2/Full-Metal-Wizard/skin.xml.bak
/usr/share/enigma2/easy-skin-aus-hd/skin_epg.xml.bak
/usr/share/enigma2/easy-skin-aus-hd/skin_videos.xml.bak
/usr/share/enigma2/easy-skin-aus-hd/skin.xml.bak
/usr/lib/enigma2/python/Components/Converter/EventName.pyo.bak
/usr/lib/enigma2/python/enigma.pyo.bak
root@beyonwizu4:~#

[Grumpy_Geoff]

Updated alpha with CRID extraction.
...

20180809 has dropped - will the new alpha #2 be compatible?

[prl]

Updated alpha with CRID extraction.
...

20180809 has dropped - will the new alpha #2 be compatible?

I haven't tested it yet, but it should be.

Edit: works OK on my test U4.

[Grumpy_Geoff]

...Edit: works OK on my test U4.

Right-o.

[IanSav]

Hi Prl,

I never got to do the IceTV switch, EPGRefresh ran and all the data updated correctly!

Did the skins or converter change in this latest update? If not, I can shortcut the update into my test system.

Regards,
Ian.

[Grumpy_Geoff]

Updated alpha with CRID extraction.

The new version includes the code to fetch the CRID default authority from the Network Information Table (NTI) as well as from the Service Description Table (SDT). This helps get CRIDs in the correct form from Seven in some locations.

The eDVBScan results are attached.
The Seven Network is still listing with 'missing_authority' -

Code: Select all

[Event] crid  1013:0506:0560  7 Perth             10.08, 09:00  crid://missing_authority/veKtvMeH                  crid://missing_authority/veKtvMeHltaPmtmO          The Morning Show

I haven't bothered attaching the event data as I don't think it changed.

[prl]

It's found the default authority for Seven, but it doesn't seem to have got through to the EPG. Did you clear and refill the EPG after doing the scan? Otherwise the old default authority assignments get used.

If (or when) you have reloaded the EPG and you're still getting "missing_authority" for Seven, could you post /etc/enigma2/lamedb?

Edit: Actually, now that I've gone back to the code, there shouldn't be any need to reload the EPG for the "missing_authority" strings to be fixed once you've done a scan.

[Grumpy_Geoff]

...If (or when) you have reloaded the EPG and you're still getting "missing_authority" for Seven, could you post /etc/enigma2/lamedb?

Yep, I cleared and reloaded the EPG.

Here's lamedb5. I know you said the original, but this one's a bit smaller - if you actually want lamedb then holler and I'll attach it.

Code: Select all

root@beyonwizu4:/etc/enigma2# cat lamedb5
eDVB services /5/
# Transponders: t:dvb_namespace:transport_stream_id:original_network_id,FEPARMS
#     DVBS  FEPARMS:   s:frequency:symbol_rate:polarisation:fec:orbital_position:inversion:flags
#     DVBS2 FEPARMS:   s:frequency:symbol_rate:polarisation:fec:orbital_position:inversion:flags:system:modulation:rolloff:pilot[,MIS/PLS:is_id:pls_code:pls_mode]
#     DVBT  FEPARMS:   t:frequency:bandwidth:code_rate_HP:code_rate_LP:modulation:transmission_mode:guard_interval:hierarchy:inversion:flags:system:plp_id
#     DVBC  FEPARMS:   c:frequency:symbol_rate:inversion:modulation:fec_inner:flags:system
#     ATSC  FEPARMS:   a:frequency:inversion:modulation:flags:system
# Services    : s:service_id:dvb_namespace:transport_stream_id:original_network_id:service_type:service_number:source_id,"service_name"[,p:provider_name][,c:cached_pid]*[,C:cached_capid]*[,f:flags]
t:eeee0000:0460:1012,t:191500000:1:5:5:3:2:4:4:2:0:0:0
t:eeee0000:0506:1013,t:177500000:1:5:5:3:2:4:4:2:0:0:0
t:eeee0000:0607:1014,t:219500000:1:5:5:3:2:4:4:2:0:0:0
t:eeee0000:0261:3201,t:226500000:1:5:5:3:2:4:4:2:0:0:0
t:eeee0000:0320:3202,t:184500000:1:5:5:3:2:4:4:2:0:0:0
t:eeee0000:0e00:323e,t:557500000:1:5:5:3:2:4:4:2:0:0:0
s:0e01:eeee0000:0e00:323e:1:0:0,"West TV",p:West TV Perth,a:crid%3a//perth.wtv.community.au
s:0321:eeee0000:0320:3202:1:0:0,"SBS ONE",p:SBS
s:0322:eeee0000:0320:3202:1:0:0,"SBS VICELAND",p:SBS
s:0323:eeee0000:0320:3202:1:0:0,"Food Network",p:SBS
s:0324:eeee0000:0320:3202:1:0:0,"NITV",p:SBS
s:0560:eeee0000:0506:1013:1:0:0,"7 Perth",p:Seven Network,a:crid%3a//seven.net.au
s:0461:eeee0000:0460:1012:1:0:0,"Channel 9 Perth",p:Nine Network Australia,a:crid%3a//nine.com.au,A:3200
s:0561:eeee0000:0506:1013:1:0:0,"7 Perth",p:Seven Network,a:crid%3a//seven.net.au
s:0562:eeee0000:0506:1013:1:0:0,"7TWO Perth",p:Seven Network,a:crid%3a//seven.net.au
s:0463:eeee0000:0460:1012:1:0:0,"9Go!",p:Nine Network Australia,a:crid%3a//nine.com.au,A:3200
s:0563:eeee0000:0506:1013:1:0:0,"7mate Perth",p:Seven Network,a:crid%3a//seven.net.au
s:0464:eeee0000:0460:1012:1:0:0,"9Life",p:Nine Network Australia,a:crid%3a//nine.com.au,A:3200
s:0465:eeee0000:0460:1012:1:0:0,"Extra",p:Nine Network Australia,a:crid%3a//nine.com.au,A:3200
s:0565:eeee0000:0506:1013:1:0:0,"7flix Perth",p:Seven Network,a:crid%3a//seven.net.au
s:0466:eeee0000:0460:1012:1:0:0,"Channel 9 Perth",p:Nine Network Australia,a:crid%3a//nine.com.au,A:3200
s:0467:eeee0000:0460:1012:1:0:0,"9Gem",p:Nine Network Australia,a:crid%3a//nine.com.au,A:3200
s:0468:eeee0000:0460:1012:1:0:0,"9Go!",p:Nine Network Australia,a:crid%3a//nine.com.au,A:3200
s:0681:eeee0000:0607:1014:1:0:0,"ONE",p:TEN Perth,a:crid%3a//perth.onehd.ten.au,A:3200
s:0685:eeee0000:0607:1014:1:0:0,"TEN DIGITAL",p:TEN Perth,a:crid%3a//perth.ten.ten.au,A:3200
s:0686:eeee0000:0607:1014:1:0:0,"TVSN",p:TEN Perth,a:crid%3a//perth.tvsn.ten.au,A:3200
s:0687:eeee0000:0607:1014:1:0:0,"ONE",p:TEN Perth,a:crid%3a//perth.onehd12.ten.au,A:3200
s:0688:eeee0000:0607:1014:1:0:0,"ELEVEN",p:TEN Perth,a:crid%3a//perth.11.ten.au,A:3200
s:0689:eeee0000:0607:1014:1:0:0,"SpreeTV",p:TEN Perth,a:crid%3a//perth.spree.ten.au,A:3200
s:02e0:eeee0000:0261:3201:1:0:0,"ABC NEWS",p:ABC,a:crid%3a//perthabcnews24.abc.net.au,A:3201
s:02e1:eeee0000:0261:3201:1:0:0,"ABC",p:ABC,a:crid%3a//perth2.abc.net.au,A:3201
s:02e2:eeee0000:0261:3201:1:0:0,"ABCComedy/Kids",p:ABC,a:crid%3a//perth22.abc.net.au,A:3201
s:02e3:eeee0000:0261:3201:1:0:0,"ABC",p:ABC,a:crid%3a//perth21.abc.net.au,A:3201
s:02e4:eeee0000:0261:3201:1:0:0,"ABC ME",p:ABC,a:crid%3a//perth23.abc.net.au,A:3201
s:032d:eeee0000:0320:3202:2:0:0,"SBS Arabic24",p:SBS
s:032e:eeee0000:0320:3202:2:0:0,"SBS Radio 1",p:SBS
s:032f:eeee0000:0320:3202:2:0:0,"SBS Radio 2",p:SBS
s:0330:eeee0000:0320:3202:2:0:0,"SBS Chill",p:SBS
s:0331:eeee0000:0320:3202:2:0:0,"SBS Radio 1",p:SBS
s:0332:eeee0000:0320:3202:2:0:0,"SBS Radio 2",p:SBS
s:0333:eeee0000:0320:3202:2:0:0,"SBS Radio 3",p:SBS
s:0334:eeee0000:0320:3202:2:0:0,"SBS Arabic24",p:SBS
s:0335:eeee0000:0320:3202:2:0:0,"SBS PopDesi",p:SBS
s:0336:eeee0000:0320:3202:2:0:0,"SBS Chill",p:SBS
s:0337:eeee0000:0320:3202:2:0:0,"SBS PopAsia",p:SBS
s:02e6:eeee0000:0261:3201:2:0:0,"Double J",p:ABC,A:3201
s:02e7:eeee0000:0261:3201:2:0:0,"ABC Jazz",p:ABC,A:3201
s:0568:eeee0000:0506:1013:22:0:0,"RACING.COM",p:Seven Network,a:crid%3a//seven.net.au
s:0325:eeee0000:0320:3202:25:0:0,"SBS ONE HD",p:SBS
s:0326:eeee0000:0320:3202:25:0:0,"SBS VICELAND HD",p:SBS
s:0462:eeee0000:0460:1012:25:0:0,"9HD Perth",p:Nine Network Australia,a:crid%3a//nine.com.au,A:3200
s:0564:eeee0000:0506:1013:25:0:0,"7HD Perth",p:Seven Network,a:crid%3a//seven.net.au
s:0684:eeee0000:0607:1014:25:0:0,"TEN HD",p:TEN Perth,a:crid%3a//perth.ten.ten.au,A:3200
s:02e5:eeee0000:0261:3201:25:0:0,"ABC HD",p:ABC,a:crid%3a//perth20.abc.net.au,A:3201
# done. 6 channels and 48 services
root@beyonwizu4:/etc/enigma2#

[adoxa]

That may have been my mistake - I only checked that it picked up the DA, not that it actually used it. I'll have another look later...

[prl]

...If (or when) you have reloaded the EPG and you're still getting "missing_authority" for Seven, could you post /etc/enigma2/lamedb?

Yep, I cleared and reloaded the EPG.

Here's lamedb5. I know you said the original, but this one's a bit smaller - if you actually want lamedb then holler and I'll attach it.

Lamedb5 is fine. I can't see any obvious reasons there why those default authority entries wouldn't work for Seven (but the others do).

I'll try copy/pasting one of your Seven DAs into my lamedb and see if that changes the DA that I see.

[prl]

That may have been my mistake - I only checked that it picked up the DA, not that it actually used it. I'll have another look later...

Thanks.

[prl]

Is anyone seeing any occurrences of [eDVBScan] SDT da <> in the debug logs? In the current code, that would explicitly clear a service's default authority, even if one had been scanned.

[Grumpy_Geoff]

Is anyone seeing any occurrences of [eDVBScan] SDT da <> in the debug logs? In the current code, that would explicitly clear a service's default authority, even if one had been scanned.

I won't be home for a few hours, I'll check then.

[Grumpy_Geoff]

Is anyone seeing any occurrences of [eDVBScan] SDT da <> in the debug logs? In the current code, that would explicitly clear a service's default authority, even if one had been scanned.

Yep, with two spaces (the code markup appears to show it as one). Not for the Seven Network though.

[prl]

Is anyone seeing any occurrences of [eDVBScan] SDT da <> in the debug logs? In the current code, that would explicitly clear a service's default authority, even if one had been scanned.

Yep, with two spaces (the code markup appears to show it as one). Not for the Seven Network though.

Three spaces rather than two? That's what's in the logs and the code. I don't know what I did with my copy/paste.

Anyway, what I was asking more about was whether there were any with empty default authorities. I.e. literally <> (rather than <crid://some.crid.authority>) in the matched line. I don't see any like that in the posted log. I'd also expect that if Seven's DAs were being clobbered in that way, they would disappear from the lamedb files in the next GUI restart (or system restart).

[adoxa]

I compiled the new code, ran a scan, the Seven CRID was found in the NIT, which was then used in events. I did add private data specifier 0x29, but I don't think that would matter (the specifier is stored, but not used).

It's really slow to change channels, at least from FAV, didn't try live.

[prl]

I compiled the new code, ran a scan, the Seven CRID was found in the NIT, which was then used in events.

Thanks for verifying. That's how I'd expect it to work. I'm really struggling to work out why Grumpy_Geoff's seeing something different.

Does the code in my second patch work correctly, too? I'm wondering whether something's messed up in that, or there is some incompatibility between the patch and 20180809.

I did add private data specifier 0x29, but I don't think that would matter (the specifier is stored, but not used).

The fact that some broadcasters use private data specifiers that aren't supposed to be used by Australian broadcasters makes them of limited use. I'm not even sure that they would be useful even if they were correct. Perhaps in proper code for international use if there were different national conventions about how the CRIDs were intended to be used. But then the Australian private data specifiers would need to be correct for that to be useful.

It's really slow to change channels, at least from FAV, didn't try live.

I haven't noticed that. There's only a small amount of additional logging in the CRID code other than what's printed when the EPG is opened or navigated through. The added processing cost should be tiny.

[adoxa]

I compiled the new code, ran a scan, the Seven CRID was found in the NIT, which was then used in events.

Thanks for verifying. That's how I'd expect it to work. I'm really struggling to work out why Grumpy_Geoff's seeing something different.

I spoke too soon. It worked the first time, but didn't work after restart, nor does it work after changing channel. It appears the service is created anew each time, so without the DA in the SDT it gets lost.

After a restart it read the DA from the DB, so when I started to change to 7 it picked it up:

Code: Select all

{18222}<692825.311> [Event] crid  1013:0930:0940  7 Rockhampton       11.08, 16:00  crid://seven.net.au/q25brMiM                       crid://seven.net.au/q25brMiMltaPmdiP               Better Homes And Gardens

but then once the channel change completed:

Code: Select all

{18222}<692826.289> [eDVBScan] no valid NIT
{18222}<692826.289> [eDVBScan] channel done!
{18222}<692826.289> [eDVBScan] tuner data from frontend: freq 599500000, ber 0xe0, snr 0xae13, pwr 0xffff
{18222}<692826.289> [eDVBScan] addKnownGoodChannel eeee0000:1013:0930, tparm.freq=599500000, tunerstate.freq=599500000
{18222}<692826.289> [eDVBScan] adding new channel
{18222}<692826.289> [eDVBScan] no channels left: 1 scanned, 0 unavailable, 1 database.

the DA's gone:

Code: Select all

{18222}<692839.418> [Event] crid  1013:0930:0940  7 Rockhampton       11.08, 16:00  crid://missing_authority/q25brMiM                  crid://missing_authority/q25brMiMltaPmdiP          Better Homes And Gardens

Not sure how to fix that, if it's even worth it.

It's really slow to change channels, at least from FAV, didn't try live.

I haven't noticed that. There's only a small amount of additional logging in the CRID code other than what's printed when the EPG is opened or navigated through. The added processing cost should be tiny.

I added extra debugging info to see what was going on, and it didn't happen. Go figure. It's in use for the rest of the day so additional testing will have to wait.

[prl]

I spoke too soon. It worked the first time, but didn't work after restart, nor does it work after changing channel. It appears the service is created anew each time, so without the DA in the SDT it gets lost.
...
Not sure how to fix that, if it's even worth it.

The problem is that there isn't anywhere sensible to hang the NIT first loop and NIT TS loop default authorities, so I just used them as fallbacks if there wasn't a DA in the SDT. But it looks like I may have to find a proper place to stash them after all, but I'm not sure where. There doesn't seem to be any data structure that holds Transport Stream data.

[adoxa]

A possible way to do it would be to always scan the NIT (ignore scanNetworkSearch and always use readyNIT), but I don't know how feasible that is.

[prl]

I think I have a simple fix for the problem.

[prl]

Updated alpha with CRID extraction. Tested in firmware 20180809.

The new version stops default authorities set in the NIT from being cleared when an SDT-only update is done, which doesn't re-scan the NIT. Also fixes a bug where indirect CRIDs were handled incorrectly. Indirect CRIDs still aren't handled, but if they are used, you get a warning printed to the debug log.

The installation instructions are the same as for the first version, with just a small change to the names of the ZIP files. You must uninstall the first version of the patch with any earlier version's uninstaller.sh script before installing the new version.

You still need to rescan, clear the EPG and reload it as in the installation instructions for the first version.

The list of files printed when the patch is installed has changed from the first version:

Code: Select all

root@beyonwizu4:~# find /usr/bin /usr/share/enigma2 /usr/lib/enigma2 -name \*.bak
/usr/bin/enigma2.bak
/usr/share/enigma2/Full-Metal-Wizard/skin_epg.xml.bak
/usr/share/enigma2/Full-Metal-Wizard/skin_videos.xml.bak
/usr/share/enigma2/Full-Metal-Wizard/skin.xml.bak
/usr/share/enigma2/easy-skin-aus-hd/skin_epg.xml.bak
/usr/share/enigma2/easy-skin-aus-hd/skin_videos.xml.bak
/usr/share/enigma2/easy-skin-aus-hd/skin.xml.bak
/usr/lib/enigma2/python/Components/Converter/EventName.pyo.bak
/usr/lib/enigma2/python/enigma.pyo.bak
root@beyonwizu4:~#

[prl]

A possible way to do it would be to always scan the NIT (ignore scanNetworkSearch and always use readyNIT), but I don't know how feasible that is.

In the current code, if you scan the NIT, that can add new channels to scan, if, for example, the NIT contains a Frequency list descriptor. If it does, the channel might be switched away from the one you're trying to change to, which isn't quite what you want. It could probably be coded around, but I thought it would be simpler to only update the default authority in the master service list if the service update contained a non-empty default authority.

[prl]

The updated source for the above alpha is now in the Crid-dev branch in my repository fork.

I've done a rebase of Crid-dev against the current repository master, so if you have a checkout of Crid-dev, you'll need to do whatever you need to do in git when someone goes re-writing history on you. Perhaps just a git pull of the branch?

[adoxa]

Yep, just pull and fix any conflicts.

[prl]

Yep, just pull and fix any conflicts.

There shouldn't be any.

[adoxa]

I made some minor changes of my own. I'm in the process of making major changes. Stripping it down to only what I need for what I want.

[Grumpy_Geoff]

Updated alpha with CRID extraction. Tested in firmware 20180809.

The new version stops default authorities set in the NIT from being cleared when an SDT-only update is done, which doesn't re-scan the NIT. Also fixes a bug where indirect CRIDs were handled incorrectly. Indirect CRIDs still aren't handled, but if they are used, you get a warning printed to the debug log.
...

Picked up and retained the Seven Network CRIDS.
Same as with my previous event data results, it was sorted by ONID/TSID/SID, and then by date/time, with duplicates removed.

[prl]

I made some minor changes of my own. I'm in the process of making major changes. Stripping it down to only what I need for what I want.

If some of that are parts that I also want to strip down/out, then they may as well be stripped out of my code, too.

I intend removing all the lowercasing of parts of the CRIDs and instead put a case-insensitive operator=() into eCridData (and also methods to extract the components of the CRID).

[prl]

Updated alpha with CRID extraction. Tested in firmware 20180809.

The new version stops default authorities set in the NIT from being cleared when an SDT-only update is done, which doesn't re-scan the NIT. Also fixes a bug where indirect CRIDs were handled incorrectly. Indirect CRIDs still aren't handled, but if they are used, you get a warning printed to the debug log.
...

Picked up and retained the Seven Network CRIDS.

Great! Thanks.

[adoxa]

I intend removing all the lowercasing of parts of the CRIDs and instead put a case-insensitive operator=() into eCridData (and also methods to extract the components of the CRID).

I'm keeping the lowercase authority. eCridData is something I've stripped. I just have member strings for the authority (without scheme) and series/episode CRIDs (without authority). getCridData will return those as a tuple and the converter will translate them to what I want.

[IanSav]

Hi Adoxa,

If you are proposing that the C++ layer simply returns the raw CRID data and the converter can/will assemble the parts under Python / Converter control then I think this is a better way to implement the CRIDs.

Perhaps some CRID library calls can be created to make the CRID data manipulation within Enigma2 uniform.

Regards,
Ian.

[adoxa]

I think the CRID data, in itself, is essentially useless. As mentioned earlier, I'll extract the information I can, adding it to my Single EPG info and the EPG search results. I'll push the code, but don't intend to release it.

[IanSav]

Hi Adoxa,

I think the CRID data, in itself, is essentially useless.

I agree. The initial value in the CRID data is as a point of comparison between events for the purpose of trying to more reliably identify separate programs by a method other than the broadcast title (which often contains obfuscating data). Also to try and identify new or repeat episodes of an individual program.

I'll push the code, but don't intend to release it.

Understood. I think I am beginning to understand your development style.

Regards,
Ian.

[prl]

If you are proposing that the C++ layer simply returns the raw CRID data and the converter can/will assemble the parts under Python / Converter control then I think this is a better way to implement the CRIDs.

What would that be? Should it, for example, include returning the Content Identifier Table so that CRIDs with their location specified as "Carried in Content Identifier Table" can be constructed? Tables of the network-level and transport stream-level and sevice-level default authorities for abbreviated CRIDs?

The current implementation of the Python interface simply returns a list of tuples representing eCridData structures and containing fully-specified CRIDs for an event as a list of text strings. I'm not sure whether there's any real need for the CRID components to be displayed. I'm not even convinced there's a need for a Converter for CRIDs at all. If the Python code wants to split the CRID into its logical component parts, there's always:

Code: Select all

>>> import urlparse
>>> urlparse.urlsplit("crid://canberra.nitv.sbs.au/211351#IM")
SplitResult(scheme='crid', netloc='canberra.nitv.sbs.au', path='/211351', query='', fragment='IM')
>>> 

The Crid-dev code has simple examples of how to use the interface in Components.Converter.EventName.