# Running daily call at a specific time



## ColinYounger (Aug 9, 2006)

I want my TiVo to call the mothership at the same time every day - so that my DailyMail email stops giving false positives on items TiVo is going to record (or even rejected recordings) due to inaccurate guide data. There's also a couple of other reasons which basically involve me being anally retentive. 

I thought I'd share my simple solution which has been working happily for a week.

TivoWeb(+) allows you to force a call, and looking at the phone.itcl script, these two lines are the killers:

```
set Daily [binary format c20 "127 -60 126 100 127 -1 -15 -80 1 -78 92 -56 127 -18 -5 116 127 -75 -91 -8"]
event send $TmkEvent::EVT_DIALUPEVENT 0 $Daily
```
So I've stuffed those into a small 'MakeCallNow.itcl' script (attached - you'll need to rename it to MakeCallNow.itcl) and scheduled it in cron:

```
0 6 * * * /var/hack/MakeCallNow.itcl &
```
Now feel free to point out a setting somewhere that makes this worthless.


----------



## BrianHughes (Jan 21, 2001)

Well done! Over the years there have been queries about doing this and the answer was always to do it manually.


----------



## iankb (Oct 9, 2000)

I would suggest that people vary the cron time a little, or you'll all be competing for server access.

Neat solution, and a pity that dial-up users won't be able to use it to better avoid conflicts with voice calls.


----------



## ColinYounger (Aug 9, 2006)

Ian - very good point about the cron entry. I just included mine as an example and didn't think others would just cut 'n' paste. 

Also - why can't dial-up users just set the time that they know everyone is asleep or out? Say 4am?


----------



## ColinYounger (Aug 9, 2006)

ColinYounger said:


> ```
> 0 6 * * * /var/hack/MakeCallNow.itcl &
> ```


Please note that this causes my TiVo to do the call at 6am. Just vary the FIRST number (minutes) or the SECOND number (hour) to get your preferred time.


----------



## iankb (Oct 9, 2000)

ColinYounger said:


> Also - why can't dial-up users just set the time that they know everyone is asleep or out? Say 4am?


Mainly, because most people who use dial-up access don't have network access to hack their TiVo.


----------



## Pete77 (Aug 1, 2006)

Colin,

Nice idea as I would like to put an event in my crontab to make Tivo reboot every so many days in the early hours of the morning (to avoid the eventual reboot failure when using TivoWeb that results if the machine is not rebooted every so often and/or a much, much rarer total freeze of my Tivo menu system that has happened to me two or 3 times while Telnet and FTP access still persist and reboot at the Telnet prompt still works) However I am reluctant to do so as if this automated reboot may clash with my Tivo being in the midst of re-indexing after a daily call.

To clarify your new method adds an extra certain time for a Daily Call each day but TivoWeb will still makes a further daily call at a random time of its own choosing as well each day? Is that a correct assumption on my part?

There is no way to stop Tivo making its own daily call as well and to only make the call that is scheduled using your new script is there?


----------



## iankb (Oct 9, 2000)

Pete77 said:


> To clarify your new method adds an extra certain time for a Daily Call each day but TivoWeb will still makes a further daily call at a random time of its own choosing as well each day? Is that a correct assumption on my part?


No, completely wrong. 

TivoWeb never makes any calls, except when manually requested via its menus. The TiVo software will make a routine daily call that is scheduled to start 24 hours after the end of the previous call. This causes the call time to move forward, but less quickly with the faster network call. When the time reaches the start of daytime, it will automatically jump to late evening to avoid hogging the 'phone during waking hours.

When a call is scheduled manually, the next automatic call will be rescheduled to start at least 24 hours after that, so there shouldn't be more than one call in any 24 hours, unless manually initiated.

It's just possible that the TiVo servers will start rejecting update requests if manual requests are scheduled too frequently, but I doubt that they have bothered to implement that.


----------



## Pete77 (Aug 1, 2006)

iankb said:


> When a call is scheduled manually, the next automatic call will be rescheduled to start at least 24 hours after that, so there shouldn't be more than one call in any 24 hours, unless manually initiated.
> 
> It's just possible that the TiVo servers will start rejecting update requests if manual requests are scheduled too frequently, but I doubt that they have bothered to implement that.


So you are saying that running the call manually at a set time with this utility from Colin and using Cron will probably mean the Tivo software never makes its own automated call any longer?

By the way my experience of automated Tivo calls is that they do not avoid daytime hours. My Tivo calls regularly occur at times like 11am and 2pm. My experience is that although the Tivo call time moves forward as you suggest the times of day it most avoids are the night between about 10pm and 6am. It is to avoid those times of day that its call time suddenly advances by 8 hours. Or that is my impression as I look regularly at System Information but have never kept a manual log of daily call times.

Also do you think setting up an entry for reboot in crontab once a day or three times a week or say once a week sounds a viable option that cron will execute?


----------



## iankb (Oct 9, 2000)

Pete77 said:


> So you are saying that running the call manually at a set time with this utility from Colin and using Cron will probably mean the Tivo software never makes its own automated call any longer?


It's very unlikely to.



> By the way my experience of automated Tivo calls is that they do not avoid daytime hours.


There do seem to be random glitches with the algorithm, but generally it usually does with me. Maybe, with some users, it gets their time zone wrong, or it switches off the skip for a while if you start performing manual updates.



> Also do you think setting up an entry for reboot in crontab once a day or three times a week or say once a week sounds a viable option that cron will execute?


Personally, I wouldn't reboot my TiVo automatically more than every 3 months or so. But then I don't use TivoWeb much, and I think that any problems with failing drives, etc, are more likely to appear during a reboot. I don't know whether there are any technical reasons why it wouldn't work within crontab, but it wouldn't hurt to try.


----------



## Pete77 (Aug 1, 2006)

iankb said:


> Personally, I wouldn't reboot my TiVo automatically more than every 3 months or so. But then I don't use TivoWeb much, and I think that any problems with failing drives, etc, are more likely to appear during a reboot. I don't know whether there are any technical reasons why it wouldn't work within crontab, but it wouldn't hurt to try.


The Zipper hack installation pack they use on later Tivo models in the USA seems to include an option to reboot the Tivo once a day as a standard feature. I really can't see how a reboot without a power off is likely to cause hard drive wear. I thought it was only power cycling where the hard drive spins down and then is spun back up again from off that causes that kind of wear.

