Tivo Control Station 1.1.2

[Zirak]

This release fixes several modules, adds support for starting/restarting tivoweb on a port over than the standard 80, adds an improved auto-update function, as well as other miscellaneous and sundry fixes and improvements.

Why upgrade? The auto-update function now understands the "preferred" place where a module should run if you are running a network server. This should make updates seamless for "reasonable" configurations. Changes to the auto-update function also mean that module updates will no longer be available to earlier releases. I.E:

DUE TO IMPROVEMENTS IN THE AUTO-UPDATE FUNCTION, ALL PRIOR RELEASES OF TCS ARE OBSOLETE AND WILL NO LONGER RECEIVE UPDATES.

If you are unfamiliar with what TCS does, see the description as well as the screenshots on the website.

If you are upgrading from a version prior to 1.1.0, it is really an absolute must to read the README in its entirety. It may also be helpful to read the first post in the TCS 1.1.0 thread in this forum, as it gives a pretty good description of the major changes from 1.0.x to 1.1.0.

If you are upgrading from version 1.1.0 or later, you need to read the LICENSE. If you are very familiar with TCS and the directory structure, installation can be streamlined by copying over your IPAddresses and prefs files, and making some minor changes to prefs as so:

1) Copy over your config/IPAddresses file.
2) Rename the 1.1.2 config/prefs file to config/prefs.112
3) Copy over your config/prefs file, and edit as follows:

A) After the line with the path to tivoweb ADD:

tivowebdir TivowebDir <your path to tivoweb> (no trailing "/")

B) DELETE the SECOND occurrence of the following line (as it is a duplicate):

scheduler DSCHED 0

4) (already in 1.1.1) If you are running 1.1.0, copy 5 (I SAID FIVE) lines from config/prefs112.bak, starting with the line:

# Non-linux network server (Set for Cygwin/Mac OS, perhaps for other

and insert them after the line that contains "nsip"

5) If you don't understand these instructions it will be faster for you to just re-edit your paths in the release prefs file.

This is the new support thread.

Get it from the TCS Home Page

Tivo Control Station is copyright 2003, 2004, ZirakZigil, LLC.

[dgi]

NSNonLinux is set to 1, but I still get the following in the server's log:

bgerror failed to handle background error.
    Original error: couldn't open "/proc/loadavg": no such file or directory
    Error in bgerror: invalid command name "bgerror"

I get this when pressing 97-clear.

[dgi]

I experimented a little with the effects of 81-clear. If an Alaskan ZIP is entered, 82-clear fails with no error on the server, but the TiVo reports:

Not a JPEG file: starts with 0x42 0x4d

Pacific Island ZIP codes outside Hawaii are not accepted at all.

[Zirak]

Originally Posted by dgi

NSNonLinux is set to 1, but I still get the following in the server's log:

bgerror failed to handle background error.
    Original error: couldn't open "/proc/loadavg": no such file or directory
    Error in bgerror: invalid command name "bgerror"

I get this when pressing 97-clear.

Definitely a bug. Seems like I remember fixing this one before, so I either lost it, or have a bad memory. Got it fixed.

Unfortunately, the Timers module had a further bug in that it wouldn't register its version from the network server, which means auto-update wouldn't update it from there. I have that fixed too. To "goose" autoupdate to get the fixed version, delete tcs/modules/Timers.tcl, tcs/modules/modules/Timers.tcl, and tcs/modulesserver/Timers.tcl, and restart. This will force the download. This will NOT effect anyone who installs tcs after this date, and thus can be ignored by those people.

[Zirak]

Originally Posted by dgi

I experimented a little with the effects of 81-clear. If an Alaskan ZIP is entered, 82-clear fails with no error on the server, but the TiVo reports:

Not a JPEG file: starts with 0x42 0x4d

Pacific Island ZIP codes outside Hawaii are not accepted at all.

The format of the urls for those maps are different from those on the mainland. Some time ago someone in Hawaii pointed the problem there, and I special cased it in the code to make it work there. If you point out a few places (zips), I will see if there is a reasonable solution (no promises!). If someone using tcs actually lives in one of those places, I will look into making those locations special cases.

If you look at the jpeg file that is trying to be displayed, you will probably find it to be an html 404 page not found error.

[dgi]

Pacific Island ZIP codes include 96799, 96940, 96950, 96960, 96910, and 96943. Puerto Rico and the Virgin Islands already work perfectly. An example of an Alaskan ZIP code would be 99767.

[dgi]

Originally Posted by Zirak

