Bugs and Workarounds

Somewhere to post any bugs that you have come across... and hopefully some workarounds :)

There seems to be an issue when closing a pipe in a mawk script when it is run from cron. You may notice that while some of your scripts will run fine from the command line, they will abort with a "bozo: wait_for" error when scheduled via cron. This was reported on the URL=http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=27809]Debian List[/URL] a while back.

The easiest workaround for this isssue is to replace your pipes with system calls... oddly enough, in my experience, this does not slow down the execution of the script.

As an example, the following pipe'd command:

Code:

---

  cmd="date";
  cmd | getline output;
  close(cmd);

---

should be replaced with something like this to avoid the bozo error under cron:

Code:

---

  system("date > /tmp/sys.out");
  getline output < "/tmp/sys.out";
  close("/tmp/sys.out");

---

There is an issue with the standard grep binary that comes with the TiVo software where it can result in a corrupted buffer being written back out to the filesystem... thus corrupting the file that it was processing. This is not just related to grep, as I have also had the issue when using vi on some files.

The best workaround when grep'ing very large files, is to replace:

Code:

---

grep 'regexp' largfile.txt

---

with the following:

Code:

---

cat largefile.txt | grep 'regexp'

---

If your TiVo reboots with an error message similar to the following:

Code:

---

TmkAssertionFailure[166]:  (BlockFailure, line 2073 ())
tivosh[166]: Tmk Fatal Error: Thread tivosh <166> died due to signal -2
tivosh[166]: Tmk Thread Backtrace: 1aa90ac 1aa79c8 1aa2290 1cda374 1ce64ec 1d37004 1d60820 1d48968 1d363d8 1d5b184 1d48968 1d363d8 1d37584 1d48968 1d363d8 1d5b184 1d48968 1d363d8 1d36160 199ccec 19b13e8 19b9870 1ba85dc 1ba79fc 1ba7d0c 19a607c 1d35b98 1d48968 1d363d8 1d53470 1d5457c 1ce648c 1ce61d4 1800134
tivosh[166]: Tmk Fatal Error: Thread died due to signal -2
tivosh[166]: Invoking rule 834: rebooting system

---

Then it is very likely that you are running an application (most likely TCL) that has just allocated too much memory. This can happen in badly written scripts, or in TivoWeb modules that are processing a lot of information.

I have attached a debug.itcl library that can be placed in your TivoWeb modules directory. This will create a function called pvars(chan) which will print out all variables (as well as their sizes) within the scope of the calling application/function. The global variables will be marked as yellow, and the local ones red. If you are debugging a module you can call "pvars $chan" to check the memory and see if there are any large variables that can be unset.

For some reason, when you are doing very bad things (sometimes referred to as developing:)) things can get upset and running a script that accesses the MFS database will start failing with "can't scan path (0x00070009)" errors. Rather than waste your time trying to fix a non-existent problem... just reboot and save yourself some time.

If you are seeing "commit failed (0x0030008)" errors when running an MFS script then the chances are you are trying to "add" a field that already exists in a record.

You will need to "remove" the field before you "add" it again (or you could just "set" the value if you know it exists). The brute force approach would be to "remove" the entry (but place this in a catch statement just in case it does not exist) and then "add" it.

There's a method of prodding myworld (tivoapp) to dump it's current state to the file /tmp/mwstate which can be pretty handy. This can be done via "event send $TmkEvent::EVT_REMOTEEVENT [binary format II 32 0]"

The problem is that version 2.5.x of Tivoapp had a bug where two programs would attempt to write to /tmp/mwstate simultaneously thus corrupting the file. The easiest fix is to change the second occurance of "mwstate" to "mwstat1" so the two programs write to different files.

This patch will alter the second occurance of /tmp/mwstate to be /tmp/mwstat1... in fact this is the only difference between v2.5.5 and v2.5.5a of the tivoapp binary. Assuming you have 'dd' available to you on the TiVo then the following can be applied directly (after you make the filesystem read-write and change to /tvbin).

WARNING: Do not do this unless your tivoapp is exactly 5646960 bytes in size (eg version 2.5.5).

Code:

---

cd /tvbin
mv tivoapp tivoapp-bak
cp tivoapp-bak tivoapp
echo -n '1' | dd conv=notrunc of=tivoapp bs=1 seek=5137975

---

Under version 3.0 of the software there is an issue where the system will stop processing remote events. This seems to be caused by a process that hooks into the event system and later stops responding or is unable to process waiting events. It is commonly known as the '3.0 event bug'. To help reduce the risk you may wish to watch what TivoWeb modules and utilities you run. Modules such as 'Phone' hook into the event handler to perform various tasks. It also seems to happen more often after heavy use of a remote control (not necessarily the TiVo remote)... which also implies that a process is not able to clear its queue before hanging.

The TiVo will still record programmes in this state, it will just not repond to events (such as those created by the remote control!). The system can be fixed by either killing the hung process (if you can determine which one it is), or by rebooting.

In TiVoWeb I get an error when I view the page:

User Interface -> Channel Guide -> All

Fixed by editing the file /hack/tivoweb-tcl/modules/ui.itcl changing this line:

Code:

---

set logoindex [dbobj $station get ${varname}oIndex]

---

to this:

Code:

---

set logoindex [dbobj $station get LogoIndex]

---

and restarting TiVoWeb.

(Hope it's OK for a West Islander to post here :) )