EPG Refresh, iEPG and VPS

[birdman]

If someone on here suggests something I don't think is what I want I will now call it a crazy idea instead of trying to explain why it's not what I want.

Whereas I was presuming that had all been gone over before and there was no need to repeat it here.

[BrokenUnusableAccount]

Whereas I was presuming that had all been gone over before and there was no need to repeat it here.

Says mr it wouldn't help me the way I use it so I'm not going to listen at all, just keep saying over and over and over that it wouldn't help.

[abu baniaz]

The eit is the same, that's what's being discussed.

Sent from my IN2013 using Tapatalk

Please describe exactly what you mean

EIT Now/next EPG data
EIT EPG data upto 7 days?
EIT number?

[goRt]

Please describe exactly what you mean

EIT Now/next EPG data
EIT EPG data upto 7 days?
EIT number?

In the context of your reply, I was replying to a person who'd posted SD and HD data for a programme from timer.xml and stated that they were different - which is correct as they are different programmes, whereas the HD stream of a programme on DVB-T and DVB-S in the same D has the same eit.

Here's another example for tomorrow evening, it's also noteworthy that when using crossepg one does not require opentv to be active in epg settings as crossepg handles the harvesting within its own code (eit of 186 on C4HD both DVB-S and DVB-T):

<timer begin="1611687600" end="1611691320" serviceref="1:0:19:52D0:814:2:11A0000:0:0:0:" repeated="0" rename_repeat="1" name="Channel 4 News" description="Channel 4&apos;s flagship news programme. Including the weather." afterevent="auto" eit="186" tags="AutoTimer Channel_4_News" justplay="0" always_zap="0" pipzap="0" conflict_detection="1" descramble="1" record_ecm="0" isAutoTimer="1">
<log code="500" time="1611081419">[AutoTimer] Try to add new timer based on AutoTimer Channel 4 News.</log>
<log code="509" time="1611081419">[AutoTimer] Timer start on: Tue Jan 26 19:00:00 2021</log>
<log code="15" time="1611081419">record time changed, start prepare is now: Tue Jan 26 18:59:41 2021</log>
<log code="15" time="1611082092">record time changed, start prepare is now: Tue Jan 26 18:59:40 2021</log>
</timer>
<timer begin="1611687601" end="1611691320" serviceref="1:0:19:4500:4083:233A:EEEE0000:0:0:0:" repeated="0" rename_repeat="1" name="Channel 4 News" description="Channel 4&apos;s flagship news programme. Including the weather.  [S]" afterevent="auto" eit="186" justplay="0" always_zap="0" pipzap="0" conflict_detection="1" descramble="1" record_ecm="0" isAutoTimer="0">
<log code="15" time="1611559777">record time changed, start prepare is now: Tue Jan 26 18:59:41 2021</log>
</timer>

[abu baniaz]

So when you say "EIT", you mean "EIT number"?

CrossEPG does nothing with Freeview/Terrestrial EPG.

[goRt]

So when you say "EIT", you mean "EIT number"?

CrossEPG does nothing with Freeview/Terrestrial EPG.

That's correct, I continue to refer to the programme eit - that within the epg stream and the now/next data, I await a comment on why that harvested from iEPG-1 doesn't match that from now/next, crossepg or DVB-T use of epgrefresh.
I'm well aware that crossepg only reads the 28.2e data, the discussion relates to a programme of a given density having the same eit identifier whichever platform it is broadcast on i.e. DVB-T or DVB-S.

[abu baniaz]

You need to be specific to avoid confusion. The "EIT number" is new to me, I appreciate that it has "always been there", but it isn't used by Enigma2 for recording. We don't have the CRID system

I am guessing that the EIT number is designed for systems that do not have multiple reception facilities. e.g 28.2 and Freeview. Otherwise if you scheduled a recording on Terrestrial and satellite, they would be identified as the same event, when they are different services.

The OpenTV EPG reader code was added by LraiZer not too long ago. Not sure when he will be back here, but someone else mentioned radio EPG not being absorbed.

[ccs]

In the context of your reply, I was replying to a person who'd posted SD and HD data for a programme from timer.xml and stated that they were different - which is correct as they are different programmes, whereas the HD stream of a programme on DVB-T and DVB-S in the same D has the same eit.

I posted SD and HD data to see if there was a match with the timers you'd referred to as nowhere had you said whether yours were HD or SD.

I hadn't a clue what your service references referred to.

[goRt]

You need to be specific to avoid confusion. The "EIT number" is new to me, I appreciate that it has "always been there", but it isn't used by Enigma2 for recording. We don't have the CRID system