Definitely a bug. Seems like I remember fixing this one before, so I either lost it, or have a bad memory. Got it fixed.

Unfortunately, the Timers module had a further bug in that it wouldn't register its version from the network server, which means auto-update wouldn't update it from there. I have that fixed too. To "goose" autoupdate to get the fixed version, delete tcs/modules/Timers.tcl, tcs/modules/modules/Timers.tcl, and tcs/modulesserver/Timers.tcl, and restart. This will force the download. This will NOT effect anyone who installs tcs after this date, and thus can be ignored by those people.

Apparently, it still isn't fixed. Now, whenever I press 97-clear, I get:

Bad Network Command: TVTM 1

[Zirak]

Originally Posted by dgi

Apparently, it still isn't fixed. Now, whenever I press 97-clear, I get:

Bad Network Command: TVTM 1

It sounds like the Timers module isn't loaded in the Network Server. I suppose that the tivo downloaded and installed the module for itself, but upon checking, the network server noticed the module already installed in modules/modules, so it didn't think it was "new". In the long term, I'm going to have to figure out how to manage new module installation, as this will be an ongoing problem for "new" modules.

Solve the problem by linking the module in for the network server:

cd modulesserver
ln ../modules/modules/Timers.tcl

and restart the network server.

[dgi]

OK, now Timers works, but some of the values are zero or negative. Perhaps this has something to do with the fact that since I went from 1.1.1 to 1.1.2, it keeps saying that the network seems to be down, and that no nameservers are responding, all the time. Clearly, the nameservers work, so why can't TCS seem to use them? If I manually enable greedy updates, weather does periodically change from blue to yellow, but the logs still say the nameservers don't respond. The load average on the TiVo is now really high, greedy updates or not, and stopples are plentiful.

[Zirak]

Originally Posted by dgi

OK, now Timers works, but some of the values are zero or negative. Perhaps this has something to do with the fact that since I went from 1.1.1 to 1.1.2, it keeps saying that the network seems to be down, and that no nameservers are responding, all the time. Clearly, the nameservers work, so why can't TCS seem to use them? If I manually enable greedy updates, weather does periodically change from blue to yellow, but the logs still say the nameservers don't respond. The load average on the TiVo is now really high, greedy updates or not, and stopples are plentiful.

Zero or negative values are OK, it just means that updates are pending for those items. If TCS thinks the network is down, this is going to happen and isn't a problem per se.

Possibilities include wrong IP Addresses for the name servers in the config/IPAddresses file, possibly a problem with the physical connection or route, or that the nameservers specified don't support TCP connections, only UDP. It seems that the latter would be unlikely as it would imply that your ISP changed their name server software (since it worked yesterday). You can verify that your nameservers support UDP using dig. There is a version available for Windows.

TCS determines the network is down when it can't hit any name servers. When the network is down, it turns off greedy updates (read hitting the web) since they will fail anyway, and drive up the load average as an aside. Several releases ago there was a bug in the DNS code that would drive the load average through the roof when this occurred. That was fixed, but hasn't been tested recently. Although this may again be a problem, it isn't the core issue here.

Best guess is that the IP Addresses of the name server(s) aren't correct. Connectivity/route could be checked by forcing a daily call. The Timers module has nothing to do with this area of code, and thus, the prior issue is unrelated.

Check your config/IPAddresses file to verify the name server addresses.

[dgi]

I'm positive the IP addresses are correct. More likely the TCP/UDP thing. Can I dig for TCP support?

[Zirak]

TCS determines that the network is down by resolving www.zirakzigil.net. If none of the name servers respond with a valid IP, the network is down. It seems that www.zirakzigil.net can not currently be resolved, so I need to figure out what is going on. I.E, everyone should be having this problem right now. Its odd that you are stoppling though, as I'm having the same issue and am not. The load average is very high, but there is plenty of idle CPU.

The problem seemed to occur at about midnight EDT today.

[Zirak]

It seems that Hurricane Frances has taken out connectivity to the web host. This problem will linger until connectivity is restored.

[Zirak]

Originally Posted by dgi

I'm positive the IP addresses are correct. More likely the TCP/UDP thing. Can I dig for TCP support?

Yes, dig has an option to force either a tcp or udp lookup.

[Zirak]

The TCS site is back up as of 5PM EDT. I don't know if its subject to further outages or not.

I have fixed the code where it takes more than a single DNS resolution error for TCS to think the network is down. I'm not going to bother to distribute it until the next release, as I think this will be a rather rare event.