epgcache overlap problems

[adm]

The first problem seen since i changed settings

Settings
epg_30Jan_1.jpg

01:35 to 2:45
Problem seen

epg_30Jan_2.jpg

epg_30Jan_3.jpg

epg_30Jan_4.jpg

The entry for "The Professionals" should be from 1:35 to 2:45 and not overwritten by Auto Mundial (which was the program before The Professionals AND on my other box that doesn't show the problem River Monsters is not present in the EPG.

Note: the box has been on continiously for approx 18 hours.

My other box is a Zgemma H9S with a single satelitte tuner, with opentvzapper disabled and with a repeating timer set to switch the box from deep standby to the IEPG channel each morning at 6:30am

the setting for ths box is

epg_30Jan_5.jpg

And the EPG is shown correctly for ITV4 at the same time as the above

epg_30Jan_6.jpg


I'm now going to delete the EPG cache and change a setting to see if the problem re-appers in the next day or so.

[adm]

After a bit of investigation I do believe the problem to be both EIT now/next and IEPG populating the same EPG data base.

If I disable all modes for getting data from IEPG, then delete the EPG cache the following setting will populate (or not) the (grid) EPG with now/next data

table.jpg

So, if both Enable EIT EPG and Enable OpenTV EPG are both configured to yes the (grid) EPG for Sky FTA will be populated with now/next data.

Now, if the IEPG channel is also selected then the (grid) EPG data will be updated from this second source, as well as now/next

You could argue that for SKY FTA the Enable EIT EPG option can be turned off. This would give IEPG as the single source of EPG data and/or any Internet download as the single source of data.

However, I want Enable EIT EPG to be on to get the over the air terrestrial EPG for Freeview!

People with only satellite tuners may never see the problem if EIT EPG is configured to be off BUT the question arises about having an up to date EPG for Sky FTA. If IEPG or a Internet download is only updated once a day or every 6 hours the problem I found the other day with 12 TV channels having incorrect or overwritten data may indicate that now/next is possibly more up to date with respect to program changes.

The show EIT now/next in info bar option only seems to make a difference to the information shown in the Info Bar. In some cases in the table above where now/next doesn’t populate the EPG cache the now/next information is correctly shown in the Info bar.

[Huevos]

The column of the table that explain what each yes/no means is missing.

[adm]

The column of the table that explain what each yes/no means is missing.

The first row in the table is the headings for each column, the next 8 rows show all the possible settings for the three configurable menu items.
The last column in the table is the result - the observation about now/next data appearing in the EPG cache.

It shows that in
menu -> setup -> EPG -> settings
that option " Show EIT now/next in infobar" is a don't care as it is not controlling what appers in the EPG cache, and seen in the grid EPG

Only the combination of the options "Enable EIT data" and "Enable OpenTV EPG" both being set to "Yes" result in now/next appering in the EPG cache.

"Enable EIT data" and "Enable OpenTV EPG" both being set to "Yes" is the setting I need for over the air EPG for both satellite (Sky FTA) and terrestrial (Freeview) population.

[Huevos]

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/c...ec50dd5631b871

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

[Huevos]

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):

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.

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/s...l=1#post508597

[Joe_90]

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/c...ec50dd5631b871

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?

[Huevos]

@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.

[Joe_90]

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!

[dntaylor]

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?

[Huevos]

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/c...1e04b06f3fc4e1

The above commit fixes that. Give it a try and see if it cures your problem.

[dntaylor]

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.

[Huevos]

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.

[adm]

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/s...fails/page2#17

https://www.world-of-satellite.com/s...fails/page2#16