Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £99! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £149! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

epgcache overlap problems

I'm copying this here as it is relevant to this thread.

Cache has no namespace or orbital position, just "uniqueEPGKey" from sid, tsid, and onid. If it matches between any type of T/S/C, then it rely's on the cache source type. These are priority checks performed before overwriting any current cached data.

Cache also has a type to check against where the epg came from, this is eg. if(source > type):
Code:
https://github.com/OpenPLi/enigma2/blob/3664db5f91860c05a80962ec9127f885daecd515/lib/dvb/epgcache.cpp#L40
The only epg with a lower write priority than opentv at the moment is EPG_IMPORT, but you may notice epg from this EPG_IMPORT sets a do not update from eit flag on its uniqueEPGKey's.
Code:
https://github.com/OpenPLi/enigma2/blob/103d129496df5b236473dc134d2554ba45456f9c/lib/dvb/epgcache.h#L249
Based on same uniqueEPGKey from different epg sources:

EIT schedule would overwrite FREESAT_SCHEDULE
FREESAT_SCHEDULE_OTHER would overwrite VIRGIN_SCHEDULE
OPENTV would not overwrite any of the above..

From here: https://www.world-of-satellite.com/...h-iEPG-and-VPS&p=508597&viewfull=1#post508597
 
So it turns out that previously epgcache OpenTV reader was using the event start time as the event_id. LraiZer has provided a patch to cure this which needs testing. https://github.com/OpenViX/enigma2/commit/0731baaaa16d7985cb42b003d3ec50dd5631b871

If you want a binary to use for testing I can provide an ARM version.

Just for my own clarification...

I've been following this thread for days and noticed that @gort was indicating that the event id number generated by epgrefresh/opentv reader was different than that generated by CrossEPG and that this was causing issues for the VPS plugin when it was checking now/next EIT data and couldn't seem to match that particular event id with the one stored in the timer entry. I had a look at the actual EIT data on various 28.2 transponders and found that the event id info for most channels was a simple incrementing numeric sequence like 182, 183,184 etc. The info is stored in the table as a hex value. When I checked a timer entry for the same programme, it seemed to be a different, apparently random value which didn't match. Lraizer's post indicated that the event id was being generated in the OpenTV reader though an AND function using the start time of the event, whereas CrossEPG was actually using the even id stored by the broadcaster in the table. Am I correct in this?

It would explain the effect where small changes in the start time resulted in "ghost entries" being presented in the EPG display as they had different event ids generated by the AND function.

I'm further assuming that your amendment to the EPGcache code should now result in consistent use of the broadcaster event id by CrossEPG and the Opentv reader (and probably the Freesat reader) so that the issue of ghost entries should be minimised or eliminated and that the VPS plugin should work also?
 
@fat-tony, I'm only concerned that our built-in reader works properly. I haven't explored what might be happening in Cross.

Tests using LraiZer's patch show corresponding event_id in timers created from both EIT and OpenTV data. All that is needed now is to see what happens when there is a change in the data.
 
Yes - thanks for the changes. I think what's now happening is that the event ID values are now the same in Cross and in the OpenTV reader. I would hazard a guess that slight schedule moves were causing the overlapping entries in the EPG display due to the event id values being generated "on the fly". It will be interesting to see what will happen on a schedule change now!
 
I do apologize, and I know this is a little off the topic but after installing OpenViX 5.4.005 on my GigaBlue UHD QUAD 4K I have noticed when the receiver is in standby and OpenTV download (28.2) has updated the EPG the bouquet always defaults to 'Last Scanned' when I first turn on receiver. Is their a way to stop this happening and set it to the last bouquet I was was using as it has always been before?
 
Last edited:
I do apologize, and I know this is a little off the topic but after installing OpenViX 5.4.005 on my GigaBlue UHD QUAD 4K I have noticed when the receiver is in standby and OpenTV download (28.2) has updated the EPG the bouquet always defaults to 'Last Scanned' when I first turn on receiver. Is their a way to stop this happening and set it to the last bouquet I was was using as it has always been before?
I can't reproduce this... but...

If you watch what is happening via OpenWebInterface you can see that the tuner is not released when the download completes.

https://github.com/OpenViX/enigma2/commit/75e530fa791db602499c8ccd511e04b06f3fc4e1

The above commit fixes that. Give it a try and see if it cures your problem.
 
Thanks Huevos for your reply,
I think that could be the issue as the front LCD display shows an active tuner on when in standby and nothing is recording. I am a complete novice using lynx. I know I can edit py files using Easy Python Decompiler, but how do you convert back to a py file to copy the file back over to the receiver? Thanks again.
 
You don't. You just take the py file from github, send it to your receiver, restart the receiver. Now the pyo on the box will be the latest version and you can delete the py.
 
Thanks Huevos for your reply,
I think that could be the issue as the front LCD display shows an active tuner on when in standby and nothing is recording. I am a complete novice using lynx. I know I can edit py files using Easy Python Decompiler, but how do you convert back to a py file to copy the file back over to the receiver? Thanks again.

https://www.world-of-satellite.com/...upgrading-to-5-0-016-AutoTimer-fails/page2#17

https://www.world-of-satellite.com/...upgrading-to-5-0-016-AutoTimer-fails/page2#16
 

OpenViX Feeds Status

Back
Top