[Zgemma H7] Weird EPG errors. EPG Refresh. Recent versions of OpenViX e.g. 5.4.008.

BrokenUnusableAccount · Mar 13, 2021

birdman said:
Given that there are only 86400 seconds in a day (0x15180) that looks as though 0x20000 is a flag (meaning unknown) that needs to be masked off.
Or it's a bit that's been shifted down that shouldn't be there....(signed vs unsigned right-shift)?

I think it is as if it's a signed number but where as a normal x bit signed number when incremented the meaning goes from +(2^x)-1 to -(2^x) here the meaning changes from +ve to -ve at a different point, probably when it's over 86400 seconds.
The 0x20000 error is because the program currently just always interprets it as a positive unsigned value.

birdman · Mar 13, 2021

BefuddledBrian said:
...and startSecond corresponding to start times of over 24:00.
The start times seem to be the old original start time plus 2^17 seconds which is 131072 (or 0x20000) seconds which is 2184 (or 0x888) minutes and 32 seconds.

Wait!! That should not happen!!!

The max value for UINT16 is 0xffff. Shifted left by 1 that becomes 0x1fffe. There is no way that the 0x20000 bit should ever be set.

Is there a bug in the UINT16 definition???

BrokenUnusableAccount · Mar 13, 2021

birdman said:
Wait!! That should not happen!!!

The max value for UINT16 is 0xffff. Shifted left by 1 that becomes 0x1fffe. There is no way that the 0x20000 bit should ever be set.

Is there a bug in the UINT16 definition???

I think I must have explained it badly. Did my second message make it clearer?

They are in a funny format.
Say something yesterday really started at 23:50 on 12th March.
I think they're trying to send it as 13th March starting at minus 00:10 but the software doesn't currently realise sky think negative start times are a thing.

Or maybe something earlier in the software is messing it up, but I don't think that's likely.

birdman · Mar 13, 2021

BefuddledBrian said:
I think I must have explained it badly. Did my second message make it clearer?

No.
The relevant thing is that (assuming UINT16 returns a 16-bit unsigned int)

Code:

 (UINT16(&buffer[2]) << 1);

should never be able to set the 0x20000 bit. Regardless of who intends what.

The problem is that I cannot find a definition of UINT16 anywhere.

EDIT: Found it. It's in the dvbsi++ bytestream.h header file.

Code:

// deprecated 
#define UINT16(p)       r16(p)

#if __BYTE_ORDER == __BIG_ENDIAN 
#define r16(p)          (*(const uint16_t * const)(p))
...
#else 
#define r16(p)          bswap_16(*(const uint16_t * const)p)

BrokenUnusableAccount · Mar 13, 2021

birdman said:
No.
The relevant thing is that (assuming UINT16 returns a 16-bit unsigned int)

Code:

(UINT16(&buffer[2]) << 1);

should never be able to set the 0x20000 bit. Regardless of who intends what.

It isn't.

It's like the error if a signed byte -17 is interpreted as unsigned giving incorrect value 249.
That's an error due to interpreting it wrongly of 256 or 0x100, even though the byte has no 0x100 bit in it.

birdman · Mar 13, 2021

BefuddledBrian said:
It's like the error if a signed byte -17 is interpreted as unsigned giving incorrect value 249.
That's an error due to interpreting it wrongly of 256 or 0x100, even though the byte has no 0x100 bit in it.

No. The compiler has been told it is 16-bit unsigned. Shifting it left 1 into a 32-bit value should never result in bit 18 being set.

Code:

[parent]: cat x.c 
#include <stdio.h> 
#include <stdint.h> 
#include <byteswap.h> 

static char buffer[4] = { 
    0x00, 0x00, 0xff, 0xff 
}; 

#define UINT16(p)       r16(p) 

#if __BYTE_ORDER == __BIG_ENDIAN  
#define r16(p)          (*(const uint16_t * const)(p)) 
#else  
#define r16(p)          bswap_16(*(const uint16_t * const)p) 
#endif 

