No spurious epg entries today on build 5.004.009.005 (as expected). Good work Brian on tracking down that gremlin.
Zgemma H7S running OpenVIX 6.2, Darkmotor, Triax TD110 dish, Inverto Black Ultra dual lnb
LG 50UM7450 4K TV, Pioneer VSX-534 Atmos AVR , Panasonic UB820 region free 4K Bluray & a PS4.
bbbuk (15-03-21),Joe_90 (15-03-21),ronand (15-03-21),something_fishy (15-03-21)
If anyone is able to check this change to OpenTV EPG doesn't cause problems with other services (other than Sky UK) that use OpenTV EPG, that would be good.
I only have 28.2E to test on. so cant test on others, but here is some code ideas for your pondering
Interpretation of the data sent as a negative number, not a positive:
Code:// HACK: startSecond is detected as being from the previous // mjd date when the h:m:s is sent as greater than 1 day. // when this occurs, shifted two's complement has a negative // sign bit of a signed integer, and is not a positive number. int32_t startSecond = UINT16(&buffer[2]) << 1; // if h:m:s is sent as greater than 1 day in seconds, // first bit is a negative sign bit without padding. if (startSecond >= 86400) startSecond = 0xFFFE0000 | (startSecond & 0x1FFFF); startTimeBcd = ((startMjd - 40587) * 86400) + startSecond;
Andy_Hazza (28-03-21)
Is this tested code on 28.2E?
On another note, do you know about CRID on this transport stream? It would be a nice addition now that Simon is adding code in eEPGCache to process it.
https://github.com/OpenViX/enigma2/c...de9dcd0d44b0c0
bbbuk (28-03-21)
I dont see CRID, as far as i am aware it uses URI as defined:
Code:DVB original_network_id = 1 (0x1) DVB transport_stream_id = 10 (0xa) DVB service_id = 100 (0x64) DVB event_id = 1000 (0x3e8) Unique eventId string = 0001000a006403e8 DVB original_network_id = 1 (0x1) DVB transport_stream_id = 10 (0xa) DVB service_id = 100 (0x64) Unique serviceId string = "0001000a0064" event.serviceId = “serviceId_XYZ” event.uri = “tv://channel.serviceId_XYZ” event.eventID = eventId_XYZ event.seriesID = seriesLink (we can now proccess) event.episodeID = ??? (cant see this in the data) .sourceURL = event.uri
abu baniaz (28-03-21),bbbuk (28-03-21),Huevos (07-04-21)
Looking at OpenTV.nagra.com website, it references "seriesId" and "episodeId" as @LraiZer mentions...
Code:https://www.google.co.uk/search?q=site%3Ahttps%3A%2F%2Fopentv.nagra.com+seriesid&ei=G1VgYJ3tKouU8gLegLiABg&oq=site%3Ahttps%3A%2F%2Fopentv.nagra.com+seriesid&gs_lcp=Cgdnd3Mtd2l6EANQ1NYBWPDrAWD_7AFoAXAAeACAAewCiAGQEJIBBzQuMy40LjGYAQCgAQGqAQdnd3Mtd2l6wAEB&sclient=gws-wiz&ved=0ahUKEwjd5pfV3tLvAhULilwKHV4ADmAQ4dUDCA0&uact=5Code:https://docs.nagra.com/docs/os/524/series-linking-tutorial
I'm not entirely sure it's any clearer now that we have a comment by the original code.
Though it does kind of process things in a more logical order.
You could write 0xFFFE0000 as (-0x20000) though that shouldn't be necessary since int32_t should be guaranteed to be 32 bits.
Last edited by BrokenUnusableAccount; 30-03-21 at 01:46.
This must be documentation for some piece of software that takes in EPGs and things and produces the "secret" OpenTV data that Sky transmit.
I certainly can't find much information in there to help with interpreting the raw transmitted data (such as EPG).
Perhaps all the APIs and things described are how the TV companies transfer their EPG data, and so on, to Sky.
(but it does, as bbbuk pointed out, give you a good idea of what's in there somewhere)
Last edited by BrokenUnusableAccount; 30-03-21 at 01:54.
For a while after using the fix I think I wasn't seeing any holes in Gemporia Craft.
But now I am seeing holes, and also weird program ending times of the form xx:x7 just before the holes.
All other channels seem fine though.
I think the most liekly explanation is that Gemporia Craft are doing something weird.
Just thinking aloud
Gemporia Craft take the piss with 20 hour events = 72000 seconds duration. I guess you could start your debug by checking opentv code for uint16_t getDuration limits of 65535. Maybe there could also be an upper int18_t limit on a (startSecond+duration) that also triggers startSecond as a negative, even when startSecond is not greater than 1 day?
I've fixed the issue on OpenPLi where xx.x7 was seen for 20 hours (72000 seconds) events.
This was just a wrongly defined upper uint16_t limitation which subtracting 65535 from 72000 giving a false duration of 1 hour 47 minutes.
The issue of the holes now again on Gemporia Craft is that most events they send are sent correctly as GMT +0, but the ones that appear to be causing the issue are the new 20 hour events that are sent with an 1 hour too late startTime. I can only assume this is related to BST +1 change last week that they have not done correctly and so may only be a temporary issue once they realize their mistake?
Andy_Hazza (10-04-21),BrianG61UK (12-12-23)