Beyonwiz Australia

prl wrote:This is a long-standing issue with IceTV timers. I don't ever see it, but I think that's because I don't see timers being set beyond the end of the EPG.

MrQuade wrote:Just speculating now, but what about repeat flagging for that show?

I think all of my series timers are restricted to first-runs only. Perhaps first-run flagged series timers are deferred until later if the repeat information takes a bit longer to determine? Maybe if a series is set to record all instances, the timer is set earlier?

vader1111 wrote: Almost all of my series reservations use these settings.

MrQuade wrote:Is it a simple matter of ensuring that the IceTV plugin performs a periodic refresh equivalent to whatever it does following a GUI restart/reboot?

# Whenever EPG update is received ...
timertbl = {}
for timer in recording_timers:
    timertbl[entry.event_id] = timer

save_timers = False

for shows in EPG_update:
    if show.event_id in timertbl:
        timer = timertbl[show.event_id]
        if show.episode != timer.episode:
            timer.episode = show.episode
            save_timers = True
        if show.description != timer.description
            timer.description = show.description
            save_timers = True

if save_timers:
    recording_timers.save_to_file()

prl wrote:Perhaps getting timers outside the EPG range is a regional thing. ...

{528}<   137.824> [Console] finished: /usr/bin/ntpdate-sync
{528}<   137.825> [NetworkTime] setting E2 time: 1490737344.49
{528}<   137.833> [eMainloop::processOneEvent] unhandled POLLERR/HUP/NVAL for fd 49(17)
{528}<   140.601> [eDVBServicePlay] timeshift
{528}<   140.608> [eDVBServicePlay] timeshift
{528}<   140.611> [eDVBServicePlay] [Timeshift] stopTimeshift
{528}<   140.614> [eDVBServicePlay] timeshift
{528}<   140.628> [eDVBServicePlay] timeshift
{528}<   140.630> [eDVBServicePlay] timeshift
{528}<   140.636> [eDVBServicePlay] Start timeshift!
{528}<   140.647> [eDVBServicePlay] timeshift recording to /media/hdd/timeshift/timeshift.XzjoOv
{665}<   140.657> [setIoPrio] realtime level 7 ok
{665}<   140.657> [eFilePushThreadRecorder] THREAD START
{528}<   140.680> [Timeshift] ptsCreateEITFile: in method 'eEPGCache_saveEventToFile', argument 3 of type 'eServiceReference const &'
{528}<   140.682> [eDVBServicePlay] timeshift
{528}<   140.684> [eDVBServicePlay] unpause
{528}<   140.690> [eDVBServicePlay] timeshift
{528}<   140.691> [eDVBServicePlay] timeshift
{528}<   140.693> [eDVBServicePlay] timeshift
{642}<   169.174> [RecordTimer] ignore double timer
{642}<   169.555> [RecordTimer] ignore double timer
{528}<   173.441> [Skin] processing screen MessageBoxSimple:
{528}<   173.567> [Skin] processing screen MessageBoxSimple_summary:
{528}<   173.574> [SCREENNAME]  ['MessageBoxSimple_summary', 'SimpleSummary']
{528}<   173.579> [SCREENNAME]  ['MessageBoxSimple']
{528}<   292.122> [AutoTimer] Auto Poll
{528}<   292.165> [AutoTimer] Auto Poll Started
{687}<   292.319> [eEPGCache] lookup events with 'The Deep' in title (ignore case)
{528}<   292.932> [Task] job Components.Task.Job name=AutoTimer #tasks=2 completed with [] in None
{528}<   352.578> [MessageBox] Timeout!
{528}<   352.652> [SCREENNAME]  InfoBarSummary
{528}<   352.793> [Standby] enter standby
{528}<   352.809> [eDVBServicePlay] [Timeshift] stopTimeshift

prl wrote:I'm happy to work with anyone who has this problem to try fix it if they're willing to run alpha code.

prl wrote:Perhaps getting timers outside the EPG range is a regional thing. Our in-use box is also shut down when it's not in use, so that may also help with keeping the timer info up to date.

I'm happy to work with anyone who has this problem to try fix it if they're willing to run alpha code.

vader1111 wrote: How do I re-start the GUI?

MrQuade wrote:

vader1111 wrote: How do I re-start the GUI?

Long-press the POWER button and choose the appropriate option (also accessible via MENU->Power).

Hopefully this will just be a temporary measure for you, if prl's idea comes to fruition.

vader1111 wrote:

prl wrote:Perhaps getting timers outside the EPG range is a regional thing. Our in-use box is also shut down when it's not in use, so that may also help with keeping the timer info up to date.
....

You and I are both in Canberra... yet I have the problem and you can't replicate it. That suggests it's not regional.

vader1111 wrote:My T2 is very rarely switched on. Most of the time I leave it in standby mode.

vader1111 wrote:... I rarely turn the T2 "on" ...

