15 replies to this topic

[doglover]

In the XMLTV importer the standard time to start an import is set at 5h45.

Pls. do not do this.

 

The download servers are not all professional servers which can handle hundreds of thousand simultaneous connections.

I am experiencing problems updating these servers at exactly 5h45, probably due to a server overload.

 

I am asking that you set your XMLTV import at another time,  preferably after 7h00 (GMT+2) in the morning.

 

If you are smart, you even set your import time after 10h00.  By that time I had time to inspect the sites and correct the errors in the upload.

 

Willy

Edited by doglover, 16 August 2014 - 07:48.

[littlesat]

Probably a random factor should be added to this default time...... even consider to NOT make it programmable...

[MiLo]

How about basing the default import time on the MAC address of the machine... That would give each box its own preferred time.

[doglover]

I will welcome every solution which prevents server overload.

 

Willy

[MiLo]

Well, if the last digits of MAC address are evenly spread, you should see evenly spread import times tomorrow (between 6:00 and 9:00).

[golfdiesel]

I have the import set at 19.00 CET because this is for me the most convenient time because the box is in deep sleep when not in use so it has to be turned on and at 19.00 the chance is pretty big the unit is on.

A fixed designated time will be problematic for me if it would enforced.

Edited by golfdiesel, 16 August 2014 - 09:37.

[doglover]

19.00 CET  is fine.  You are well out of the way of anybody else.

If everybody was this smart, we would not see this overload problem.

 

I guess that Milo is not talking of a set fixed time spread between 06h00 and 09h00.  I guess he is just talking about setting the default time depending on the MAC address.  So everybody will have a different time by default when he installs the plug-in and not the 5h45.  The user would be still free to set a time of his choice.

 

Willy

Edited by doglover, 16 August 2014 - 09:52.

[MiLo]

Yep. If you set your own time, it will use that (it will randomly add a few second though, so it would start at 19:00:42 if you asked it to run at 19:00). Otherwise, it will use whatever happens to be the default for your box, which is different for each box (at least, that's what I hope).

[hemertje]

does it respect "deep standby" or does it "auto wakeup" and sleep again after the import?

[MiLo]

No change there.

[littlesat]

When it is in deep standby I would recommend to take the time it comes back from deep standby + 10 min or so..... That is random enough I suppose...

[doglover]

I am avoiding now 5h00 and 5h45 with the upload.  And this morning the update was OK.  (except for one file - still trying to determine why)

 

The change Milo programmed, will only work for new installed plug-ins.  An update would still have the previous selected time. So I will have to live with overloaded sites (and denial of service) for some time.

 

I will strongly request that users check the import time they have selected, and change this to a time after 7h00 (6h30).  And please use a time like 7h13 and similar. (7h28 - 7h17 and so on).  This will reduce the chance of many people selecting the same time slot.  (if a lot of people select f.i. 7h00 then the overload would happen at 7h00).  If it is more convenient for you to import lets say at 5h45 or around that time, you can still do it, but pls. change your import time to something like 5h51 - with the 51 here as an example - choose something different).

 

Willy

[MiLo]

The change Milo programmed, will only work for new installed plug-ins.  An update would still have the previous selected time. So I will have to live with overloaded sites (and denial of service) for some time.

It should work for upgrades too. It will only work though when the user did not modify the default time.

The vast majority of users don't upgrade very often, so regardless, it will indeed take considerable time for this issue to settle.

I could "force" a reset to default by changing the internal name of the config item, so it will have its default value after upgrading.

[littlesat]

I could "force" a reset to default by changing the internal name of the config item, so it will have its default value after upgrading. 

+1

[Pr2]

Hi,

 

Indeed that's a solution but that will apply to who?  Will it really solve the problem?

Not everybody is using OpenPLi and not everybody is using xmltv-import, but many others use the Rytec sources too, so this "best pratice" should be applied in every "EPG download" plugin (eg CrossEPG) and not only to OpenPLi and xmltv-import users. And for users that still using old OpenPLi no longer supported (OpenPLi 3, 2.1,...).

 

 

Pr2

[Pr2]

Hi,

 

One more remark don't have all the crappy clones the same MAC address?  So using MAC is perhaps not the best idea... will have worked fines in a world without clones...

 

Pr2