164 replies to this topic

[WanWizard]

If someone can tell me exactly what...

[doglover]

Littlesat should have all the info.  (he wrote it)

But it is the plugin.py file which is attached to post #60 in this thread.

 

Willy

[WanWizard]

I've pinged him, but I guess busy at work.

 

edit: ok, that is the version I've removed the syntax error from. I'll have a look.

[WanWizard]

Done.

[littlesat]

Thanks... will it now also come in release?

[Lost in Space]

Erst wenn ALLE try:/except: bereinigt sind

 

Only after cleanup of ALL try:/except:

Edited by gutemine, 22 June 2019 - 12:25.

[Huevos]

Which repo is the plugin on?

[littlesat]

E2openplugins?

Edited by littlesat, 22 June 2019 - 22:40.

[Abu Baniaz]

PLI uses this repository

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

 

Commit for this change was here

https://github.com/O...4b611f0008da72a

Edited by Abu Baniaz, 23 June 2019 - 00:11.

[Huevos]

No need to do that.. in post #39 I already fixed that - as I also discovered it...

Better test it and when issues are discovered fix it..

 

I think string match here is more sufficient. No need to make it extra complex by converting the stuff to e.g. a list of integers and then compare lists- this is more complicated... The service references come as string with hexadecimal characters and : as seperator. We can consider to remove the ":".join(of course and then compare list of strings).

 

This is just an example how we can work together!

1:0:02:1292:07EA:2:011A0000:0:0:0:

Reason I said convert to numbers was not for efficiency. Current commit does not work where there are leading zeros. Nor does it handle namespace subnet.

 

In my opinion it is more important that it works properly than a few extra seconds in run time.

[littlesat]

Why should that not work? You compare string with string? Explain me more about the cullpit. Maybe something else should be changed. How did you get these leiding zero’s in there? They are muda (not needed) and then you have on one pace them and on tbr other side of the conparison not. Converting to integer takes time in a long list so it is preferable to solve it at the source.
Previously you should also had this is as we also had string comparing. So actually you also describe a different issue. Maybe when we read the bouquets we should remove them? Or in the xml download formatring or so we should remove them. First please investigate where it does come from because on more places in e2 where references are compared this will go wrong.
I prefer to solve it at the source and not work-a-round somewhere ‘later’.

Edited by littlesat, 23 June 2019 - 07:52.

[doglover]

Service refs with leading zero's, yes they could be a problem.

 

1. All the enigma2 stuff do not produce service refs with leading zero's

2. The fastscan's also do not produce them.

3. In constructing the channels file for EPGimport, I was very aware of this and avoid them.  Although I cannot guaranty that none exist.  But if it exist it should be changed and not programmed for.

 

Where they come from:

 

From people using all kinds of software, and manually put these into bouquets.

According to my knowledge Dreamset and Dreamboxedit do not use these service refs with leading zero's.

 

Although they could be a problem.  However the problem is created by people doing manual stuff.
And if they run into problems with that, so be it.  You cannot program for every mistake somebody makes.

Edited by doglover, 23 June 2019 - 08:45.

[LraiZer]

I prefer to solve it at the source and not work-a-round somewhere ‘later’.

They were only introduced last night during a larger patch commit, I have now removed the leading zeros at the source.

[littlesat]

I still don’t understand where they did come from...

[Huevos]

Littlesat, the reason this is happening is because you insist on using a string comparison to compare numbers. Leading zero and upper/lower case are all vallid ways to write a hex value.

 

Also, because you are not comparing numbers this will also break when namespace subnet is enabled/disabled.

[littlesat]

I do not agree... string compare should work here. It was never there before... how do you get these ‘invalid’ not required leading zero’s? When the format is appropriate it should go right and it does not care at all...
As far I see it the format is without leading zero’s and not with...

Edited by littlesat, 23 June 2019 - 12:52.

[Huevos]

Leading zeros is a valid way to write hex numbers.

sRefToNum(sref):
	s, t, o, n = sref.toString().split(':')[3:7]
	return int(s, 16) << 48 | int(t, 16) << 32 | int(o, 16) << 16 | int(n, 16) >> 16

That will fix that problem and the namespace subnet problem.

[Lost in Space]

well, there was a reason why I used only split(":") and %s:%s ... in my code (not even a join), to preserve whatever garbage the code has to handle 

Edited by gutemine, 23 June 2019 - 14:02.

[littlesat]

Bases on the structured programming princilples I would say fix it at the source and make it consequent.... it is or leading zero’s or never.. I would say do it never... .and not try to fix it afterwards with %s tricks and convert it to integer...
I still don’t understand how you het the leading zero’s

Edited by littlesat, 23 June 2019 - 15:32.

[Huevos]

I don't know what you mean "fix" at source. These are valid values. Enigma does not see them as faulty values. There is nothing to "fix" elsewhere. The problem is in the plugin not comparing one hex value to another hex value properly.

 

Also, you are converting to upper case. If your argument is "fix" at source why is that also not fixed at source?

 

Internally in enigma c++ code these are dealt with as intergers so why should it be any different here?

 

Also you are still avoiding the issue of namespace subnet. In PLi that is a value the user can turn on and off from the menu.