PDA

View Full Version : Problems with Remote Responsiveness & the Event Bug!



daryl
06-15-2004, 12:40 AM
Now that I've installed LGKahn's PC Media server plugin for mfs_ftp, I've been using my Tivo hacks more than ever. I'm constantly firing up tivoweb, and mfs_ftp for Tivo storage management, in addition to my old trusty tyserver and tserver_mfs tools that I use for long term archiving.

In the past year I've often encountered the dreaded 'event bug' after using TivoWeb. Specifically, what I mean by the 'event bug' is that after xxx hours, my remote control input competely stops being processed by the Tivo. I can't telnet, I can't ftp, I can't do anything but reboot. Luckly, Tivo normal playback/recording functionality seems to be unaffected by this 'event bug state', but I am completely unable to interact with my Tivo until I manually reboot it by removing the power cord.

Due to this event bug, I've minimized my use of Tivoweb over the past year. But after discovering the PC media server plugin for mfs_ftp last week, I'm now using Tivoweb/mfs_ftp now on a semi-daily basis, and I really want to get to the bottom of this 'event bug'.

I'd like to know:

1) Is anyone else experience similar problems to those mentioned above, where 10-20 hours after running a .tcl server hack, your remote control completely loses responsiveness?

2) Does anyone have any recommendations for how to prevent this problem? Does anyone know a way to at least telnet into the shell and kill the process that is causing this lockup? (When my Tivo goes into this 'event bug' loop, my telnet shell no longer responds!!!)

Thanks in advance for your help

Daryl @ SA1/3.0 (141 hrs)
tivoftpd / tivoweb 1.9.4 / mfs_ftp 1.2.9p w/ PC media server plugin / tyserver / tserver_mfs7

tweaky
06-15-2004, 08:14 AM
http://www.dealdatabase.com/forum/showthread.php?t=25697&highlight=reboot

Also, it was answered where you asked the question first:
http://www.dealdatabase.com/forum/showthread.php?t=34334&page=6

Only ask it in one spot.

daryl
06-15-2004, 10:32 AM
Tweaky, I don't think this thread you provided is answering the same question I was asking.

I really don't want a script that will auto-reboot the Tivo. My recordings are going all day long, and they do not fail (even when my response response is completely lost).

I want to get the bottom of this event bug and find out what specifically is causing it, and how I can trap it from occuring.

Lowcarb
06-15-2004, 11:00 AM
1) Is anyone else experience similar problems to those mentioned above, where 10-20 hours after running a .tcl server hack, your remote control completely loses responsiveness?

Daryl @ SA1/3.0 (141 hrs)
tivoftpd / tivoweb 1.9.4 / mfs_ftp 1.2.9p w/ PC media server plugin / tyserver / tserver_mfs7