Yesterday my Tivo UI froze for no obvious reason as it did 3 or 4 months ago but Telnet and FTP access were still working. I believe this freeze would have impeded further recording. But a reboot kicked off by Linux Cron would surely have got it going again?


----------



## iankb (Oct 9, 2000)

Pete77 said:


> I thought it was only power cycling where the hard drive spins down and then is spun back up again from off that causes that kind of wear.


I was thinking more about corruption of the MFS filesystem, that may only be found during startup checks, and that may then cause a GSOD.


----------



## Pete77 (Aug 1, 2006)

iankb said:


> I was thinking more about corruption of the MFS filesystem, that may only be found during startup checks, and that may then cause a GSOD.


Perhaps.

But its obviously better to replace your hard drive before it gets anywhere near that stage.


----------



## ColinYounger (Aug 9, 2006)

...back on topic...

Ian is right in that part of the 'call home' procedure (EVT_DIALUPEVENT) that I trigger does all the things that a normal daily call does - including scheduling the next daily call (which is usually 24 hrs plus a fudge factor). I compared the log file entries of a normal automatic call and a 'forced' call, and other than TiVo being suspicious about who my script is ("EvtSwitcher[77]: Invalid service attempted to attach?") it seems happy enough.

Of course, now that my script is in the wild, when I get home today I find that a *second* call has been made today - a mere 30 minutes ago. Due to log file rotation, I can't tell why.


----------



## jeremy Parsons (Jan 6, 2002)

If you are worried about rebooting causing issues you could use the /etc/restart command which dismounts the filesystems prior to a reboot , I use it when I restart my recorders , usually every 6-12 months when endpad stops working or freespace has an issue. The only other problem as I see it is you would then want to cron the dial up as rebooting during indexing is I believe one of the few nono's on a tivo.

I tend to reboot after loading up tivoftp when doing tivoweb updates but apart from that have had them up between 200-300+ days the usual reboots nowdays are due to power failours


----------



## ColinYounger (Aug 9, 2006)

OK - I need to tweak.

Today my Tivo called home at the allocated time. But the 'fudge factor' to the next call was *negative* meaning that the next auto call would be 5 mins before the 'manual' one. That's the first time that's happened, but no excuse for shoddy coding. 

I'm unsure about the solution, though and would appreciate thoughts.

My first thought is that I could check the 'last call' and status info to see if the auto call was done successfully in the last 'x' hours. If not, call now. If it was done within the time window, do nothing.

Another thought could be to 'adjust' when the TiVo wants to call home to *after* the manual time after the cron job has completed so that we never get this situation.

Neither of these will be easy (for me) - especially handling dates and times so feel free to share knowledge.


----------



## rickynumber18 (Feb 28, 2007)

Hi. Colin's intitial instructions say to "scheduled it in cron". Could anyone let me know (in easy words!!) what that means. How do I schedule it in cron - is it via Telnet? Sorry, as my tag says, I'm getting there slowly!!


----------



## TCM2007 (Dec 25, 2006)

A pedant writes:

It's not a .itcl file, it's a .tcl file.



No need to use cron at all in fact; as you've made a TCL script, just have it wait *23* hours and then run the main routine again.


----------



## Pete77 (Aug 1, 2006)

ColinYounger said:


> I'm unsure about the solution, though and would appreciate thoughts.


Colin,

My experience of getting Tivo to make a manual call is that the next automated call is not then scheduled 24 hours + fudge factor minutes after that last manual call. Instead regardless of the making of the manual call the auto call scheduled by Tivo often decides it is still going to run in say 5 or 6 hours at the originally scheduled time - this being the time Tivo had originally scheduled for an auto call.

So unless I have missed something by making a manual call at the same time every day using cron and this script you are not going to prevent the automated call from still running at the time that Tivo feels like running it.

Thus intervening directly in the scheduling of the automated call is probably the only way to achieve what you actually want to do. However as you have indicated this is likely to be more tricky to accomplish.

Could I perhaps suggest your energies are diverted to a more worthwhile and more readily achievable objective - namely the archiving of all of a user's thumbs ratings over time for all their Tivo series and the ability to restore those thumb rating values in the event of total hard drive failure.


----------



## ColinYounger (Aug 9, 2006)

TCM2007 said:


> It's not a .itcl file, it's a .tcl file.


I embrace pedantry.

My understanding of the difference is obviously wrong - educate me, oh master.


----------



## ColinYounger (Aug 9, 2006)

rickynumber18 said:


> How do I schedule it in cron


The first question is: have you got cron installed?

Look for /var/hack/cron.

If not, there's an installation guide here but for the sake of your sanity (and ours) it might be worth waiting a little if you don't understand those instructions. I don't want to be responsible for helping you break your TiVo!


----------



## ColinYounger (Aug 9, 2006)

Pete77 said:


> My experience of getting Tivo to make a manual call is that the next automated call is not then scheduled 24 hours + fudge factor minutes after that last manual call.


In your experience using what?

The reason I say that is part of the 'call home' routine I trigger schedules the next call:

```
Apr 27 06:23:12 (none) tcphonehome[133]: setting next attempt at 1177740972 (Sat Apr 28 06:16:12 2007 )
```


----------



## Pete77 (Aug 1, 2006)

ColinYounger said:


> In your experience using what?


When my ADSL router has crashed or lost sync with provider while I am away and I trigger the daily call manually in the phone menus on the Tivo I notice that the next automated call after the manual call has completed is still at its originallly scheduled time.


----------



## Pete77 (Aug 1, 2006)

ColinYounger said:


> I embrace pedantry.


And paper bags.


----------



## iankb (Oct 9, 2000)

ColinYounger said:


> My understanding of the difference [between .tcl and .itcl] is obviously wrong ...


TCL is not object-orientated. ITCL (or 'incr TCL') is an extension that adds object-orientation to the TCL language.

Basically, it allows code modules to be added to TivoWeb that are encapsulated to the extent that nothing that is internal to them (such as variable names, etc) will conflict with those in any other code module.

Standard .tcl scripts do not use .itcl, since their methods do not belong to any object.


----------



