164 replies to this topic

[doglover]

In the EPGimport  plug-in there is an option:  " only import EPG for channels in bouquets"

 

This option is causing problems.

f.i the channel NPO1 has a service ref when you scan 23.5E: 1:0:19:5225:C99:3:EB0000:0:0:0:

However when performing a fast scan of Canaal Digitaal, the service ref is:  1:0:1:5225:C99:3:EB0000:0:0:0:

 

In the rytec channels file this channels is denoted as: 

<!-- 23.5E --><channel id="Ned1.nl">1:0:19:5225:C99:3:EB0000:0:0:0:</channel><!-- NED 1 HD -->

 

So when you apply the setting " only import EPG for channels in bouquets"  this channels will have no EPG.

 

This is one example.  But there are countless channels which suffer from this.  The providers do not always denoted their channels with the correct  tranmission code.  (1= MPEG2, 16=SD,MPEG4, 19=HD,MPEG4)

 

Also the proplem exist with IPTV channels (legal ones) which need the 5002 code.

f.i.

 

#SERVICE 5002:0:1:1:0:32:0:0:0:0:http%3a//api.new.livestream.com/accounts/27755193/events/8452383/live.secure.m3u8:TV Limburg

 

I would appreciate it, if some-one with knowlegde of python could modify this option " only import EPG for channels in bouquets" to only compare part of the service ref.

This part: 5225:C99:3:EB0000  (SID:TID:NID:Namespace)

So skipping the first 3 values and the last 4 values.

 

Be warned that in the rytec.channels file, and bouquet list entries can exist like these:

 

#SERVICE 5002:0:1:1:0:32:0:0:0:0:http%3a//api.new.livestream.com/accounts/27755193/events/8452383/live.secure.m3u8:TV Limburg

 

<!-- IPTV --><channel id="TVL.be">4097:0:1:1:0:32:0:0:0:0:http%3a//example.com</channel><!-- TVL -->

 

Thanks in advance

 

Willy

 

PS: the comparison should be case independend

Edited by doglover, 18 June 2019 - 18:13.

[Abu Baniaz]

Virgin UK has this problem too. So a change would be appreciated.

Sent from my Moto G (5S) using Forum Fiend v1.3.3.

[Lost in Space]

EPGLoad Plugin doesn't have this Problem, because it uses already only this truncated Part of sref to check bouquets, because this Always annoyed me.

Edited by gutemine, 19 June 2019 - 07:51.

[littlesat]

Actually when comparing service references you should do something special here with the 3rd digit... Aswell 19 as 1 is right... Or arrange in the EPG that both are labeled. The 'denotion' is chaos and please be aware that the service reference was initially an Enigma invention.

 

I think it was better to simply always make the service reference 1 for video and 2 for radio (audio only). It totally does not help E2 to put here more details. To check if a channel is SD or HD etc... is also detected 'afterwards'.... so for me in E2 each 19 can be replaced by 1 etc...

 

E.g. 16 SD-MPEG-4 I rarely see...

Edited by littlesat, 19 June 2019 - 08:09.

[doglover]

@littlesat:

I share your objection against all this. 

 

However this is besides the point.  Reality is that all kinds of denotions are used, and not always in the correct way.

f.i. there are bouquets floating around which have all service refs in the bouquets in lower case.  This works.  But again it plays havoc when using the option "Import only EPG for channels in bouquets".

Also these bouquets have all TV channels identified as 1:0:1:...

 

If everyone would be using the conventions, we would not need all this.  But reality is different.

 

As for 16 (SD/MPEG4)

 

These are some examples scanned from 23.5E.  Plenty of 16 defined channels