Daily Freeze (http://www.dealdatabase.com/forum/showthread.php?t=34906)


Is this the 'Event Bug' (http://www.dealdatabase.com/forum/showthread.php?t=34355)

daryl
06-15-2004, 11:46 AM
Lowcarb,

Thanks for the links. I did read those threads, but they don't seem to apply to my case. There are no other IR devices in my house, and there is no florescent lighting either.

The fact that I am unable to telnet into my Tivo when it's in this unresponsive state is what leads me to believe it is a system level problem.

Lowcard, have you resolved this problem for yourself yet?

Lowcarb
06-15-2004, 11:52 AM
Lowcard, <sic>., have you resolved this problem for yourself yet?

I don't think so. I had one event since I disabled the IR on my laptop.
I haven't had a freeze in a while, but then again I haven't been using TWP much either. At first I thought that CajonesDelToro had the answer but I'm afraid not. Also the near daily precision of the lockup left me wondering.

Right now I've got enough on my plate without antagonizing the Tivo trying to challenge it into failure.

Zirak
06-15-2004, 12:14 PM
I coined the phrase "event bug" and have a great deal of experience with it.

You can not completely avoid it, even on unhacked tivos.

Generally, If you run a hack that taps into the event system you will exacerbate the frequency of occurence.

The only way to recover from it is to kill the process that hangs, which will often cause the tivo to reboot.

Deleting the tivoweb phone module and not using the tivoweb remote will reduce the frequency of occurrence.

Lowcarb
06-15-2004, 01:11 PM
The only way to recover from it is to kill the process that hangs, which will often cause the tivo to reboot.


Thanks Zirak.

How does one tell which process is the one that is hung?

Zirak
06-15-2004, 01:52 PM
I don't think there is a certain way, but from my experience strace returns what I call the nanosleep of death. You will understand that once you see it.

The only things that merit attention are hacks that look at events. Tivoweb is the only relatively common one that is susceptible. However, its rather pointless as there is generally no option short of rebooting the box.

eastwind
06-15-2004, 04:38 PM
One thing that seemed to work for me was to always do a Full Reload of TiVoWeb before exiting the browser. That was before I found out about removing the phones module.
ew

lgkahn
06-15-2004, 05:59 PM
zirak ... I have heard rumours that you have a workaround ?????

Is there anything I as a code writer can do when I need to look at an event and process it... say thumbs up on a message screen I have tried to keep my code to a minimum this is the current... but still every few days the box does freeze due to the dreeded event bug....Also needs to work on series 2 boxes as well.. Thanks in advance.

ie.


event register 28 pc_dumpstate


and

# proc runs when event 4 (EVT_MW_STATUS) is triggered
proc pc_dumpstate { event subevent } {
global EventData mwStateG refresh delete got eventSerialNumberG select tivo last31 info version dlg nameloc portloc iploc dirloc rfname rport rdir rip fixname fixname2 r1 r2 nameloc2 iploc2 rfname2 fixname3 serverloc rserver foundserver processingserver server_username server_pwd totalservers current
outd $info(snpdbl) "Dumpstate called at [clock format [clock seconds]]"
binary scan $EventData IIIIII ident junk junk2 junk2 junk4 junk5
outd $info(snpdbl) "Ident: $ident"
# outd $info(pcdbl) "event is 28 subevent is $subevent ident is $ident"
if {$event == 28 && $subevent == 1 && $ident==7} {
# That's our signal - someone tried to play a dummy recording
# Send a select to return to the NP screen
# no send key fx in version 4.x
if {$info(version4) != 1} {
sendremotekey $select
}

set last31 [clock seconds]
# return to NP complete
if {[expr [clock seconds] - $last31] < 5} {
pc_process_event
}
}
}

Zirak
06-15-2004, 07:20 PM
zirak ... I have heard rumours that you have a workaround ?????

Is there anything I as a code writer can do when I need to look at an event and process it...

I put a workaround in TCS. Although functional, its ugly. One process monitors the events and notifies a second process when they come in through a section of shared memory. The second process monitors the first and kills/restarts it if it event hangs.

lgkahn
06-15-2004, 08:03 PM
taking this off topic I was thinking of doing something similiar using pipes in tcl... would need to be threaded though I guess to get a heartbeat from the other every so often to know when to kill the othe rprocess.. however I thourght when tcl shells are killed the box reboots anyway....

eastwind
06-15-2004, 11:50 PM
taking this off topic I was thinking of doing something similiar using pipes in tcl... would need to be threaded though I guess to get a heartbeat from the other every so often to know when to kill the othe rprocess.. however I thourght when tcl shells are killed the box reboots anyway....
AFAIK, killing a tcl shell (tivosh?) doesn't reboot the box unless there are open handles to the MFS (but I could be wrong).
ew

cojonesdetoro
06-16-2004, 12:10 AM
Here's a good one to get context changes and remote events:

http://alt.org/forum/index.php?t=msg&th=26&start=0&rid=0&S=2865ca86f5430cac11e9fbdd0b45e451

You run this and open a socket to it. It sends heartbeats, too.

lgkahn
06-16-2004, 09:56 AM
thanks ... been playing with it.. looks promising... can kill and restart it once I changed it into a regular tcl script so the tivosh call is not necessary using killall ... also beefed it up to pass all three paramaters event subevent and id

and only the single event I am insterested in and upped the heartbeat to 10 seconds....
that should be often enough to know it hung every 20 seonds or so and restart it.


now all I need is an example of threads inside tcl.. is it even possible does anyone have an example I will need to have a thread running a fx in a loop waiting so long on the socket communicating with this thing and if I block and don't get the heartbeat in say 20 seconds kill and restart the thing and then reopen the socket and continue....

also it needs to wait for the key events....

thanks

cojonesdetoro
06-16-2004, 01:07 PM
now all I need is an example of threads inside tcl.

You mean sockets, right?



. is it even possible does anyone have an example I will need to have a thread running a fx in a loop waiting so long on the socket communicating with this thing and if I block and don't get the heartbeat in say 20 seconds kill and restart the thing and then reopen the socket and continue....
also it needs to wait for the key events....
thanks

Look for my fxpmerge script. I have a proc called getsock that turns off blocking on the channel and times out if not data recvd in a set amount of time.

lgkahn
06-16-2004, 01:16 PM
no not sockets I know how to do sockets.. but since this is going to be running inside of part of mfs_Ftp... it needs to be in a separate thread becuase it will take the place of the callback routine..

so it needs to be running in its own thread...

ie the old callback kind of was in its own thread.. it got called automatically
whenever a key was pressed..

this needs to sit and run in a thread... not matter what else is going on...