## ColinYounger (Aug 9, 2006)

Thanks, Ian. I was nearly there then - I understood itcl to be TCL with object extensions, but my wonky thinking came in where I figured that the TiVo specific bits were the objects. So calling TiVo events (in this case) was not pure tcl in my weird world.

So would scripts that use dboj be itcl?

So much to learn, so little time.


----------



## ColinYounger (Aug 9, 2006)

Pete77 said:


> Could I perhaps suggest your energies are diverted to a more worthwhile and more readily achievable objective - namely the archiving of all of a user's thumbs ratings over time for all their Tivo series and the ability to restore those thumb rating values in the event of total hard drive failure.


Pete - this paragraph has been bugging me all day. So much so, I have to blow some steam.

1) I'll decide what to expend my energies on, thanks.

2) I'll also decide what's worthwhile.

3) I don't use thumbs, so I don't care about backing them up.

4) It's not readily achievable. If you'd even bothered to do a modicum of research you would have found this post at the bottom of the page.

So stop banging on about it or go and research it yourself. You've got the spare time after all.

Thanks for listening.


----------



## iankb (Oct 9, 2000)

ColinYounger said:


> So would scripts that use dboj be itcl?


I've never tried programming in Tcl, so I'm probably not the one to ask. I'm waiting for Stuart to step in and tell me I'm talking complete b*llocks. 

I assume that $dbo*b*j (if that's what you meant) is provided by tivosh, and since it is accessible from the main httpd-tt.tcl script, the difference in the way that TivoWeb uses .tcl and .itcl appears to be a bit fuzzy. Either running as an .itcl just provides a private namespace in which the included functions run, or TivoWeb simply uses .itcl as just a way of indicating an 'included' script file. Certainly, the code within the .itcl modules does not have any explicit object-based structure.


----------



## ColinYounger (Aug 9, 2006)

Well, we've obviously read the same definitions albeit I understood it differently. 

I haven't seen any true 'object' (i)TCL code myself (yet), but I've seen stuff that works *like* an object - e.g. you can obtain properties from them and they act as individual entities. Having worked in a few different environments I've got a bit laissez-faire about what constitutes an 'object oriented' language nowadays and left those arguments to the puritans. 

[EDIT] I realise my phrasing above contradicts embracing pedantism, but I try to be pedantic with the environment I'm in - i.e. I try to adopt the style of the area. My point above is that I don't bother entering into arguments like 'ITCL isn't true object oriented because <blah> C++ <blah> <blah>'.

PS. I win the monthly prize for most use of pedant and derivatives in one sentence.


----------



## iankb (Oct 9, 2000)

Although there might be some implicit object created by placing code within a separate file, and giving it an .itcl extension, I would still expect there to be some explicit differentiation between public and private methods and properties, to indicate what is made visible on the surface of the object. I don't see anything like that within the TivoWeb modules.

A little knowledge is a dangerous thing, but it allows you to call yourself a consultant.


----------



## Pete77 (Aug 1, 2006)

ColinYounger said:


> Pete - this paragraph has been bugging me all day. So much so, I have to blow some steam.
> 
> 1) I'll decide what to expend my energies on, thanks.
> 
> ...


Colin,

I should have put various smilies against that post. You shouldn't have taken me too seriously as I was only trying to pull your leg a little.  

My main point was that being able to have the daily call happen at the same time each day doesn't seem that important an extra facility to most of us.

However very many thanks for adding the better Web Remote in TivoWeb which I think will be usefull to many Tivoweb users. You really ought to add that hack as an entry on the Wiki Tivo page.

I imagine the biggest problem with Thumbs, even if you could at least back them up would be to reimport them in a fashion that TivoWeb accepts and doesn't reject like some unwelcome invasive organism.

It seems the only solution to back up thumbs is in fact to pull the drives and take a new image every 6 months as the basic Tivoweb system image does include the thumbs data as I understand it.

I'm sorry that my mastery of words is great than my coding skills. However some are born to write computer program code and some are not in my experience and opinion. I have tried it and found I am really not that much good at it so would prefer to leave it to the experts such as yourself.

Apologies once again for riling your normally placid self.


----------



## mikerr (Jun 2, 2005)

Summary of the thumbs problem from the above thread - there wasn't a problem restoring thumbs, just getting tivo to notice changes. 


LJ said:


> angra said:
> 
> 
> > hi, I tried to do thumbs, and I could reliably restore the thumbs themselves but it never seemed to impact the suggestions engine.
> ...


It seems noone could figure out that event, so it was a dead end.

Back to the topic (daily call at a specific time ): it doesn't really matter if a call occurs in between these forced calls, as the point of the script is to ensure the database is full updated at a particular time...


----------



## TCM2007 (Dec 25, 2006)

ColinYounger said:


> I embrace pedantry.
> 
> My understanding of the difference is obviously wrong - educate me, oh master.


I believe that in the grand scheme of things ITCL is the object oriented version of TCL, but in the context of TiVo and TiVoweb, the .itcl extension indicates that the file is a snippet of TCL code which is loaded by a master TCL script. It's not a runnable script in its own right.

TCL has a nifty property whereby you can tell it to treat any given block of text or file as code rather than data and run it, TiVoweb uses this to load the modules at startup.

I'd guess the "i" stands for "include" in this context.


----------



## Pete77 (Aug 1, 2006)

mikerr said:


> Back to the topic (daily call at a specific time ): it doesn't really matter if a call occurs in between these forced calls, as the point of the script is to ensure the database is full updated at a particular time...


Except that the automated call may be the one grabs the data and therefore does the re-indexing rather than the manually initiated call.

Which leads us on to what time each day does Tivo may available a fresh day's set of data. Ideally one wants the forced call to be made half an hour or so after that fresh data set is made available.


----------



## TCM2007 (Dec 25, 2006)

ColinYounger said:


> Well, we've obviously read the same definitions albeit I understood it differently.
> 
> I haven't seen any true 'object' (i)TCL code myself (yet), but I've seen stuff that works *like* an object - e.g. you can obtain properties from them and they act as individual entities. Having worked in a few different environments I've got a bit laissez-faire about what constitutes an 'object oriented' language nowadays and left those arguments to the puritans.
> 
> ...


TCL isn't object oriented, but the MFS database is - hence TiVo TCL can look fairly OOP-y.


----------



## TCM2007 (Dec 25, 2006)

Pete77 said:


> Except that the automated call may be the one grabs the data and therefore does the re-indexing rather than the manually initiated call.
> 
> Which leads us on to what time each day does Tivo may available a fresh day's set of data. Ideally one wants the forced call to be made half an hour or so after that fresh data set is made available.


I've already told you how to solve this above. Out with your book and get coding Pete!


----------



## Pete77 (Aug 1, 2006)

Colin,

I'm now running your tcl call script daily from Cron and have observed the following behaviour.

Initially when the daily call is called by Cron starting the tcl program the Next Scheduled Call time does not become 24 hours + fudge factor after the time at which Cron kicks off the call but remains at the original time that Tivo was going to make the call of its own accord. This then remains the case indefinitely so long as one's Tivo is not rebooted.

However when one finally reboots one's Tivo one finds that Hey Presto the next scheduled call time is 24 hours + fudge factor after the last Cron kicked off TCL instructed dialup time. So as Cron will make the next call just before Tivo tries to make the call itself hopefully the call will continue to be made at around 2am in GMT hours and 3am during BST hours every day as I have instructed it to.

This does lead to the big question though which is when do Tivo normally make available a new day's data set bearing in mind they are 8 hours behind in California? This was where my 2am/3am GMT/BST call time seemed like a good idea apart also from no nieces or nephews being around to turn off the power on my Tivo while it is reindexing at that time of day.

What have your own continued experiences been as no one else seems to have followed up on your thread and you did now claim your Tivo was making its daily call several times a day.

Also on another interesting point iankb maintains his Tivo never used to call in daytime hours and always used to skip from early morning to evening as the fudge factor advanced the call time. Yet my automated calls always happen between about 8am and 6pm and never at night. This rather suggests that different Tivos are in fact told to call in during different call time windows to balance the total load on the Tivo servers and that this is more important to them than minimising phone call cost (which may in any case be a fixed price per call regardless of time depending what they have agreed with their telecoms supplier).

How are you finding things now. Is your Tivo still making several calls a day or have you rebooted it and find that it now only makes the one call a day at the time triggered by the Cron initiated TCL script?

I look forward to your comments.


----------



## ColinYounger (Aug 9, 2006)

Pete,

As I observed earlier in the thread, my automatic daily call was suddenly scheduled to before the cron'd one. Due to log rotations, etc I never found out why but your message is interesting in that perhaps my TiVo rebooted and gave a new auto-time. An imponderable however.

The behaviour the next day was interesting, though - as the TiVo developers foresaw something like this. My TiVo did it's automatic call and then reported that it had already called 'recently' when the cron'd call kicked off. It didn't make the call, but TiVo then re-adjusted itself and I've always had scheduled auto calls about 2-5mins after my scheduled time since then.

So in answer to the 'many calls per day' question - no, I'm only seeing one call a day, as per the first week of my trying this out.

As for when the data is available - no idea. I've not looked into it. I would imagine OzTivo would know, though. 

On the times that the auto call is scheduled, I can see how they would want to traffic shape so that UK users only call during daytime as the recent posts about guide data suggest that the data is held on US-based systems (i.e. we call during their night). But iankb's experience reported by you seems different. FWIW, my TiVo seemed to be obsessed with the 12pm-4pm call time.

I suspect that unless we reverse engineer the daily call process (like the Australians have), we'll only be able to speculate. I would suggest that it's likely to be really simple and nothing more than a random time as most of the TiVo stuff I've looked at so far is amazingly elegant in it's simplicity.


----------



## TCM2007 (Dec 25, 2006)

Am I missing something, but if you're on a network connection via broadband, why do you care when the call is made?


----------



## Pete77 (Aug 1, 2006)

ColinYounger said:


> The behaviour the next day was interesting, though - as the TiVo developers foresaw something like this. My TiVo did it's automatic call and then reported that it had already called 'recently' when the cron'd call kicked off. *It didn't make the call, but TiVo then re-adjusted itself and I've always had scheduled auto calls about 2-5mins after my scheduled time since then*.
> 
> So in answer to the 'many calls per day' question - no, I'm only seeing one call a day, as per the first week of my trying this out.


So far as I can tell the Tivo has now settled in to a routine where its automated call is scheduled to run a few minutes arfter the cron initiated call at 3am and the automated call then doesn't get made as a result and is instead scheduled for just after 3am the next day. This in fact equates to Tivo's normal behaviour when it has found the phone line unavailable to it for some reason where it does then reschedule the call for one day later.

However I am seeing apparently odd behaviour with my last Garbage Collection (GC) and Guide Data Indedx which do not appear to be updating to times not long after the daily call as one might expect and are remaining stuck back in the past by a day or two. But on the other hand my last Guide Index and GC were stuck back on last Sunday before I rebooted yesterday and yet I only installed your script to manually kick off the call from Cron on Saturday. So this may be an unrelated database confusion issue that may perhaps require a full Guided Setup run to resolve. As things stand I haven't done a Guided Setup on the Tivo for almost 2 years.

Its disappointing to have so little feedback from other users on this new forced phone call utility thus far. I would have thought quite a few Daily Mail users would be keen to have a call only an hour or so before cron and Daily Mail produces its email.


----------



## Pete77 (Aug 1, 2006)

TCM2007 said:


> Am I missing something, but if you're on a network connection via broadband, why do you care when the call is made?


So that the data on the Tivo is the latest available at the time that the DailyMail email is produced. But this is why it then becomes crucial to know when the latest day's UK Tivo EPG data normally becomes available.


----------



## TCM2007 (Dec 25, 2006)

The data you mostly use a s a Sky-phobe is only updated once a week. Midweek corrections do occur, but not often and having one less than 24hrs before broadcast would be rare.

I have never heard of a TiVo missing a recording because an update didn't arrive in time.

I don't know how Tribune works this, but while I would expect the main upload to be on a schedule, ad hoc changes may just be added as-and-when.


----------



## ColinYounger (Aug 9, 2006)

TCM2007 said:


> why do you care when the call is made?


I want my TiVo to call the mothership at the same time every day - so that my DailyMail email stops giving false positives on items TiVo is going to record (or even rejected recordings) due to inaccurate guide data on channels that mostly have placeholders rather than real data.