#SERVICE 1:0:19:5221:C99:3:EB0000:0:0:0:
#SERVICE 1:0:19:5226:C99:3:EB0000:0:0:0:
#SERVICE 1:0:19:1B76:C88:3:EB0000:0:0:0:
#SERVICE 1:0:19:1B90:C88:3:EB0000:0:0:0:
#SERVICE 1:0:19:1B91:C88:3:EB0000:0:0:0:
#SERVICE 1:0:16:5286:C96:3:EB0000:0:0:0:
#SERVICE 1:0:16:5280:C96:3:EB0000:0:0:0:
#SERVICE 1:0:16:1B95:C88:3:EB0000:0:0:0:
#SERVICE 1:0:16:5282:C96:3:EB0000:0:0:0:
#SERVICE 1:0:19:5225:C99:3:EB0000:0:0:0:
#SERVICE 1:0:19:17C0:C82:3:EB0000:0:0:0:
#SERVICE 1:0:19:5230:C99:3:EB0000:0:0:0:
#SERVICE 1:0:19:1B6C:C88:3:EB0000:0:0:0:
#SERVICE 1:0:19:1B6F:C88:3:EB0000:0:0:0:
#SERVICE 1:0:19:1B7C:C88:3:EB0000:0:0:0:
#SERVICE 1:0:19:1B73:C88:3:EB0000:0:0:0:
#SERVICE 1:0:19:521C:C99:3:EB0000:0:0:0:
#SERVICE 1:0:19:17CA:C82:3:EB0000:0:0:0:
#SERVICE 1:0:19:522B:C99:3:EB0000:0:0:0:
#SERVICE 1:0:16:51D1:C96:3:EB0000:0:0:0:
#SERVICE 1:0:1:FE2:451:35:C00000:0:0:0:
#SERVICE 1:0:1:52E8:C96:3:EB0000:0:0:0:
#SERVICE 1:0:16:523F:C99:3:EB0000:0:0:0:
#SERVICE 1:0:16:51DA:C96:3:EB0000:0:0:0:
#SERVICE 1:0:1:51D5:C96:3:EB0000:0:0:0:
#SERVICE 1:0:16:178E:C82:3:EB0000:0:0:0:
#SERVICE 1:0:16:17EA:C82:3:EB0000:0:0:0:
#SERVICE 1:0:16:36F9:C8C:3:EB0000:0:0:0:
#SERVICE 1:0:16:36F8:C8C:3:EB0000:0:0:0:
#SERVICE 1:0:16:36F6:C8C:3:EB0000:0:0:0:
#SERVICE 1:0:16:17B3:C82:3:EB0000:0:0:0:
#SERVICE 1:0:1:439F:2CEC:13E:820000:0:0:0:
#SERVICE 1:0:1:1B03:3FE:1:C00000:0:0:0:
#SERVICE 1:0:1:52EA:C96:3:EB0000:0:0:0:
#SERVICE 1:0:19:306:C94:3:EB0000:0:0:0:
#SERVICE 1:0:19:51E5:C96:3:EB0000:0:0:0:
#SERVICE 1:0:16:17D1:C82:3:EB0000:0:0:0:
#SERVICE 1:0:1:52B0:C99:3:EB0000:0:0:0:
#SERVICE 1:0:19:36E6:C8C:3:EB0000:0:0:0:
#SERVICE 1:0:16:179D:C82:3:EB0000:0:0:0:
#SERVICE 1:0:19:17AF:C82:3:EB0000:0:0:0:
#SERVICE 1:0:1:1BFD:C88:3:EB0000:0:0:0:
#SERVICE 1:0:16:5278:C96:3:EB0000:0:0:0:
#SERVICE 1:0:16:5276:C96:3:EB0000:0:0:0:
#SERVICE 1:0:16:527C:C96:3:EB0000:0:0:0:
#SERVICE 1:0:1:522B:C99:3:EB0000:0:0:0:
#SERVICE 1:0:1:5230:C99:3:EB0000:0:0:0::NPO Zapp
#DESCRIPTION NPO Zapp
#SERVICE 1:0:1:17E9:C82:3:EB0000:0:0:0:
#SERVICE 1:0:16:17B1:C82:3:EB0000:0:0:0:
#SERVICE 1:0:1:36F7:C8C:3:EB0000:0:0:0:
#SERVICE 1:0:16:36F7:C8C:3:EB0000:0:0:0:
#SERVICE 1:0:16:36FA:C8C:3:EB0000:0:0:0:
#SERVICE 1:0:16:1793:C82:3:EB0000:0:0:0:
#SERVICE 1:0:1:6FF7:42A:1:C00000:0:0:0:
#SERVICE 1:0:1:141B:C85:3:EB0000:0:0:0:

