This is what I was trying to get at earlier by saying that I don't notice these issues with Sky UK when using CrossEPG to grab EPG data! Have previously seen when I switched from CrossEPG to EPGRefresh/OpenTV.
It's also looks like CrossEPG does some work-around maybe with epg cache as it creates a new instance of EPG cache.
Doesn't this, at least for Sky UK, potentially mean that broadcast data is correct and yes there could be multiple issues and EPG cache being other issue?
Last edited by bbbuk; 14-03-21 at 13:12.
bbbuk (15-03-21)
Let me put that another way just in case some people still can't see it.
I think that startSecond (including the 0 LSB that's been added) is the bottom 17 bits from a larger (say 32 bit) signed integer that is only allowed to take on even values between -44672 and 86398.
Which seems and odd thing to do.
Would you ever consider that I'm writing this at -11:00 on Monday?
It sounds more like and artefact of the way they process service suppliers data rather than being intentional. It's noticeable that it only seems to affect programmes which wrap between days at midnight. That's midnight UK, so for many Western European countries these do not span two days - they are completely within the second day.
But since the OpenTV spec isn't published we can only ever speculate, and just have work with whatever is sent out.
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD
While we have developer types in here can anyone tell me what's going on in opentv.cpp a few lines underneath where I was working?
WT* is it necessary to allocate memory to make a copy before working out the crc and then release it afterwards?Code:uint8_t *otvt = new uint8_t[titleLength]; memcpy(otvt, buffer + 9, titleLength); crc32 = opentv_crc(otvt, titleLength); delete [] otvt;
If you look at the definition of opentv_crc further up it can't modify it's input data.
It doesn't make any sense to me.
Wasn't this also used and deleted somewhere instead in the early code creation during debug testing and then that code was removed and just a quick temporary delete added back here and then all this was forgot about?
Looks like you've got something else you'll have to fix
I'm ready to test when software is available
GB Quad Plus, Mut@nt HD51, AX HD61, 80cm dish and Supreme Dark motor. Sony STR-DN 1060, Sony UHP-H1 Bluray, Odroid N2+ (CoreElec), Monitor Audio Bronze 5.1 speakers
These erroneous values? e3 e0
They are in the stream buffer data that i output in the log file.
e3 << 9 = 116224
e0 << 1 = 448
116224 + 448 = 116672
1615766400 + 116672 = 1615883072
1615883072 - 131072 = 1615752000
Code:BOGUS: Sewing Street / Yarn Lane REPEATS mjd=59288(bcd:1615766400) bcd=1615883072 bcdfix=1615752000 sec=116672(E3 E0) duration=43200 b5 22 e3 e0 54 60 6b
Huevos (14-03-21)
Is it possible to get CRID from this stream? Simon is planning some code for programming series link.
Andy_Hazza (14-03-21),bbbuk (14-03-21)
There does seem to be some end-user documentation for an OpenTV API here:
Not sure how complete this is, but I can't find any reference to CRID data in it.Code:https://opentv.nagra.com/sites/default/files/api/medialive_os_api/5.2.4/CCOM/index.html
MiracleBox Prem Twin HD - 2@DVB-T2 + Xtrend et8000 - 5(incl. 2 different USBs)@DVB-T2[terrestrial - UK Freeview HD, Sandy Heath] - LAN/USB-stick/HDD