There's also a couple of other reasons which basically involve me being anally retentive.


----------



## TCM2007 (Dec 25, 2006)

Pete77 said:


> Its disappointing to have so little feedback from other users on this new forced phone call utility thus far. I would have thought quite a few Daily Mail users would be keen to have a call only an hour or so before cron and Daily Mail produces its email.


Perhaps most people are happy with it as it is!

I wouldn't recommend setting this up to run an hour before DailyMail if that's what you're trying to achieve. Indexing can take longer than that.


----------



## TCM2007 (Dec 25, 2006)

ColinYounger said:


> I want my TiVo to call the mothership at the same time every day - so that my DailyMail email stops giving false positives on items TiVo is going to record (or even rejected recordings) due to inaccurate guide data on channels that mostly have placeholders rather than real data.
> 
> There's also a couple of other reasons which basically involve me being anally retentive.


You must have DailyMail set to view a LONG time into the future to get that. there should be no placeholders until you get over 7 days out.


----------



## ColinYounger (Aug 9, 2006)

Just to clarify - I have the 72 hour DailyMail. An example false positive is 'Two and a half men' which Dailymail used to report as going to be recorded every day - but once the call had been made and the todo list re-done, the episodes would be removed as duplicates.

I might have barked up the wrong tree in assuming it's the daily call that makes the difference, but in my case it does.


----------



## TCM2007 (Dec 25, 2006)

ColinYounger said:


> Just to clarify - I have the 72 hour DailyMail. An example false positive is 'Two and a half men' which Dailymail used to report as going to be recorded every day - but once the call had been made and the todo list re-done, the episodes would be removed as duplicates.
> 
> I might have barked up the wrong tree in assuming it's the daily call that makes the difference, but in my case it does.


I have full episode data for all next week for that show?


----------



## Pete77 (Aug 1, 2006)

Currently Tribune is making a lot of listings errors which are often only being corrected at the last minute thanks to Ozsat's intervention. Thus the more up to date my Tivo data can be in relation to DailyMail the better. Also for your information as a blinkered lifelong Sky subscription payer we Freesatters do have access to quite a number of FTA satellite channels for which up to three weeks of data are available in the same way as those you who like to feel rich by paying for your Sky channels.   

As it happens I'm leaving a 4 to 5 hour gap between the Daily Call and Daily Mail but that's still a lot better than the gap of up to 22 hours that would otherwise often occur. The other reason I like the idea of a call at a set hour of the morning is so that Indexing doesn't ever take place at a time of day when my Tivo might accidentally reboot due to it being overtaxed by a Tivoweb program request and/or by my nephew or niece or anyone else accidentally turning off the power.

On top of all that I like the idea of regularising the time of day of the call just because Colin has made it possible for us to do so. I expect the just because I can do it reasons are the ones Colin refers to as being anally retentive.


----------



## ColinYounger (Aug 9, 2006)

TCM - intriguing. But perhaps our definition of full data is different.

My Tivo certainly wanted to record tonight's two showings at 8.30pm/9pm which we (Tivo and I) have 'seen'. After the daily call today it disappeared - while I accept that guide data was wonky over this weekend, it's the general pattern I see. Episodes appear that should be recorded and disappear (typically) 24<=48 hours before the showing - but ONLY after a daily call.

But at the end of the day - it works for me. I was only sharing, not mandating.


----------



## Pete77 (Aug 1, 2006)

ColinYounger said:


> TCM - intriguing. But perhaps our definition of full data is different.
> 
> My Tivo certainly wanted to record tonight's two showings at 8.30pm/9pm which we (Tivo and I) have 'seen'. After the daily call today it disappeared - while I accept that guide data was wonky over this weekend, it's the general pattern I see.


This is also the pattern I see with things like Never Mind The Full Stops on BBC Four which Tivo initially believes it needs to record all three weekly showings of. Then near transmission date it no longer believes this.

Another advantage of nailing down your daily call and Indexing (which on my Sky Freesat and Freeview setup is always complete within 2 hours of the daily call taking place) to a set time is it then makes it possible to consider scheduling a periodic "reboot" or "restart" (have yet to discover which is safer) from Cron say once or twice a week in order to counter the phenomenon of Tivoweb 1.9.4 gradually causing memory corruption that leads to an eventual memory overflow and reboot. Now I accept that this is of course in turn only particularly necessary in my case due to the large number of items in my Now Playing. However I wouldn't have wanted to schedule a reboot for 3am a couple of times a week if there was a possibility this might be in the middle of of data indexing after a daily call or even the garbage clearance (GC) cycle (which again can now be pinned down to happening in a certain timeslot window).

So there do seem to be definite reasons why some of us would like to pin down our daily call to happening at a set time of day even if for most of you it appears to make no difference.


----------



## TCM2007 (Dec 25, 2006)

Pete77 said:


> The other reason I like the idea of a call at a set hour of the morning is so that Indexing doesn't ever take place at a time of day when my Tivo might accidentally reboot due to it being overtaxed by a Tivoweb program request and/or by my nephew or niece or anyone else accidentally turning off the power..


Nothing bad happens in that case . It just starts indexing again.

Is your TiVo really that fragile that it falls over when you use TiVoWeb?


----------



## Pete77 (Aug 1, 2006)

TCM2007 said:


> Is your TiVo really that fragile that it falls over when you use TiVoWeb?


Yes only me and all the other users who have the same problems with TivoWeb making the machine fall over and reboot the machine from time to time.

Simple changes of season pass order or setting up a single recording don't tend to cause the reboot. It is more complex utilities like Search by Advisory Codes, Highlights etc that in the end tend to kick off a reboot. But only if you run quite a number of more demanding operations sequentially.

By comparison TivoWebPlus 2.0 has been specifically evolved to handle the rebooting issue through adopting different database structures so if it was just me who had these issues then presumably its developers wouldn't have bothered going to all this trouble?


----------



## TCM2007 (Dec 25, 2006)

TiVoWeb Plus was developed for a number of reasons, mostly to support the dual tuner TiVos running software 4 and over which 1.9.4 didn't do effectively.