int main(int argc, char *argv[]) { 
     
    uint32_t startSecond = (UINT16(&buffer[2]) << 1); 
     
    printf("res: %08x, %d\n", startSecond, startSecond); 
    return 0; 
}

[parent]: ./x
res: 0001fffe, 131070

Is correct. So why is that not what you are seeing??

BrokenUnusableAccount · Mar 13, 2021

birdman said:
No. The compiler has been told it is 16-bit unsigned. Shifting it left 1 into a 32-bit value should never result in bit 18 being set.

It's not set.

I told you I explained it badly.

Example:
StartMjd=59286 (13th March 2021) at startSecond=130772 (more than 86400! and currently interpreted as 36:19:32) should be interpreted as minus 00:05 or 23:55 on previous day.

But it's not just a 17 bit signed number of seconds because 86399 has be be positive, probably anything over 86400 should be interpreted as negative, but isn't.

birdman · Mar 13, 2021

BefuddledBrian said:

You are printing unsigned values as signed there, which may be throwing us.

startMjd and duration are uint16_t

startSecond and startTimeBcd are uint32_t

You need %u not %i.

BrokenUnusableAccount · Mar 13, 2021

birdman said:
You are printing unsigned values as signed there, which may be throwing us.

Oops.
Nothing printed out as negative, so I think I got away with it due to the 32 bit architecture.

adm · Mar 13, 2021

BefuddledBrian said:
It's not set.

I told you I explained it badly.

Example:
StartMjd=59286 (13th March 2021) at startSecond=130772 (more than 86400! and currently interpreted as 36:19:32) should be interpreted as minus 00:05 or 23:55 on previous day.

But it's not just a 17 bit signed number of seconds because 86399 has be be positive, probably anything over 86400 should be interpreted as negative, but isn't.

Ignoring the current definition of values for the moment ...

What happens to the value of StartMJD at mid-day? Does it go to 59287 at midday (0.5 rounded up) in which case could the value in buffer[2] actually represent a negative value after mid-day, and before midnight?

Why does the code multiply buffer[2] by 2? (left shift by 1). Does buffer[2] actually contain a time in seconds or the time in a resolution of 2 seconds?

However, having written the above questions the code seems to work for 99.99% of program times.

adm · Mar 13, 2021

BefuddledBrian said:
It's not set.

I told you I explained it badly.

Example:
StartMjd=59286 (13th March 2021) at startSecond=130772 (more than 86400! and currently interpreted as 36:19:32) should be interpreted as minus 00:05 or 23:55 on previous day.

But it's not just a 17 bit signed number of seconds because 86399 has be be positive, probably anything over 86400 should be interpreted as negative, but isn't.

Speculation

In your example of startSecond=130772, this is after buffer[2] has been shifted left by 1
So buffer[2] has a value of 0xFF6A
Ignoring the current definitions
Depending on types, casting this to a 32 bit value could result in either 0x0000_FF6A OR 0xFFFF_FF6A
Now shifting left by 1 gives either 0x0001_FED4 OR 0xFFFF_FED4

One value is more than the number of seconds in a day and the other could be a small negative number representing 1 hour 3 minutes

If MJD does increment by 1 at mid-day the latter could represent midnight on the 13/14th March boundary minus 1 hour 3 minutes rather than what you are assuming of midnight on the 12/13th March boundary plus 130772 seconds (approx 36.3 hours)

BUT again, why do 99.99% of program times appear to be correct?

BrokenUnusableAccount · Mar 13, 2021

I'm sorry everyone, I must have explained it really badly.

adm said:
BUT again, why do 99.99% of program times appear to be correct?

99.99% of the start times (startSecond) are less than 86400 and the software interprets them correctly.

I think what's happening is that after midnight programs that started before midnight but are still running get sent with these startSecond values over 86400 and the current MJD value (even though they really started when the MJD value was one less), and you can work out the start times in the normal format like this:

Code:

		if (startSecond >= 86400) //BB...
		{
			startSecond -= (0x20000 - 86400);
			--startMjd; // Interpret weird time beyond 86400 seconds as previous day
		}			//...BB