prl wrote: Your T2 is almost always on. Otherwise you wouldn't be able to copy shows off it.

Grumpy_Geoff wrote:...
My T2 has a Power Timer (kludged) set to boot to standby in the mornings, before the daily morning recording session starts. The PT has a 3-minute 'wait period' to go to standby from that bootup at 05:40.
Is that enough time for the recalcitrant timers to be fixed?

Grumpy_Geoff wrote:At what interval would the timer cleansing be expected - is it the below "[RecordTimer]" entries at 169 secs interval?

Grumpy_Geoff wrote:I note the NTP update at 137 secs is for time 05:42:24, so the interval appears 'short' by 7 seconds given the boot is set for 05:40.

Grumpy_Geoff wrote:

prl wrote:I'm happy to work with anyone who has this problem to try fix it if they're willing to run alpha code.

I'm always happy to run your alphas

vader1111 wrote:That's just a matter of terminology, with the T2 having 4 states..
Off - Switched off by the switch at the back of the machine
Deep Standby - Wakes up for timers, but is to all intents and purposes off the rest of the time (no network functionality)
Standby - A/V circuits powered down, but network functionality (including IceTV, Samba, FTP) all fully functional
On - A/V circuits running, all systems operational

My T2 spends 99% of its life in the 3rd of these modes, which I refer to as "Standby".

prl wrote:...

Grumpy_Geoff wrote:At what interval would the timer cleansing be expected - is it the below "[RecordTimer]" entries at 169 secs interval?

If you mean "when does the first IceTV EPG & timer update finish", then I would expect it to be well before the 137.8 second mark where your log extract starts.

prl wrote:

Grumpy_Geoff wrote:I note the NTP update at 137 secs is for time 05:42:24, so the interval appears 'short' by 7 seconds given the boot is set for 05:40.

I wouldn't be quibbling about a few seconds there. The front panel restart timer is set 3 minutes before the time in the timer (power timer or record timer). This makes sure everything is up and running for the timer the timer was set for.

Grumpy_Geoff wrote:

prl wrote:...

Grumpy_Geoff wrote:At what interval would the timer cleansing be expected - is it the below "[RecordTimer]" entries at 169 secs interval?

If you mean "when does the first IceTV EPG & timer update finish", then I would expect it to be well before the 137.8 second mark where your log extract starts.

All of the record and power timers are listed between 112 secs and 126 secs. Are you saying that the timers without description are processed then?

Grumpy_Geoff wrote:

prl wrote:

Grumpy_Geoff wrote:I note the NTP update at 137 secs is for time 05:42:24, so the interval appears 'short' by 7 seconds given the boot is set for 05:40.

I wouldn't be quibbling about a few seconds there. The front panel restart timer is set 3 minutes before the time in the timer (power timer or record timer). This makes sure everything is up and running for the timer the timer was set for.

For a record timer sure, but I don't believe that's the case for a Power Timer boot from shutdown.
The first time interval recorded in a relevant log is at 32.985 secs, with the log being named as *{date}_05-40-37.log.
The Power Timer was set for 05:40 - I believe that's when the bootup happened.

vader1111 wrote:...
How do I re-start the GUI? Is this just turning the T2 on & off again? If solving the problem is as simple as cycling the T2 through on/off every day, then that's definitely an acceptable solution.

1. A GUI restart. It could run daily, or on specified days you define
2. A go to standby
   Have this timed for, say 5 mins after the above restart. You need to account for the 3-min countdown popup before the restart occurs, plus the restart duration so the T2 can then effect your timed go to standby.

prl wrote:...
The only way around it, I think, is to scan the timers list looking for missing (or outdated) episode names and/or descriptions each time an EPG update is done. But I'm not in a position to test it.

prl wrote:...
When timers are checked to update their descriptions from the EPG, should it only update if the timer description isn't set (and miss out on getting any changes in the description on the IceTV side) or always set the timer description whether it's been set or not (and overwrite any description changes the user may have made).

I've coded the first, but I think the second may be better (and there's only a few lines of code that differ).

prl wrote:scan the timers list looking for missing (or outdated) episode names and/or descriptions each time an EPG update is done

peteru wrote:

prl wrote:scan the timers list looking for missing (or outdated) episode names and/or descriptions each time an EPG update is done

That sounds like the type of thing that could lead to performance issues akin to the "confused autotimer spinning star" syndrome. Not saying it's not worth trying, but it may be prudent to collect some performance metrics and tread carefully.

vader1111 wrote:Am I reading that correctly.. the whole EPG load process takes 15.8 seconds, and you're concerned about the 7ms it takes to update the descriptions?

vader1111 wrote:Maybe there's something else going on that I'm not aware of, which might cause conflicts... But from the outside it looks like an increase of 0.044%. I think most people would find that to be an acceptable delay!

prl wrote:I'd go with "should have known" rather than "have known".

prl wrote:Now that the server side changes have been running for a few days, have they fixed the problem of missing descriptions in timers created since then?