My understanding was that TWP 2 was developed to cure instability problems with large channel line ups in TWP 1, not large NP lists - have you sneakily subscribed to all the Sky channels Pete?

Must say I've never rebooted the Tivo by using TW 1.9.4 on any of my machines, some of which are fairly heavily loaded (200+ items). 

Hadn't looked at TWP 2 much; nice to see some of my and Mr Tickle's work included as standard!


----------



## Pete77 (Aug 1, 2006)

TCM2007 said:


> My understanding was that TWP 2 was developed to cure instability problems with large channel line ups in TWP 1, not large NP lists - have you sneakily subscribed to all the Sky channels Pete?


The developers of TWP2 assure me that it is the number of channels on the channel platform(s) you have selected that introduce the instability in TW 1.9.4 and TWP 1.3.1 and earlier versions and that the proportion of the channels that you have selected in Channels I Receive is irrelevant. And since I actually have a dual platform Sky Digital television and Freeview setup I possibly have a more demanding channel lineup than you do?

As to the number of items in Now Playing I think having 600+ impacts on everything resource wise in a big way and since TWP 1.9.4 and TW 1.3.1 was already unstable with channel packages with larger numbers of channels this Now Playing list size hardly helps.

I can't speculate as to why your Tivo never reboots under Tivoweb as loads of other people with large channel lineups who use it regualrly on more demanding apps like Highlights and Search by Advisory Code find that spontaneous reboots do happen.


----------



## TCM2007 (Dec 25, 2006)

Pete77 said:


> I can't speculate as to why your Tivo never reboots under Tivoweb as loads of other people with large channel lineups who use it regualrly on more demanding apps like Highlights and Search by Advisory Code find that spontaneous reboots do happen.


Don't know. I use some high demand ones (like the Digiuide modules), but I've never installed the Search for Porn, sorry, Search by Advisory Code one.

Can't say I've noticed many (any?) other people than yourself suggesting it was a problem.


----------



## Pete77 (Aug 1, 2006)

TCM2007 said:


> Can't say I've noticed many (any?) other people than yourself suggesting it was a problem.


You should try the TWP2 thread.

For instance:-

http://www.tivocommunity.com/tivo-vb/showthread.php?p=4939525&&#post4939525


----------



## TCM2007 (Dec 25, 2006)

Pete77 said:


> You should try the TWP2 thread.
> 
> For instance:-
> 
> http://www.tivocommunity.com/tivo-vb/showthread.php?p=4939525&&#post4939525


Erm, that was one American saying that they'd had problems with older versions of TiVoWebPlus on a Series 2 TiVo.

I've not seen many/any suggestions other than your own that there is an issue with UK TiVos running regular TiVoWeb?


----------



## Pete77 (Aug 1, 2006)

Colin,

As you and I seem to be the only people who are anally retentive and/or control freakish (which is probably my condition) enough to want to control the time of the daily call it seems we aren't going to get much feedback from the others. This is even though I personally consider this a hack worthy of addition to the Wikipedia Tivo hacks Guide if it is reliable.

Anyhow I just wanted to report as follows:-

A. The forced daily call seems to be going fine with it making the call every day at 3am and the next call then being scheduled for 3.01am or 3.02am the next day, which is then pre-empted by Cron kicking off your script for the next forced call at 3am the next day.

B. However a very bizarre thing that is happening is that for so long as my Tivo continues running and does not soft reboot the Phone module in TivoWeb continues to show Last Garbage Collection and Last Guide Data Index settings that do not advance and stay back on the dates that were reported in Tivoweb on the last day the machine soft rebooted. However if I go in to System Information on the Tivo Central menu using the remote the usual way I find GC and Indexing are correct and show as updated in the last 24 hour cycle. Meanwhile "Guide Data To" shown by Phone in TivoWeb shows one day behind the day Guide Data is available to in Tivo telly System Information but is at least advancing one day each day. All this gets completely corrected in TivoWeb Phone when I reboot my Tivo but then the data shown in TivoWeb phone starts to fall behind again. The obvious remedies like Reloading the TivoWeb page or even completely clearing the Firefox Cache do not fix the problem.

For instance at the moment my Tivo Central System Information shows "Program Guide Data To" of Sunday 10th Jun 2007 but TivoWeb Phone shows "Guide Data To" of Saturday 9th Jun 2007. And Tivo Central System Information shows a "GC:" of Saturday 19th May at 9.46am and Indexing: of Sunday 20th May at 3.56am but TivoWeb Phone shows "Last Garbage Collection" of Tuesday 15th May at 21:11 and "Last Guide Data Index" of Wednesday 16th May at 03:38. The current "Uptime" of the Tivo is 4days 9hours 00minutes on Tivo Central System Information (no equivalent shown in Tivoweb Phone) which directly tallies with the 4 to 5 days for which TivoWeb Phone's "Last Garbage Collection" and "Last Guide Data Index" values are backdated. So as you can see there is some logic behind the outdatedness of the Tivoweb Phone values presented.

Worryingly User Interface/To Do in TivoWeb also only shows programs scheduled until this Tuesday 22nd May and Tivo Telly's To Do list is in full agreement with this. Sheduled Suggestions in Tivoweb also only run to Tuesday 22nd May and yet Suggestions in TivoWeb User Interface run as far as 6th June. Now the reason quoted in View Recording History from Tivo Central is that there won't be enough space to record the program but Daily Mail says I have over 70 hours left assuming it can reallocate space from all Expired programs (I now have quite a few SPs for things I am only moderatly keen on that are Space Needed and/or only keep 1 episode). Now I admit my Tivo is pretty full at the moment so it could be the Tivo or DailyMail has miscalculated the amount of space that is still available because one of them hasn't factored in the use of VBR instead of expected CBR in all the recordings.

OK so I admit my To Do shortness problem may have another cause but there is no doubt that using your forced Phone dialling script is definitely causing TivoWeb Phone not to stay up to date and in sync with data reported on Tivo Central System Information. So this suggests to me that your script's method of kicking off the daily call doesn't cause all the relevant TivoWeb call registers to activate and for some reason TivoWeb Phone then accesses old out of date records of the last Garbage Clearance and Gude Data Index.

Have you also observed this situation with the out of date TivoWeb Phone data and do you think it is anything to worry about or can safely just be ignored?

