TivoWeb 1.9.4 issue

[sose]

I have yet to see a fix for this.. Someone else must be getting it..

INTERNAL SERVER ERROR
--cut here--
action_channellist '/1' ''
invalid attribute: oIndex
while executing
"dbobj $station get ${varname}oIndex"
("uplevel" body line 8)
invoked from within
"uplevel $body"
invoked from within
"transaction {uplevel $body}"
(procedure "RetryTransaction" line 5)
invoked from within
"RetryTransaction {
for {set count $i} {$count < $maxchannelcount} {incr count} {
binary scan [string range $channeltabledata [expr $count*8..."
(procedure "::action_channellist" line 34)
invoked from within
"::action_$action $chan $part $env"
("eval" body line 1)
invoked from within
"eval {::action_$action $chan $part $env}"
--cut here--

[sose]

It happens when i click all under Channel Guide..

[superzap]

I get the same. Not sure what causes it but it might be an incompatibility with dtivos. As mentioned in the readme, "DirectTivos are not fully supported."

[George Martinez]

How about this one? When trying to take out the manual on a SA1 tivo with 3.1? I read somewhere that the manual field may have been moved in the database? What would I need to change in the script?

Making changes....
no such object: dbobj6
while executing
"dbobj $recbehave set ProgramGuideBehavior 2 "
("uplevel" body line 16)
invoked from within
"uplevel $body"
invoked from within
"transaction {uplevel $body}"
(procedure "RetryTransaction" line 5)
invoked from within
"RetryTransaction {
set rec [db $db openid $fsid]
set showing [dbobj $rec get Showing]
set program [dbobj $showing get Program]
if { $n..."
("uplevel" body line 87)
invoked from within
"uplevel $body"
invoked from within
"ForeachMfsFile fsid name type "$nowshowingpath" "" {
if { $fsid == $id } {
RetryTransaction {
set rec [db $db openid $fsid]
set showing [..."
(procedure "change" line 3)
invoked from within
"change $id $versionthree $nowshowingpath "
(file "./myedit.tcl" line 490)

[George Martinez]

I just realized that the theory about the database moved doesn't make sense because the script is able to correctly display the original type of a recording...

[George Martinez]

I love this conversation with myself, but I just figured out a fix for this. I added:

set recbehave [dbobj $rec get RecordingBehavior]

right after:
if { $newtype != "" } {

which is right before it uses that variable. I have never programmed TCL stuff before and really don't even know why I have to do this. It looks like this variable was already set earlier. Something about variable scope maybe? Although I printed the value and it looked correct in both instances... So maybe out of file handles or something like that? I would like to hear from somebody that knows this stuff.

[Frogbutt]

wich file did you edit to make the fix?