RS EPG all over the place and totally out of sync with the on the box EPG

However, around midnight each day the data indices are reset which will result in all EPG data being re-uploaded by whichever box checks in first (one box per region). This will update events that have moved.
Unfortunately it doesn't seem to work very well,
For example it hasn't picked up the move of Pointless from BBC1 to BBC2 today
RS:
1585069340787.png
webif:
1585069413674.png

This may be because the broadcast EPG wasn't updated until during the day today so perhaps it would be better to reset the indexes at noon rather than midnight or perhaps even every couple of hours. (they haven't moved the rest of the week Pointless yet even though the Coronavirus Daily Update has become a regular event)

But even when a schedule change has been made more than 24 hours in advance it doesn't seem to reliably make it into the RS epg - for example I noticed a live football match appearing on Sunday's epg though it surely must have been rescheduled long before then
 
- for example I noticed a live football match appearing on Sunday's epg though it surely must have been rescheduled long before then
also here

could it be that the first machine that checks in does NOT have the updated epg, perhaps continuous on?
 
Good call Mihaid, but what are the chances of that in all the regions?

Sent from my SM-G950F using Tapatalk
 
Good call Mihaid, but what are the chances of that in all the regions?

Sent from my SM-G950F using Tapatalk
presumably the always on machines make the first contact because they're on? and also we probably don't represent all the uk regions
 
Whether there are Humax's in all regions is irrelevant, if there are none who cares what the epg is for that region? If there is one humax it will provide the RS with the epg for the region when it connects.
 
Probably is exactly the correct word.
Only if you have data to indicate that the likelihood is greater than 50%. Otherwise "might" or "maybe" is exactly the right word. "Probably" specifically means "it is more likely than not" - ie a specific assessment of likelihood which cannot be made without data.

It really p*sses me off when people oversell like this, but I admit we all do it (some more than others).
 
Only if you have data to indicate that the likelihood is greater than 50%. Otherwise "might" or "maybe" is exactly the right word. "Probably" specifically means "it is more likely than not" - ie a specific assessment of likelihood which cannot be made without data.

yeah, but you're assuming i had no data. forgetting the years and years of activity on this forum and reading relevant posts made by af123.

and it seems that my data lead me to the right words and the right result.
 
we probably don't represent all the uk regions
What, all the HDR-FOXes being run with RS by regular contributors to this forum and the droves of people who use the CF without ever posting or subscribing to this forum?

but you're assuming i had no data
Only af123 has the data

and reading relevant posts made by af123.
Quote please. I don't recall anything recent about this.

What's so wrong with admitting "might not" is a more accurate representation than "probably not"? I believe this is just your pride getting in the way.
 
An example of the RS epg getting it wrong (region South)

It currently has two programmes for the same BBC 1 time slot today.
1585996069333.png

Which is shown in the grid view seems to vary depending on where you start the display
1585996298241.png
or starting at 12
1585996377625.png
Initially I was suspecting the Rugby must be an error which is why I started looking at the schedule - but no we are being shown classic matches :(
 
but no we are being shown classic matches :(

What's wrong with that? There must be vast archives somewhere of great sporting events, Motorbikes, car racing etc., which would make good viewing to sport starved fans.
 
The database contains both entries, one uploaded on the 3rd, one on the 4th - from two different devices.

Code:
MariaDB [humaxrs]> select * from depg_12340 where start = unix_timestamp('2020-04-04 14:30:00') and service_id = 4172\G
*************************** 1. row ***************************
  network_id: 12340
  service_id: 4172
    event_id: 10650
       start: 1586010600
         end: 1586013300
    duration: 2700
        name: Money for Nothing
        text: 3/20. Sarah Moore is in Surrey, checking out the cast-offs at Witley recycling centre. She and her team of artisans try to revive a 1950s TV, an art deco chair and a drum kit. Also in HD. [S]
     warning:
warning_mode: 0
content_mgmt: 0
content_type: 2
     content: News/Current affairs
  event_crid: /m/231Q
 series_crid: /m-22ZU
    rec_crid:
       flags:
         did: 3062
         dat: 2020-04-03 03:24:16
*************************** 2. row ***************************
  network_id: 12340
  service_id: 4172
    event_id: 10980
       start: 1586010600
         end: 1586016900
    duration: 6300
        name: Coronavirus: Daily Update
        text: Latest developments including a Downing Street news conference on the coronavirus epidemic. Also in HD. [S]
     warning:
warning_mode: 0
content_mgmt: 0
content_type: 2
     content: News/Current affairs
  event_crid: /m/9W5S
 series_crid: /m-9IBG/01
    rec_crid:
       flags:
         did: 2352
         dat: 2020-04-04 03:24:51
2 rows in set (0.00 sec)

Both devices are the same in terms of versions and region data

Code:
MariaDB [humaxrs]> select model, modver, rsver, region, nid from device where did in (2352, 3062);
+-------+--------+-------+--------+-------+
| model | modver | rsver | region | nid   |
+-------+--------+-------+--------+-------+
| HDR   | 3.13   | 1.5.1 | South  | 12340 |
| HDR   | 3.13   | 1.5.1 | South  | 12340 |
+-------+--------+-------+--------+-------+
2 rows in set (0.00 sec)

It does look like RS should be preferring the newer data but that is not trivial to implement.
 
FWIW, there don't seem to be many of these for that channel in your region:

Code:
MariaDB [humaxrs]> select service_id, from_unixtime(start) from depg_12340 where service_id = 4172 group by 1,2 having count(*) > 1;
+------------+----------------------+
| service_id | from_unixtime(start) |
+------------+----------------------+
|       4172 | 2020-04-03 14:45:00  |
|       4172 | 2020-04-04 14:30:00  |
+------------+----------------------+
2 rows in set (0.01 sec)
 
It does look like RS should be preferring the newer data but that is not trivial to implement.
I wondered if it was somehow related to the events being of difference lengths leading to the older shorter events being left in the data base
 
Back
Top