Of course this does give me another reason for seeing if I can force Tivo to reboot once a day from Cron at a safe time like 7am when I am never ever recording anything (only breakfast tv, kids programs, OU programs and repeats of old programs on most channels).


----------



## ColinYounger (Aug 9, 2006)

Pete - I'll try to digest this and come back in the next couple of days (bit busy at the mo), but I'm wondering if your time of call has bearing here. For a test, try changing the time to something like 7am and see what happens.

Why? My GC and GI times tend to be around midnight-3am and I'm wondering if your forcing the call at the time you do stops TiVo doing it's thing when it wants to. AFAICT, GC & GI are different processes than the call process, and scheduled by Linux (GC) and TiVo (GI).


----------



## Pete77 (Aug 1, 2006)

ColinYounger said:


> Why? My GC and GI times tend to be around midnight-3am and I'm wondering if your forcing the call at the time you do stops TiVo doing it's thing when it wants to. AFAICT, GC & GI are different processes than the call process, and scheduled by Linux (GC) and TiVo (GI).


Colin,

My experience of Tivo use is that Indexing (GI) is related to the last Successful Call and is kicked off immediately after the daily call finishes and is completed within 2 hours of it at the most. Whereas Garbage Clearance is independent of the daily call and occurs once in each 24 hour cycle at any point that Tivo has probably predicted as being a quiet time. I agree that is often or mainly overnight, unlike the automated daily call and the Indexing that follows it that virtually always took place between 7am and 9pm UK time when my Tivo chose the time.

I expect my previous post was too long but the point I was making was that GI and GC are up to date and show as within the last 24 hours on Tivo Central/System Information but their counterparts shown by TivoWeb/Phone were stuck back on the last day the Tivo did a soft reboot. This suggests Tivoweb/Phone looks up some different values to report its data from Tivo Central/System Information and that the TivoWeb/Phone values are only updated on a soft reboot.

To be honest I think the problem is just that Tivoweb/Phone is getting its data from some place on the Tivo that is only updated by a soft reboot and is not the same place that Tivo Central/System Information gets its data for these values.

Ignore my points about To Do and Scheduled Suggestions only running for a couple of days in the future as my Tivo was almost completely full up with Keep Until I Delete programs after nearly 2 years of hording programs following my uprating of it to 613 hours of Basic capacity (or 603 hours with the enlarged Live Buffer)! For some reason DailyMail over reports the amount of free space still remaining on the Tivo when it is nearly ful upl. I think others have reported this in the DailyMail thread but I don't think there is a solution. I suspect using VBR and/or my 3 hour Live Buffer (consuming an extra 10 hours of Basic recording time the Tivo won't be expecting) may be connected with that issue.

So I will reschedule the time of forced Cron initiated daily call to day to see if there is any difference but I highly doubt that this is the issue.

Did you check your TivoWeb/Phone data to see if it tallied with the same values in Tivo Central/System Information?


----------



## ColinYounger (Aug 9, 2006)

Dashing through...

I did understand the point was the reporting of the dates and times, but what I didn't say (and you subsequently asked) was that my Tivoweb and Tivo agree on the GC\GI dates and times.


----------



## Pete77 (Aug 1, 2006)

ColinYounger said:


> I did understand the point was the reporting of the dates and times, but what I didn't say (and you subsequently asked) was that my Tivoweb and Tivo agree on the GC\GI dates and times.


OK thanks for that.

I will try changing the call times and see what happens.


----------



## TCM2007 (Dec 25, 2006)

Pete77 said:


> I expect my previous post was too long but the point I was making was that GI and GC are up to date and show as within the last 24 hours on Tivo Central/System Information but their counterparts shown by TivoWeb/Phone were stuck back on the last day the Tivo did a soft reboot.


Sounds like a possible bug in the Phone module then. Suggest you take a look at the code.


----------



## Pete77 (Aug 1, 2006)

TCM2007 said:


> Sounds like a possible bug in the Phone module then. Suggest you take a look at the code.


Good suggestion and yes it does seem to look that way as the calls are being made and the data downloaded and Indexed OK.

Interesting though that Colin doesn't get the problem with a forced call at a different time of day.


----------



## Pete77 (Aug 1, 2006)

This seems to be the section of the phone.itcl module which extracts the data but I can't really understand enough to see why these two data items are not extracting current data:-



> set CD_las $PHInfo(LastCallStatus)
> 
> puts $chan ""
> puts $chan [html_table_start "" "" ""]
> ...


----------



## ColinYounger (Aug 9, 2006)

Actually, you'll find that the information is in MFS:

```
DatabaseState 23535/10 {
  Version        = 1424
  VersionMajor   = 4
  VersionMinor   = 40
  GcCompletionDate = 13654
  GcCompletionTime = 82206
  GcIndexCompletionDate = 13655
  GcIndexCompletionTime = 19932
  IndexPath      = /State/Database
}
```
You can then decode that date via a shell:

```
TiVo: {/var/hack} % tivosh
% clock format [expr 13654 * 86400 + 82206]
Mon May 21 22:50:06 localtime 2007
% exit
TiVo: {/var/hack} %
```
Note that the time is expressed in GMT.


----------



## Pete77 (Aug 1, 2006)

ColinYounger said:


