The below is of no use to those using IceTV for their EPG as you already get "frequent updates" to the EPG.
Background -
A few weeks back, due to the change in the Malaysian MotoGP race scheduling that was caused by bad weather, early on that Sunday morning Network TEN altered its program lineup for that day to cater for the change - for their motorsport coverage, this brought the MotoGP live telecast forward and put the V8 supercars highlights program back (it also affected other programs as well).
I was lucky that on that morning I just happened to have the Wiz (using FTA EIT and the AutoTimer plugin) zapped to a Network TEN service for long enough to scavenge the new event times, and thus populate the EPG with those new event changes. This then allowed the existing timers to be updated with new start times by the AutoTimer plugin well enough in advance of the MotoGP start. The V8 supercars event start time changed again about an hour and a half later.
I normally rely on EPGRefresh to keep the EPG data (i) populated, and (ii) current/accurate, but as most of you know, the plugin only runs once per day, and in my case I have it set for the late afternoon to try and cater for the night-time program drifts. So, I wouldn't normally have picked up the MotoGP change until it was too late.
This then got me thinking (a shower/dishwashing/garden watering moment) as to how I could get EPGRefresh to run in a far more frequent manner.
Having dabbled a small amount in OpenWebif command-line access to control the Wiz, I thought I had the answer - use a shell script to drive frequent executions of EPGRefresh's 'Refresh now' option (available from its YELLOW tab).
Then all sorts of issues appeared to me -
- It would disrupt live TV.
- I couldn't find a way to directly invoke the plugin as its positioning in the main menu was likely not place specific.
- The alternative access via the BLUE extensions menu was similarly likely not place specific.
- I wouldn't be able to get it to run in standby; this was the killer for me!
This then led me to deciding to roll my own, and which would use either service zapping if the box is in standby, or short timers if the box is in use.
So, on I went and what started out as a proof of concept soon evolved into something a bit more. I now present the results of that here just in case anyone wants to use it.
I no longer use EPGRefresh, as this script I wrote is doing the job.
[edited for version 1.2, see base of post changes]
Some script "features" -
- * no longer applicable
If the box is in standby then use zapping, or if the box is not in standby then use short timers and clean up after ourselves (both timers and recordings).
Zapping when in standby doesn't bring the box out of standby; it also doesn't start timeshift, and hence being my choice of mechanism if the box is in standby.
- Execution cycle is conditional on having a free tuner, and also conditional on not having timers due to fire in the next {x} mins that would exceed the current number of free tuners (that's ~4 mins based on scavenging from 6 providers x 30 secs per tune, plus the 20-secs of prepare time for the upcoming "real" timer).
- * no longer applicable
The current bouquet is used to select one service per provider to scan so as to not cause a jarring (for the user) bouquet switch. - * no longer applicable
If using zapping, grab the current (last used) service so as to zap back to it at the end (again, user expectation on startup service). - It doesn't waste time/energy scanning a provider that the box is already recording or showing live TV from
* no longer applicable (besides, if you happen to randomise to a service that is already currently being recorded, setting a short recording timer that is a subset of the existing timer's run window is ignored by the box and then the subsequent short timer deletion/cleanup fails with an error) - * no longer applicable
Handle the box being brought out of standby during a run cycle (it swaps to using timers) - You can have basic control of go/pause/stop execution cycles via "flag" files
- Of course, most importantly, execute this on a frequent basis.
The script will exit if it doesn't detect the presence of its processing flag file named 'AutoVisit.allow', therefore you can just rename it to stop the script.
If the script detects a pause file named 'AutoVisit.pause' then the next execution cycle will be skipped.
Guinea pigs are welcome - give it a burl if you're so inclined. Likely I haven't thought of everything - suggestions are welcome. Bug reports too of course.
For those without home network access to their Wiz, you can copy the shell script to a USB drive and then sneaker-net it to your Wiz and copy onto it.
I suggest locating it in a "local scripts" or "run stuff" directory on the hard drive (the same place you chuck your ipk files for the plugins such as Series2Folder, or ShootYourScreen).
You can use File Commander (Sources / Files) to perform some basic editing on the Wiz to alter the values of the variables in the top dozen lines of the script (unless you have access to an editor on Windows that keeps UNIX-like line endings).
Create an 'AutoVisit.allow' file on your computer and copy it to the Wiz. If you wish you can create a non-matching pause file (e.g. 'AutoVisit.pauseXYZ') that can be later easily renamed on the Wiz if you need to pause the processing.
I envisaged the script would be invoked from the enigma2 pre-start script, so as to automatically start after a boot or UI-restart.
There's a copy of that invocation code attached. For those with an existing pre-start script, you'll obviously need to make an edit to slot in the invocation code.
For those who like to keep their Wiz in deep standby when not in use, you can still achieve semi-regular EPG updating by utilising Power Timers.
Create a few repeated 'wakeup to standby' timers at your required "EPG updating" times. For a T3/T4/U4 you can have that same Power Timer have an end time set for, say, 20 mins after the start time. Set the after event action to be 'go to deep standby' to put the box back to the shutdown state.
Likely you'll need to push back your initial AutoTimer parsing startup delay setting (Autotimer settings: 'Startup delay (in min)') to ensure the initial AutoTimer parsing is started after the provider visiting has finished. A value of 9 mins should be enough. There is an earlier parsing started by the 'Timezones' instance but we can't control the timing of that one.
For a T2 though, since it doesn't have a smart front panel, the Power Timer bootup 'wakeup' and 'wakeup to standby' types are treated the same (a wakeup to full running state) as the T2 doesn't know the specifics of the boot (I don't think it even knows it was for a Power Timer), so it can't actually do the direct-to-standby part of the action. As a work-around, you can set an end time for the Power Timer for 3 mins after the start time and with an after event action of 'go to standby' (don't make the end time any shorter as the UI startup needs to complete before the UI can get around to detecting a "mid-stream" timer and effect that after event action).
Create another 'go to deep standby' Power Timer for your required shutdown time, at the above 20-mins interval.
Don't forget that provider visiting will occur during recordings (propitious conditions extant) so if you've regular daily recording timers set then the task objective is already being performed at those times.
________________________________________________________________________
Changes:
Version 1.1:
Changes made in an attempt to better handle live radio. Still had same issues with the system changing the TV bouquet to Last Scanned.
Version 1.2:
The AutoVisit script has been re-worked and it now uses streaming for both live and standby modes, instead of the previous methods of zapping (when in standby) or recording (live/running).
Because zapping is no longer used, it's also not restricted to using the current TV bouquet (which may not have been your usual bouquet and thus not have had all of your providers, missing out scanning some of them). All providers are now scanned as they're taken from the Terrestrial TV LCN bouquet.
Streaming is a lot gentler on the recording drive too.
There's no longer a need to adjust the number of providers in your broadcast area, as the script works it out.
So, all in all, the new version is a lot simpler and less intrusive
Version 1.3:
AutoVisit now detects any tuner use through current live TV/radio streaming, and takes that into account when deciding if there's enough spare tuner capacity for an AutoVisit run.
________________________________________________________________________
The simplest way to prove AutoVisit has updated the EPG is, prior to your first run of AutoVisit, enable IceTV and then disable it as this will clear the EPG of data. Then bring up the EPG and if you're real quick it'll be empty then after a few seconds you'll see it has populated for the current provider/broadcaster, or if you're a bit slower to open the EPG then you'll see that provider's guide data only. If you've got any recordings running then the guide data will be populated for those providers too.
Then let AutoVisit run and check the EPG and you'll find now its full of data
If you want to test it out directly without restarting the UI, you can simply invoke the script from the command line (but create the "allow" file first) -
e.g. /media/hdd/Runnables/AutoVisit.sh & (this will run it in the background).
Then you can watch the log file by tailing it -
ls -altr /media/hdd/logs | tail
tail -f /media/hdd/logs/AutoVisit.{date}_{time}.log
Then once you've seen enough, rename the "allow" file to stop it, or find the process to kill it -
ps -ef | grep [A]utoVisit
Attached:
/usr/bin/enigma2_pre_start.sh
AutoVisit.sh
Cheers,
Geoff
[edit - for new version 1.3]