TivoWebPlus 2.1 Testing and Development

[tas3086]

I seem to remember a TWP trick to add additional search criteria (categories /sub categories) to wishlist items. I can not seem to find the post. Can someone help me remember ?
Thanks in advance.

[jkozee]

spitfires,
I get a similar hang when I click wishlists with the latest distribution that didn't occur with the John1980 dist. I am still tracking down things that I managed to break, but I don't think this is one of them. If you get a chance to look at it before I do that would be great. Otherwise, I will see what I can find.

Edit:
Actually, I do get an error on the John1980 dist, but it doesn't hang at least. I actually do not have any wishlist items added on the unit. Here is the error I see:

-------INTERNAL SERVER ERROR------  --cut here--action:wishlists, path:, env:, code:'TV_NM_NAME_NOT_FOUND'
can't scan path (TV_NM_NAME_NOT_FOUND)

    while executing
"mfs scan $mfsdir -start $name -count $count"
    invoked from: "transaction {
if {$i>=$blen} {
set batch [mfs scan $mfsdir -start $name -count $count]
set blen [llength $batch]
if {[lindex [lindex $batch 0] 1]==$na..."
    (procedure "ForeachMfsFileTrans" line 13)
    invoked from: "ForeachMfsFileTrans themefsid name type "/Theme" "" 20 {
set theme [db $::db openid $themefsid]
set imagestr ""
set sp [dbobj $theme get SeasonPass]
i..."
    (procedure "MOD::action_wishlists" line 10)
    invoked from: "$cmd $chan $path $env"
--cut here--

[jkozee]

Here's a new version of btutils.tcl that allows for a missing path. I also rolled back a patch for the 'endless loop' in ForeachMfsFileTrans, as I was not able to reproduce it.

Edit: Attachment removed.

[spitfires]

-------INTERNAL SERVER ERROR------  
--cut here--
action:wishlists, path:, env:, code:'TV_NM_NAME_NOT_FOUND'
can't scan path (TV_NM_NAME_NOT_FOUND)

Yes you will get that if a path isn't found - that's deliberate I think. As you probably know, TWP doesn't play nice with "empty" TiVos - many of the modules assume that the MFS directory they want to read already exists, if it doesn't then they barf.

I would say this is an issue with the wishlist module (in this case) rather than ForeachMfsFileTrans. You don't really want to trap these sorts of errors since it may mask genuine errors in the database (and unless ForeachMfsFileTrans can handle the error itself then it will probably go unreported/unnoticed).

[spitfires]

Here's a new version of btutils.tcl that allows for a missing path.

If you're going to do one of them then you really should do them all! (also note they vary between s/w versions)

I also rolled back a patch for the 'endless loop' in ForeachMfsFileTrans, as I was not able to reproduce it.

If you remove the catch{} block around transaction{} you will re-introduce the bug reported in #1088

[jkozee]

spitfires,

I'm not sure I made my point very well in post #1142. The original John1980 distribution gives the TV_NM_NAME_NOT_FOUND, the latest version you posted goes into endless loop.

The issue is the catch around the entire transaction does not set the "code" variable. So, what happens is when the you hit the "mfs scan" without a valid path, the catch traps the error and code is still 0. Then your stuck in a loop.

I agree about trapping TV_NM_NAME_NOT_FOUND and will remove it. I put it in when I was working through the endless loop, and left it there bacause I thought ForeachMfsFile also handled it, but maybe that was the original mfslib code.

I definately don't want to re-introduce any old bugs (or create new ones), which is why I am trying to work through this before posting another bundle. The bug in #1088 relates to ForeachTrans, which I didn't intend to roll back. I obviously didn't spend enough time going through the code as I should have. I will take another look at once I've had a fresh cup of tea

[spitfires]

Ah right I see. The catch{} block is necessary to trap any error generated by transaction{} - previously ForEachTrans was doing nothing since the d/b contention error wasn't actually being trapped at all, which is why errTmActiveLockConflict errors were appearing on the screen (they shouldn't have been!).

(#1088 isn't the only place this occurred but it's the most repeatable - every time you tried to delete more than about 12 programmes in one transaction, you would get a errTmActiveLockConflict error on screen)



It depends on what you want to do with the path error - as I say, I think this should be up to calling module to check the path exists rather than expecting ForEachMFSFileTrans to deal with it - the advantage being the caller module can then do something about it. E.g. along the lines of

if [catch { mfs find /Recording/SomeDirectory }] { mfs mkdir /Recording/SomeDirectory  ;#...oops directory not found... }

If you trap the error in ForEachMFSFileTrans then your calling modules will *still* have to do something with the error or else you will get into an endless loop! ("End of table not set so read from database table" (module) -> "Table not found" (proc) -> "End of table not set so read from database table" (module) -> "Table not found" (proc) -> etc !)

This is why I think it's generally a bad idea to try and trap TV_NM_NAME_NOT_FOUND (a.k.a. errNmNameNotFound) errors - they should really be considered as fatal. (You are expecting a database table to exist but it doesn't - hmm, sounds pretty fatal to me )


A more generic version of your code should be ok - e.g. attached. This will trap and return any errors from 'mfs scan'. Hopefully....! Please give it a try

[jkozee]

Thanks for the the detailed post an example. I worked through the code and patches and now have a better understanding of what is going on. Here's what I found.

In post #1107 a catch around the transaction, setting "code" and "errs" with the results, was added that fixed the previous bug where the transaction failed with errTmActiveLockConflict/TV_TM_ACTIVE_LOCK_CONFLICT. This had the side effect of an endless loop when a link was selected or the esc key was pressed on the NPL screen.

In post #1138, setting "code" and "errs" was removed from the catch around the transaction to fix the endless loop. This had the side effect of an endless loop when an attempting to iterate a non-existent mfs path (and a potential endless loop if the transaction were to fail with a fatal error).

After examining the code, it looks the bug with post #1107 was that "code" and "errs" was being set from the catch around the transaction, overwriting the values set inside of the transaction.

The bug with #1138 (and the example in post #1147) is that any unhandled error inside of the transaction AND the transaction itself are being treated as a non error.

This version should work as intended (hopefully) and includes all of the fixes from the previous posts. I also found that the errors must be different for the THD platform, so I have update the error list as well. Please test this version and report any problems.

[jkozee]

I just noticed another bug with the catch around the transaction. If the transaction fails, we must set "i" to "lasti" so that retries can occur. Without this fix, every item in the batch would be skipped. This patched version should correct this.

[djl]

Season Passes that are created at tivo.com and then downloaded when the TiVo phones home have a new type (11). TWP doesn't recognize these, so here is a fix. Both ui_season_pass.itcl and ui_record.itcl need to be updated (changes were made against the season pass module in post #1128).

[unclemoosh]

Had to upgrade to 6.4a and now WebRemote doesn't work. Using 110622 release. Get this error:

--cut here--action:sendkey, path:/tivo, env:, code:'CHILDSTATUS 1524 1'
Usage: sendkeyplus [options] [...]
Send one or more keypress events to TiVo software v6.1 and higher.
sendkeyplus requires alldeadhomiez' routerplus kernel module,
see http://www.pvrhax0r.com/forum/showth...hp?threadid=51

Options:
-l List all possible keypress events
-w Wait for acknowledgment after sending each event
-r Treat arguments as raw event numbers instead of names
-v Verbose mode

Advanced Options:
-p Pause milliseconds after sending each event

Note: The keypress event names are case-insensitive
NUM0 through NUM9 can be written as 0 through 9
The default pause (unless specified) is 1000

sendkeyplus v0.9 beta
Copyright (c) 2007, tivo4mevo
All Rights Reserved.
Permission to use and distribute this software for non-commercial use
is hereby granted, provided that both the copyright notice and this
permission notice appear in all copies of the software, derivative works
or modified versions and any portions thereof, and that both notices appear
in supporting documentation.

See http://dealdatabase.com/forum/showthread.php?p=287662 for more information.

/devbin/sendkey: invalid option -- a
while executing
"exec $env(TIVO_ROOT)/devbin/sendkey -wait -waitTimeOut 2500 $evrc($key)"
(procedure "SendKey" line 8)
invoked from: "SendKey $key"
(procedure "MOD::action_sendkey" line 32)
invoked from: "$cmd $chan $path $env"
--cut here--

Sendkey works fine from command prompt.

Any ideas?

Thanks.

[tas3086]

I have reworked the logos module and fixed the automatic logo association. It works pretty good now, with one exception.
The updated logos show up on both TWP and on the DTivo NPL and associated info screens. Unfortunately after a few hours, the icons start to disappear, and within 24 hours the newly associated logos are all gone. (This happens even if you do a manual association. It does not appear to happen if you make a new logo and upload it to the system. It apears to last forever.)

Is this some kind of garbage collection? Any way to stop it? Any suggestions?

When I get it working, I'll post the updated module.

[djl]

What is the issue with logos? Sorry if that was an earlier post, I must have missed it...

I have reworked the logos module and fixed the automatic logo association. It works pretty good now, with one exception.
The updated logos show up on both TWP and on the DTivo NPL and associated info screens. Unfortunately after a few hours, the icons start to disappear, and within 24 hours the newly associated logos are all gone. (This happens even if you do a manual association. It does not appear to happen if you make a new logo and upload it to the system. It apears to last forever.)

Is this some kind of garbage collection? Any way to stop it? Any suggestions?

When I get it working, I'll post the updated module.

[tas3086]

What is the issue with logos?

2 issues.
1) 6.4a Dtivo automatic association does not work because all compares fail in the logodat table search because the logodat name in the table includes a numeric prefix not just the channel name or callsign.
2) correcting this area, manual or automatic logo associations only last about 24 hours, then start to disappear.

Any idea why the logo's start to disappear?

[Soapm]

TivoHD running latest OS. For some reason these commands stopped working for me.

/TivoWebPlus/tivoweb restart &
/TivoWebPlus/tivoweb start &
/TivoWebPlus/tivoweb stop &

When I try them I get

FamRoom#/TivoWebPlus/tivoweb: tr: command not found
/TivoWebPlus/tivoweb: tr: command not found
/TivoWebPlus/tivoweb: tr: command not found
/TivoWebPlus/tivoweb: tr: command not found

Any ideas what this is telling me?