> Actually, you'll find that the information is in MFS:
> 
> ```
> DatabaseState 23535/10 {
> ...


Dear Colin,

I think you are teasing me as you know that I'm not a programmer and just a demanding user with some interpretative and analytical skills.

However I was able to bring the GC and GI reported information up to date by using Hackman to change to TivoWebPlus 2.0 (in which the Phone module didn't even work at all but quit with loads of error messages) and then by doing a complete quit of TivoWeb and Restart (an option in TivoWebPlus 2.0).

I then changed back to TivoWeb 1.9.4 using Hackman from TivoWebPlus 2.0 and voila the data was updated correctly for GC and GI in TivoWeb 1.9.4 Phone. Meanwhile the Tivo itself had not been rebooted and has an Uptime of over 5 days.

This suggests to me that a problem in TivoWeb's reading of this information was actually taking place. Of course that is probably in part triggered by the way the Daily Call itself is now made, even though Tivo's own software and MFS seems to find that altered method of making the call acceptable.


----------



## ColinYounger (Aug 9, 2006)

Pete - not trying to tease at all, just fly-by posting. 

To use interweb speak: Life iz hektic. Stealin my timez. 

The info I've given you shows you how the phone tivoweb module gets it's dates. Therefore next time you see out of sync dates, you can check for yourself what TiVo thinks.


----------



## ColinYounger (Aug 9, 2006)

Oh - another fly-by. Next time you see the problem, press CTRL-F5 on your browser to see if you get different figures.


----------



## Pete77 (Aug 1, 2006)

ColinYounger said:


> Oh - another fly-by. Next time you see the problem, press CTRL-F5 on your browser to see if you get different figures.


I already said that Reoading or Refreshing my Browser or clearing the Cache made no difference.


----------



## ColinYounger (Aug 9, 2006)

Pete - humour me.


----------



## Pete77 (Aug 1, 2006)

I changed the Cron script call time to 3pm (figuring that would be immediately after the 8 hour behind overnight update of Tivo servers in the US with new EPG data) and will see how that goes in terms of Tivoweb not haveing a headache on the Phone GC and GI dates & times.

It wasn't a one off as it did it before then I rebooted Tivo, which then updated to the correct values in TivoWeb Phone, and then the data started falling behind again..................


----------



## ColinYounger (Aug 9, 2006)

Any news, Pete?


----------



## Pete77 (Aug 1, 2006)

ColinYounger said:


> Any news, Pete?


Changing the time of day the Daily Call is made didn't help at all and TivoWeb Phone starts falling behind on the reported GC and GI And Guide Data Until dates within a day. However fully quitting TivoWeb 1.9.4 and then restarting it at the bash prompt in the /var/hack/tivoweb-tcl directory with ./tivoweb causes the information to be updated to the correct latest information that matches the GC and GI data in System Information. A full soft reboot of the Tivo also achieves the same result but the data then starts falling behind again.

Of course now you will tell me you want me to get Cron to stop making a forced daily call and to return to the automated Tivo selected call time to see if TivoWeb/Phone also falls behind then. However I reguarly used TivoWeb/Phone before when thinking of rebooting manually to check that no Indexing was going on from a recent phone call and I never found the call data to be stuck in the past then. So it appears something about the way the forced call is kicked off causes the data on GI and GC in Tivoweb Phone not to be updated, even though it is updated in Tivo Central/System Information.

Since the calls are happening and the database updating I suppose you would advise just ignoring Tivoweb/Phone. All I can say is that TivoWeb Phone used to work 100% accurately and something has changed that upsets it.

I would note that I can't get TivoWebPlus 2.0 Phone to report any data at all for Phone and instead it just crashes with a string of error messages. But then as several other TivoWebPlus 2.0 modules still do that I can't say that means anything other than poorly bug tested software that doesn't like S1 Tivos.


----------



## ColinYounger (Aug 9, 2006)

Pete,

With the dates out of whack:

1) Did you try CTRL-F5? It MUST be CTRL-F5, not just F5.
2) Did you look at the MFS entries?

It's important that you do.


----------



## Pete77 (Aug 1, 2006)

ColinYounger said:


> Pete,
> 
> With the dates out of whack:
> 
> ...


CTRL-F5 didn't help as I thought I already reported yesterday.

Unfortunately I only just worked out how to use your direct MFS link to that section of the database but following my Tivoweb restart everything is currently up to date. We have to wait a couple of days for it all to fall behind again and then use the link to that section of MFS and report the data to you.

The data currently shows as below in MFS but as I say Tivoweb/Phone has not yet fallen behind following the restart earlier today:-



> DatabaseState 12867/10 {
> Version = 3033
> VersionMajor = 4
> VersionMinor = 40
> ...


I notice my Version is 3033 and yours is 1424. What does this imply?


----------



## TCM2007 (Dec 25, 2006)

Pete77 said:


> I notice my Version is 3033 and yours is 1424. What does this imply?


That you've had your TiVo longer. It increments every time the database is updated.


----------



## Pete77 (Aug 1, 2006)

TivoWeb/Phone information is now out of data again compared to Tivo Central/System Information and *using CTRL+F5 does not fix the problem.*

MFS shows:-



> DatabaseState 12867/10 {
> Version = 3036
> VersionMajor = 4
> VersionMinor = 40
> ...


But I have this in TivoWeb/Phone

Last Garbage Collection:- Wednesday 23rd May at 13:54
Last Guide Data Index:- Wednesday 23rd May at 17:56
Guide Data To:- Wednesday 13th Jun 2007

And this in Tivo Central/System Information

GC: Thursday 24 May at 10:49 am
Indexing: Thursday 24 May at 5:38 pm
Programme Guide Data to: Thursday 14 Jun 2007

They both agree on Next Scheduled Call, Last Successful Call and Last Call Attempt.

Basically GC, GI and Guide Data To will now become more and more out of date in TivoWeb Phone until I completely stop and quit Tivoweb and then restart it from the bash prompt.


----------



## ColinYounger (Aug 9, 2006)

Pete77 said:


> GcCompletionDate = 13657
> GcCompletionTime = 35345


That's Thu May 24 09:49:05 localtime 2007


Pete77 said:


> GcIndexCompletionDate = 13657
> GcIndexCompletionTime = 59916


That's Thu May 24 16:38:36 localtime 2007

In other words, correct. So - the Tivoweb phone module is caching the data (or at least, not refreshing the info). Now we need to work out a) why, and b) why mine does show the right info.

I'm off to cub camp today, so won't be able to look until at least Tuesday. Get your detective hat on, Pete!


----------



## AMc (Mar 22, 2002)

ColinYounger said:


> I'm off to cub camp today


Younger by name and Younger by nature - no wonder you keep a bag on or we'd all know you're just a kid


----------



## bigwold (Jun 4, 2003)

Pete77 said:


> Its disappointing to have so little feedback from other users on this new forced phone call utility thus far. I would have thought quite a few Daily Mail users would be keen to have a call only an hour or so before cron and Daily Mail produces its email.


First time I'd read this thread all the way through so only just found this. 
Perhaps it's because we're using LJ's daily_call.tcl?


----------



## ColinYounger (Aug 9, 2006)

Dang. There's me thinking I had finally found something to do others hadn't.


----------