Edited by doglover, 19 June 2019 - 08:48.

[littlesat]

The 16, 19 etc. is not consequently done by the providers...
 

e.g. 

 

#SERVICE 1:0:1:5230:C99:3:EB0000:0:0:0::NPO Zapp
#DESCRIPTION NPO Zapp

 

I'm 100% convinced this is a SD-MPEG4 service...

 

For E2 it actually really doesn't care... when we simplify it and make 1 video 2 audio 3 data I prefer it... Actually in the 'background' E2 is doing nothing with that data and the rest in the service reference is sufficiently unique.

So for me at any place when a service is added to E2 the 19, 16 etc could be replaced by a 1. Please be aware that a plugin like e.g. ABW also need to be adapted that way as it is working around the service creater of E2 itself.

 

Please be aware that this is not intend to the solution, but more a thing to discuss in general...

 

In short that 3rd digit in the service reference can be ignored to compare service references as it is currently implemented in E2. At least doing this for EPG import would be 'nice'.

Edited by littlesat, 19 June 2019 - 09:23.

[Lost in Space]

Your great ideas will cause nothing but Chaos. doglover's Suggestion ist simple and works, because I implemented it this way in EPGLoad Plugin months ago.

Edited by gutemine, 19 June 2019 - 12:26.

[Abu Baniaz]

@gutemine, where is the commit where you did this please?

[Lost in Space]

EPGLoad Plugin isn't comitted in a git and it is also not (yet) GPL licensed ...

[Abu Baniaz]

OK. would you mind making the required change to EPGimport please?

 

https://github.com/O...sions-epgimport

[Lost in Space]

No, I will Not Touch the EPGImport Code anymore, because there were multiple good reasons why I created my own Plugin.

Edited by gutemine, 19 June 2019 - 13:23.

[WanWizard]

What do you mean by "anymore"? I can't remember the last time you contributed something to open source.

 

As usual you're full of "yours sucks" and "my stuff is better than yours", but actually helping out instead of suggesting you are superior to everyone else is appearently impossible for you.

[littlesat]

Your great ideas will cause nothing but Chaos.

 

Why should it create chaos. That value being 19, 16 or so has in fact no added value at all, so it can be simply ignored.

Where are your sources of the EPGLoad plugin? Without sources it has no added value at all... 

Edited by littlesat, 19 June 2019 - 14:07.

[Lost in Space]

My EPGLoad Plugin includes all the Python sources.

Edited by gutemine, 19 June 2019 - 14:05.

[littlesat]

Regarding our importer..

 

https://github.com/O...mport/plugin.py

 

Line 184 -> if refstr not in BouquetChannelListList:

 

When this check could be replaced by a function that ignores that 3rd value then the issue this thread did start with might be solved (it seems without the bouquet limited it did work).

Edited by littlesat, 19 June 2019 - 14:08.

[littlesat]

My EPGLoad Plugin includes all the Python sources. 

That is one of the first times you doing this... But don't you have a github or so somewhere?

[Abu Baniaz]

Does 179 need editing to only consider the bits that Doglover mentioned instead of the whole reference?

https://github.com/O.../plugin.py#L179

Edited by Abu Baniaz, 19 June 2019 - 14:22.

[WanWizard]

Sure 178/179 need editing to only consider the bits that Doglover mentioned?

 

If will probably be simpler and faster to leave that as-is, but change the ref being checked, and the contents of the list to only the sections required. Otherwise the check has to be rewritten to a slow iteration over the list.

 

I think we also need a bit more explaination about what Doglover means with his warning about streams.  

[Abu Baniaz]

We are checking the whole reference, just trim it. We do something similar in picon code already anyway.

 

https://github.com/O...icon.py#L64:L98

[WanWizard]

Whatever manipulation is needed. My point was that

if refstr not in BouquetChannelListList:

will require the entries in the list are converted (trimmed or whatever) in the same way.

 

If you don't do that, but rewrite this line, you need to itterate over the list, and convert list entries on the fly, which will severely impact the processing speed.