Results 1 to 9 of 9

Thread: Bugs and Workarounds

  1. #1
    Join Date
    May 2004
    Location
    Wellington, NZ
    Posts
    477

    Bugs and Workarounds

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

  2. #2
    Join Date
    May 2004
    Location
    Wellington, NZ
    Posts
    477

    mawk: bozo: wait_for

    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");

  3. #3
    Join Date
    May 2004
    Location
    Wellington, NZ
    Posts
    477

    grep corrupting large files

    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'

  4. #4
    Join Date
    May 2004
    Location
    Wellington, NZ
    Posts
    477

    Invoking rule 834: rebooting system

    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.
    Attached Files Attached Files

  5. #5
    Join Date
    May 2004
    Location
    Wellington, NZ
    Posts
    477

    can't scan path (0x00070009)

    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.

  6. #6
    Join Date
    May 2004
    Location
    Wellington, NZ
    Posts
    477

    commit failed (0x00030008)

    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.

  7. #7
    Join Date
    May 2004
    Location
    Wellington, NZ
    Posts
    477

    Tivoapp v2.5.5 mwstate fix

    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

  8. #8
    Join Date
    May 2004
    Location
    Wellington, NZ
    Posts
    477

    3.0 Event Bug

    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.

  9. #9
    Join Date
    Apr 2004
    Location
    ACT
    Posts
    134

    TiVoWeb Channel Guide "All" Bug

    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 )
    Living Room: US Philips HDR112, Seagate 200Gb, OzTiVo Image v1.5 (20051128), CacheCard (no RAM), Kross STB
    Rumpus Room: US Philips HDR31202, Seagate 120Gb, OzTiVo Image v1.6, CacheCard (no RAM), Tuner Mod, Dual Input Mod
    Additional Hacks: Re-order Season Passes

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •