[Pending] - Timeslot for DVB EPG Grabbing

Sometimes i was wondering why my HTPC doesn't shut down even when i am not watching tv. Standing in the Home-Screen. PowerScheduler setted to 5 minutes. After analyzing the logs i see that the DVB EPG Grabber prevents the system to go into standby. So i looked for a way to tell Mediaportal to grab EPG only at night.

What is done:

- New config option in DVB-EPG Grabber page in TVService
* Use Timeslot for EPG grabbing (as a checkbox)
* Not before (as a DateTime Picker with Time-Only Option)
* Not after (as a DateTime Picker with Time-Only Option)

- Implementation of this functionality

If the checkbox is set (Use Timeslot) and the current time is NOT between "Not before" and "Not after" then the DVB EPG Grabber won't start grabbing EPG or (if already running) finishes the current grab on the actual transponder and then stops grabbing

If the checkbox is not set all remains as always


I saw a code fragment like this in _epgTimer_Elapsed(...) which starts the grabbing of EPG:

if (_tvController.AllCardsIdle == false)
return;

I think this is a error, because i think the grabbing can start when minmum of 1 Card is Idle. This code supresses the grabbing if i have 2 Cards and only 1 Card is idle. What do you think about it?

Patch is for SVN-Revision 28137

AW: Timeslot for DVB EPG Grabbing

What happens if you have 4 cards. 3 are recording - one card is idle and starts grabbing EPG and then starts timeshift or another recording?

AW: Timeslot for DVB EPG Grabbing

As you can see in the code. Same behaviour. It doesn't make a difference how many cards you have.
The current statement in SVN says: Only do EPG if ALL CARDS ARE IDLE.

I don't have analysed how mediaportal handles running EPG grabbing when a new recording is started, but thats no the focus of this change. I'm going too look for this in the future and maybe submit another patch if it is nessecary

AW: Timeslot for DVB EPG Grabbing

Oh it def. has an influence imagine my example and the old behavior in that case no epg grab would run. So it can't be a problem.

Yes. I agree. But that's not the perfect solution. That would be:
If one card is idle then start RPG grabbing. When afterwards a recording starts and no cards are idle but one card is grabbing epg then stop grabbing epg and start the recording. What's the problem with this? But once again: That's not the focus of my change. My change doesn't affect the current behaviour (even if i think its buggy). I'll implement the correct behaviour in a seperate patch.

This would be great if it can be set to wake and grab the EPG even if the "Grab when idle" option is disabled, as some people have problems with that enabled (or just prefer to turn it off) but would still like their EPG to be kept updated, even if they don't watch TV for a while.

Please read my first post. As I can see pilehave and disaster123 don't understand what the patch is for. The discussion of them is going in a totally wrong way. doveman ist the first one who has discovered the functionality of the patch. So use it. It does exactly that what you want.

Besides... The patch is in status pending... ??? Long time ago since i posted it. Is this OpenSource or Microsoft Development ???

But what about the scenario of a user who doesn't use MP to watch TV very often (maybe watches videos/listens to music) but wants to use it to record TV sometimes. Therefore they need the EPG to be kept up-to-date, and if "Grab when idle" is disabled for whatever reason it never will be. So if there was an option to update at e.g. 06:00 (which ignores/overrides the "Grab when idle" option) this would sort that out, without having to allow MP to grab the EPG whenever it feels like.

As for what happens if the tuner is busy at that time, I'd suggest that a "If busy, perform grab as soon as possible" function would cover that, so if there is a recording being done at 06:00, once that's finished the grab would be done before the system was allowed to go back into standby (according to whatever the Windows/Powerscheduler settings are).

Perhaps this will all become unnecessary with 1.3, but if this can be done in the meantime it can always be removed once it becomes unnecessary.