adm · Mar 13, 2021

BefuddledBrian said:
I'm sorry everyone, I must have explained it really badly.

99.99% of the start times (startSecond) are less than 86400 and the software interprets them correctly.

I think what's happening is that after midnight programs that started before midnight but are still running get sent with these startSecond values over 86400 and the current MJD value (even though they really started when the MJD value was one less), and you can work out the start times in the normal format like this:

Code:

if (startSecond >= 86400) //BB... { startSecond -= (0x20000 - 86400); --startMjd; // Interpret weird time beyond 86400 seconds as previous day } //...BB

From what I have seen most the ghost/duplicate programms were not running at the midnight boundary - they had finished long before that.
Or have I misunderstood in that what you are seeing is correct for programs spaning the boundary and not the cause of the duplicate listing.

ronand · Mar 13, 2021

Code:

 <programme start="20210316110000 +0100" stop="20210316120000 +0100" channel="282_2_6155">
  <title lang="en">Lorraine</title>
  <sub-title lang="en">Entertainment - Magazine</sub-title>
  <desc lang="en">Lorraine Kelly presents a topical mix of entertainment, discussion and showbiz glamour as well as the latest fashion, food and celebrity gossip.</desc>
 </programme>

It may not be programs spanning midnight being the problem but 11pm - note the +1hr

something_fishy · Mar 13, 2021

From what I have seen most the ghost/duplicate programms were not running at the midnight boundary - they had finished long before that.

That is not true in my case. I think that for all the phantoms that I have seen the original crossed midnight 36 hours, 24 minutes earlier.

BrokenUnusableAccount · Mar 13, 2021

adm said:
From what I have seen most the ghost/duplicate programms were not running at the midnight boundary - they had finished long before that.
Or have I misunderstood in that what you are seeing is correct for programs spaning the boundary and not the cause of the duplicate listing.

I think the code is correct for all programs where startSecond >= 86400.
Maybe they continue transmitting information in this "different" way for programs that have finished too.

birdman · Mar 13, 2021

adm said:
Why does the code multiply buffer[2] by 2? (left shift by 1). Does buffer[2] actually contain a time in seconds or the time in a resolution of 2 seconds?

Yes. It's a 16-bit field so can only hold a days-worth of seconds if the resolution is 2s.

birdman · Mar 13, 2021

BefuddledBrian said:
I'm sorry everyone, I must have explained it really badly.

I now see what you are suggesting.

But:

99.99% of the start times (startSecond) are less than 86400 and the software interprets them correctly.

Why would that be the case?
If start times are "evenly" distributed throughout the day then you'd expect this to be reflected in this value, which would mean ~30% should have this property.

birdman · Mar 13, 2021

BefuddledBrian said:
I think what's happening is that after midnight programs that started before midnight but are still running get sent with these startSecond values over 86400 and the current MJD value (even though they really started when the MJD value was one less), and you can work out the start times in the normal format like this:

Code:

if (startSecond >= 86400) //BB... { startSecond -= (0x20000 - 86400); --startMjd; // Interpret weird time beyond 86400 seconds as previous day } //...BB

Try this out and see how it fares.

BrokenUnusableAccount · Mar 13, 2021

something_fishy said:
That is not true in my case. I think that for all the phantoms that I have seen the original crossed midnight 36 hours, 24 minutes earlier.

Yes. Actually 36 hours, 24 minutes and 32 seconds.

[Zgemma H7] Weird EPG errors. EPG Refresh. Recent versions of OpenViX e.g. 5.4.008.

BrokenUnusableAccount

Guest

Moderator

BrokenUnusableAccount

Guest

Moderator

BrokenUnusableAccount

Guest

Moderator

BrokenUnusableAccount

Guest

Moderator

BrokenUnusableAccount

Guest

Forum Supporter

Forum Supporter

BrokenUnusableAccount

Guest

Forum Supporter

ViX Beta Tester

New member

BrokenUnusableAccount

Guest

Moderator

Moderator

Moderator

BrokenUnusableAccount

Guest

Similar threads

OpenViX Feeds Status