EPG grab improvement

[frodo]

The broadcsters don't guarantee that all data is present and error free.

The epg grabber already grabbed millions of epg data for all kinds of countries and users (in both the tvengine of MP and in the new tvserver)
I didnt hear any complains that it receives a partial EPG or
that the EPG is corrupted. So i think we can skip this point.

Only thing i know is that for the UK we need to increase the timeout value
to make sure the epg-grabber does not prematurely times out.
since they transmit epg with a much lower bandwidth than other counties
As the tvserver is still in beta this is we're currently working on.
Once we that is solved, the current method for grabbing the epg should ensure
that a full error-free epg will be received always

>does not simply scans all channels in any mux (as you say it does).
It does if every channel times out

Correct and i explained why it does this.
If one channel times-out, then this doesnt mean that the whole mux can be skipped. The other channels in the mux can contain epg
Not everyone lives in the UK

>it skips channels for which epg has been received
In skipping a channel for data received there is NO guarantee that the EPG is now fully populated for that channel

This is repeating the first point.

About worse case scenario's and performance
- your solution is not faster (providing the epg grabber always grabs a full epg
and does not prematurely times-out)

- worse case scenario? Well the fact that the epg grabber as it is now works
for all countries/users tells me that its pretty capable of dealing with worse case scenario's. Unfortunaly your proposed method isnt since it only works in the UK situation.

[Broceliande]

Here is what you said first :

At the moment the broadcast EPG grab cycles through channels .

A better option would be to cycle through the broadcast/mux frequencies.

You explicitly told that a best way would be to grab EPG through mux , rather than through channels.
Again , this method won't work for many users.
However , maybe we misunderstood some things, feel free to code it this way and submit us your code : be sure we will test it.

[SciDoctor]

That was unnecessasary.

You reasoning is wrong .

I will try and make it simple

There are one hundred boxes in a room .
It takes five mins fo check a box .

The total time to check every box is 500mins, and there is no way that it can be done quicker whatever order you check the boxes.

NOW There are one hundrded boxes in a room BUT now the boxes are grouped into ten groups of ten boxes .
By checking any box in a group automaticly checks the other nine in the group and still takes only five minutes .

Now what is the quickest time to chekh every box ?


If the room has one hundred boxes some individual and some in groups which method is the best method to use ?

The MAX time is still 500mins but is there a quicker way ?

[frodo]

SciDoctor,

If there is a faster, better way to grab epg, i'm all for it.
But this discussion is leading to nothing (i guess i just dont understand you)
Perhaps you can do us both a favor:

1. Please tell me exactly with a good example how your method works.
2. make sure it works for both situations that is:

Situation 1 : UK
- each channel in a mux contains the epg data for all channels in that mux

Situation 2 : Netherlands/france
- Channels in a mux contain only their own epg data and not the epg data for other channels in that mux

Please describe
- exactly how it works
- how errors are handled
- how partial epg receival is handled
- how this leads to a faster fullepg grab.

[SciDoctor]

About worse case scenario's and performance
- your solution is not faster (providing the epg grabber always grabs a full epg
and does not prematurely times-out)

(There is a max time to grab all channels BUT there is also a min time when a channel carries data for other channels)

- worse case scenario? Well the fact that the epg grabber as it is now works
for all countries/users tells me that its pretty capable of dealing with worse case scenario's. Unfortunaly your proposed method isnt since it only works in the UK situation.[/quote]


My method still works for every possible combination of MUX and channels on MUX.
All I have proposed is a change in the order of the grab .

Instead of cycling through every channel on a MUX and then moving to the next MUX and so on.

Cycle the MUX and then increment the channel.

[SciDoctor]

Your grab.

MUX A CH1 ,MUX A CH2 ,MUX A CH3......MUX A CH (last channel)
MUX B CH1, MUX B CH 2, MUX B CH3 .....MUX B CH (last channle)
MUX C CH1, MUX C CH2 etc
MUX D etc

AT END OF AVAILABLE MUX REPEAT FROM MUX A CH 1

My proposed grab

MUX A CH 1, MUX B CH 1 ,MUX C CH 1, MUX D CH1 ........MUX (last mux) CH 1
MUX A CH 2, MUX B CH 2, MUX C CH 2, MUX D CH2 ........MUX (last mux) CH 2
MUX A CH 3 ,MUX B,CH 3 ................................................MU X (last mux) CH 3

AT END OF AVAILBLE CHANNELS REPEAT FROM MUX A CH 1


Errors are handle the same way .
A grab is a grab whatever data is received is put in the database in the same way as your existing mehtod.
You can still choose to miss a channel if the previous grab has contained data that has populated the databse if you want , i wouldn't so as to catch as much data as possible.


NO MUX is being missed NO CHANNEL is being missed , so this is a universal grab.

As I have tried to explain there is no way to change the MAX time if every channel is EPG data independent BOTH methods take the same time BUT where channels share EPG data the time is reduced .

[funkstar]

I can't understand how this would be quicker. It's a different order, but as both methods are clever enough to not check chanels that are already updated i don't get how it is quicker.

[SciDoctor]

Originally Posted by funkstar

I can't understand how this would be quicker. It's a different order, but as both methods are clever enough to not check chanels that are already updated i don't get how it is quicker.

The method as is doesn't take in to account the possibilty that if the first channel on a MUX that is checked 'times out' that ALL channels on this MUX could be in a situation NOW to 'time out' .Thus checking them NOW would waste time .(you do revisit the next channel on a MUX the next cycle)

In a situation where a 'time out' occurs a move to start to grab the channels on the next MUX instead of repeatedly trying every channel on the original MUX would be benefical

This situation ocured this weekend as the power to two MUXs had been reduced rendering reception poor and the EPG data unavailable.

These two MUXs (A and B) contain thirty channels.

The EPG grabber spent 30x10 = 300mins trying every channel, getting a 'time out' on all and the EPG database recived no data .

Changing the grab order would have allowed a 'time out' on MUX A CH 1 and then 'time out' on MUX B CH 1 (only 20 mins wasted for no EPG) and then MUX C CH 1 where a succesful garb would have occured.

The difference 300 mins for no data or 30 mins and at least data for one channel (possibly more than one or all channels depending on broadcasters EPG data)

We both agree that in perfect no error conditons both grab orders will take about the same time.

Now the problem with not grabbing any channel because you received data within a previous grab on another channel doesn't take into account that the data recieved may not be complete.

[chenks]

maybe a more relevant point is this...

why does the EPG grab work with the present tv engine for UK DVB-T.. but not with the new engine ?

[funkstar]

SciDoctor,

OK, now i understand where you are coming from. Is this really a problem though? Does this happen a lot?