EPG data not showing on most channels

[Pigletti99]

The EPG data chooses random times of the day to display and doesnt even appear on most channels. My box also loses the time now and then and i have to auto update the clock. Is there a fix for this? (using latest Sifteam image)

 

[Rocknroll]

Is your menu language set to English ?
From what I've seen it doesn't display epg on some channels if it is set to some other language.

 

[bazinshine]

There is a bug in EPG.
the box is not storing the epg to the epg.db like it should be.
it is only loading the EPG for the transponder you are on, and wiping when you change transponder as its saving only in memory,,, Abcom + DGS are both aware of the problem and i'm told they are working to fix this..
as for the time settings, if box is hard reboot, yes there is a bug that time sometimes doesnt update itself, which only makes the epg bug worse! so try make sure time always are right time,

 

[fortean]

On my box, the time will be set to zero every time I switch the box on/off (using the switch on the back). I guess that the designers of the box "forgot" to include some backup energy source (battery, capacitor) that keeps the clock ticking when you switch off :-(

But even if the clock would have been backed up: that does us no good, unless sbox checks the clock and adjusts its own clock accordingly. Well, it does not! As I have Internet and have ported ntpdate for the HD900, I configured the box so it ran ntpdate just after the network was up and just before sbox started. No cigar. The sbox developers do not read the actual value of the clock when SBOX starts; they simply set the clock to 0.00!

And then they even go a bit further: the bloody application ruins my PERFECTLY SET SYSTEM CLOCK and sets it to 0.00!

Only when you set the time within sbox, it will get it right (and set the Linux date/time too).

Now, if we only could have the source code, we could solve this in a jiffy..

 

[fortean]

@bazinshine: it is not even a bug, it's what us engineers refer to as "Works As Designed"; nowhere in the sbox binary is there any reference to this database at all!

 

[bazinshine]

@bazinshine: it is not even a bug, it's what us engineers refer to as "Works As Designed"; nowhere in the sbox binary is there any reference to this database at all!

yeh so i noticed, thanks,,, mmm strange ,, I'm sure it will 'magically' appear sometime soon..

 

[fortean]

@bazinshine: I think I just figured out why they don't use that database anymore ...

See, these boxes use MTD devices to store their data. Now, MTD (aka flash) devices have limited lifespans. You may alter any of their (32K) blocks about 10-20.000 times, and then the block becomes unreliable or even unusable. Also keep in mind that MTA devices need to do a full erase of at least one 32K block whenever a single bit is changed.

Then consider the way a database (like sqlite3) operates: it cares about its data and consequently writes the data to permanent storage ASAP, even minor changes. Also, it typically uses a limited range of disk-blocks, it is quite good at re-using existing blocks.

Now, I guess that the guys at DGstation started off storing the EPG database on their flash drives, hence the stub we still find in /var.

Then they switched on their prototype and EPG data poured in: blocks and blocks of data, changeing very frequently, and the receiver stashes these changes away in the sqlite3 database, which dutyfully re-uses the same blocks over and over again, which in turn results in massive erase/rewrites to the very same blocks on the MTD..


Now, let's see: 10.000 writes, that sounds like an awful lot, but in fact is not that much and so their boxes died after a few weeks..

 

[fortean]

I have been discussing this a bit with a member of another forum, who pointed out that the sqlite3 database manager actually does NOT re-use blocks. I did some simple tests: I created an empty database, set up a bogus table and whilst monitoring the filesize of the database started entering data. It seems that sqlite3 increments the filesize with 2K blocks and indeed: when you delete all data, the file keeps its size! Then, when you add some data again, the file starts growing again.

This makes me wonder how many transponder rescans you can do before you run out of space..

BTW: there is a VACUUM command which you can issue within sqlite databases and that will remove all superfluous space from the database. I could not find any references to it in the sbox code, though..

 

[bazinshine]

hehe yeh i was watchin on the other forum lol, All makes sense one way or another, im sure it worked on there old DGS boxes tho same method, so i am sure we will get it working again soon