I am guessing that the EIT number is designed for systems that do not have multiple reception facilities. e.g 28.2 and Freeview. Otherwise if you scheduled a recording on Terrestrial and satellite, they would be identified as the same event, when they are different services.

The OpenTV EPG reader code was added by LraiZer not too long ago. Not sure when he will be back here, but someone else mentioned radio EPG not being absorbed.

Abu, everything you state is already in this thread, when something is quoted that should be read to provide context rather than simply reading my response and asking what I refer to.

There's no need to guess why eit number exists, as I've stated only this morning, it's there to identify a programme (not event)

So it's entirely possible that the OpenTV EPG reader code is incorrectly populating the eit data. I only became aware of that feature when crossepg was removed and we were instructed to use epgrefresh (which I note has now been removed from the builds and requires manual installation *even if someone was using it prior to the .005 release*

Hopefully @LraiZer will join this discussion

[ronand]

Crossepg has not been removed - it is just not installed by default. You are free to install it yourself. For most people just using 28e using a channel zapper/epg reader system is simpler. There is no "one size fits all" method and those with motorized systems will use a combination of epg harvesters.

[goRt]

Crossepg has not been removed - it is just not installed by default. You are free to install it yourself. For most people just using 28e using a channel zapper/epg reader system is simpler. There is no "one size fits all" method and those with motorized systems will use a combination of epg harvesters.

No one's disputing that, I'm highlighting an issue that's all.

We now seem to be settling on the issue is within OpenTV

[ronand]

Be grateful we can get anything at all with the opentv reader - despite its name its actually not an "open" system.

Is it really that important to have this EIT data?? Most people seem to manage quite recording quite well.

[goRt]

Be grateful we can get anything at all with the opentv reader - despite its name its actually not an "open" system.

Is it really that important to have this EIT data?? Most people seem to manage quite recording quite well.

What's wrong with reporting a bug and asking for it to be remediated, surely that will benefit all (even those no experiencing the bug) and improve user experience going forward?

[LraiZer]

For OpenTV and some other built-in E2 readers, a raw data packet is constructed first before it is sent to be read. The eEPGCache::submitEventData() function performs a Bitwise AND operator calculation on the programs start time to set an eventid here in this preprocessing stage. The actual eventid harvested in the opentv reader code was not used here, as at the time there was no existing coding in the eEPGCache::submitEventData() function to pass eventid data.

config.recording.margin_before=3

<timer begin="1611601020" eit="5424">

eEPGCache::submitEventData() "example for opentv eit number"

1611601020 + (3*60sec) = 1611601200
1611601200 = 0x600F1530
0x600F1530 & 0xFFFF = 0x1530
0x1530 = 5424

As far as i am aware, crossepg loads without any preprocessing in E2 as raw data, so probably has the eventid in its raw data that is also read by the opentv built-in reader code but not used.

Another thing to note for any title string comparisons is the later OpenTV patches that added a hack to concatenate title... and ...summary data when they are detected as truncated. You can briefly observe this title string difference to EIT now/next data when the infobar display appears as you zap to concatenated titles. I think this feature could have been an optional.

https://github.com/OpenViX/enigma2/commit/9259e4d30402cad5c7b04ba71501332bbec78373#diff-b15024bd2b4ea380025955f8d690ba180059716f8f64bd2366de9dcd0d44b0c0

[goRt]

For OpenTV and some other built-in E2 readers, a raw data packet is constructed first before it is sent to be read. The eEPGCache::submitEventData() function performs a Bitwise AND operator calculation on the programs start time to set an eventid here in this preprocessing stage. The actual eventid harvested in the opentv reader code was not used here, as at the time there was no existing coding in the eEPGCache::submitEventData() function to pass eventid data.

config.recording.margin_before=3

<timer begin="1611601020" eit="5424">

eEPGCache::submitEventData() "example for opentv eit number"

1611601020 + (3*60sec) = 1611601200
1611601200 = 0x600F1530
0x600F1530 & 0xFFFF = 0x1530
0x1530 = 5424

As far as i am aware, crossepg loads without any preprocessing in E2 as raw data, so probably has the eventid in its raw data that is also read by the opentv built-in reader code but not used.

Another thing to note for any title string comparisons is the later OpenTV patches that added a hack to concatenate title... and ...summary data when they are detected as truncated. You can briefly observe this title string difference to EIT now/next data when the infobar display appears as you zap to concatenated titles. I think this feature could have been an optional.

https://github.com/OpenViX/enigma2/commit/9259e4d30402cad5c7b04ba71501332bbec78373#diff-b15024bd2b4ea380025955f8d690ba180059716f8f64bd2366de9dcd0d44b0c0

Thanks for taking the time to reply