Mfs_Ftp: extract, archive, restore & transfer recordings

[psxboy]

Didn't look into fixing this. Just corrected the value in tzoffset.txt that's generated when .tcl is run. As i understood it, if the file exists, it'll be used instead of running the tcl.

That's true... it will use a pre-existing tzoffset.txt if it exists. But if you're interested in fixing the code to begin with:

Change this (in tzoffset.tcl)

if {$dlsval == 1} {
		return [expr ($tz+1)*60*60]
	} else {
		return [expr $tz*60*60]
	}
	} else {
		return [expr $tz*60*60]
	}

to this:

if {$dlsval == 1} {
		return [expr $tz+3600]
	} else {
		return $tz
	}
	} else {
		return $tz
	}

-psxboy

[kelsky]

I noticed that on a new install the tzoffset.txt didn't get created.

I copied it from one of my other units and it worked. I didn't have to change anything else. Here is what I had in the txt file

# <tzoffset>-21600</tzoffset>
set info(tzoffset) -21600

[tas3086]

Trying to move a .tmf file from one machine to another. Most filenames using the #6 format start with a {, but occasionally they start with a hh:mm before the {. Heres a log of the ftp request to download the file. It is funny that it only happens on an occasionall basis.....

11:38:35:AM - PORT 192,168,1,100,8,120
11:38:35:AM - data channel "sock23" to 192.168.1.100:2168
11:38:35:AM - 200 PORT command successful.
11:38:35:AM - readlinefromsocket: "sock22"
11:38:35:AM - echo to verify: "RETR 09:00 {Irreconcilable Differences}{1983-12-31}{}{09.00 AM Tue Apr 05, 2005}{WE}{567603}.tmf"
11:38:35:AM - parseline:
"RETR 09:00 {Irreconcilable Differences}{1983-12-31}{}{09.00 AM Tue Apr 05, 2005}{WE}{567603}.tmf"
11:38:35:AM - RETR:
"09:00 {Irreconcilable Differences}{1983-12-31}{}{09.00 AM Tue Apr 05, 2005}{WE}{567603}.tmf"
11:38:35:AM - fsid_from_filename:
"09:00 {Irreconcilable Differences}{1983-12-31}{}{09.00 AM Tue Apr 05, 2005}{WE}{567603}.tmf"
11:38:35:AM - searching $info(rec_filenames) for
"09:00 {Irreconcilable Differences}{1983-12-31}{}{09.00 AM Tue Apr 05, 2005}{WE}{567603}"
11:38:35:AM - searching fsid list for "09:00 {Irreconcilable Differences}{1983-12-31}{}{09.00 AM Tue Apr 05, 2005}{WE}{567603}"
11:38:35:AM - recfsid "-1" filetype "tmf"
11:38:35:AM - 550 error, can't find "09:00 {Irreconcilable Differences}{1983-12-31}{}{09.00 AM Tue Apr 05, 2005}{WE}{567603}.tmf"
11:38:42:AM - readlinefromsocket: "sock22"


Any Ideas ?
Otherwise, things work very well !

[drewcaplan]

Nope - I just haven't done any transfers for a few days or so and system has been working fine. Was hoping someone might offer some suggestions before I tried again. Shutting down the other processes would be worth a try. At least that might narrow it down a bit. I also wonder if there is a way to preserve the mfs_ftp log following a reboot so at least I could see what the error message is prior to losing network connectivity. As it stands now it resets on reboot.

Bob

Bob, I have done a bit more investigating. I am still having the problem -- I reported I wasn't earlier, but was wrong. I used a sniffer on the connection, and here is what I found. Things look great for a while... packet, ACK, packet, ACK, etc. All are TCP.

Then there is an odd packet. Ethereal logs it as a "TDS7/8 Login packet," of protocol TDS, which is new to me. Right after that, my Tivo starts sending only "Unknown packet types" with protocol TDS. This goes on for a while, and then the Tivo starts sending "TCP Out-of-Order" packets, my PC responds with "TCP Duplicate" reponses, and then the Tivo regresses to searching for the network, sending out tons of ARP messages. It finally just stops and dies (the network, that is, the Tivo application is fine). I have found that I have to reset my switches on the network to bring things back -- the entire network gets hosed.

Any network experts have any thoughts on this?

[cheer]

Then there is an odd packet. Ethereal logs it as a "TDS7/8 Login packet," of protocol TDS, which is new to me. Right after that, my Tivo starts sending only "Unknown packet types" with protocol TDS.

Isn't that SQL*Net? (Or SQL Server or something similar...Oracle's Tabular Data Stream.) Not sure why you'd hit that at this stage.

This goes on for a while, and then the Tivo starts sending "TCP Out-of-Order" packets, my PC responds with "TCP Duplicate" reponses, and then the Tivo regresses to searching for the network, sending out tons of ARP messages.

Do you see responses to the ARPs? Or does it all explode too quickly?

It finally just stops and dies (the network, that is, the Tivo application is fine). I have found that I have to reset my switches on the network to bring things back -- the entire network gets hosed.

OUCH.

OK. What kind of switches? Dumb or smart? When the ARP goes nuts, what do you see? Can you post a sniffer trace in a text file? (Feel free to block out IPs and MACs so long as I can tell which is what...)

--chris

[drewcaplan]

Do you see responses to the ARPs? Or does it all explode too quickly? What kind of switches? Dumb or smart? When the ARP goes nuts, what do you see? Can you post a sniffer trace in a text file? (Feel free to block out IPs and MACs so long as I can tell which is what...)

--chris

Thanks for the inquiry. I did see responses to the ARPs... my computer kept properly replying that it was the address in question, but the Tivo seemed to ignore that.

I am now questioning my trace. When I exported it to a text file, it looked different than it did on screen in terms of the TDS stuff. I am going to run another trace with another tool, and will send up the results if they look more real. My switch is a standard, dumb, Linksys model, BTW.

[drewcaplan]

Cheer,

I finally got a good capture. Info is below. Note that my Tivo is 192.168.2.168 and my PC is 192.168.2.170. I included only the end of the capture. Things hum along, with the Tivo sending two data packets (I edited out the data itself from the trace, didn't think that was interesting) and the computer responding with two packets. Then in packet 90655 we have our first sign of trouble, a TCP retransmit. Then an out-of-order, then a duplicate, etc. Then things just sort of end. The symptom at that point is that is that the Tivo is unreachable on the network -- it has to be restarted to regain its IP address. It is as if its IP stack gets corrupted or something. Sometimes my switch needs to be reset -- my whole network gets messed up. This time not so severe. Any help appreciated!

I attached the file snippet.

Thanks!
Drew

[cheer]

Cheer,

I finally got a good capture. Info is below. Note that my Tivo is 192.168.2.168 and my PC is 192.168.2.170. I included only the end of the capture. Things hum along, with the Tivo sending two data packets (I edited out the data itself from the trace, didn't think that was interesting) and the computer responding with two packets. Then in packet 90655 we have our first sign of trouble, a TCP retransmit. Then an out-of-order, then a duplicate, etc. Then things just sort of end. The symptom at that point is that is that the Tivo is unreachable on the network -- it has to be restarted to regain its IP address. It is as if its IP stack gets corrupted or something. Sometimes my switch needs to be reset -- my whole network gets messed up.

Well that's a curious trace, all right. Looks like perhaps a windowing issue -- it's asking for a retransmission of seq 66690280, which isn't in the trace (presumably happened prior to what is in here). The window is cranked up pretty high. Then later it sends an out-of-order for the same sequence! I just can't figure out why it's doing it. Let me ponder this for a bit; I will reply more later.

Meanwhile, try stringing a crossover cable from the PC to the Tivo and see if the same thing happens. Let's eliminate as much as we can -- a haywire switch might be the issue.

--chris

[drewcaplan]

Thanks, Cheer. ... note that I've tried 2 different switches, both Linksys, but different models. Also, some other people have complained about the same exact thing so I lean to thinking that the issue is some bug in the IP stack or USB network drivers. Perhaps one can upgrade the drivers...

On the crossover... I can try that... is the idea to just use a crossover cat5 between the two machines... ?

I can also send you a more complete capture if that would help.

[Jamie]

Thanks, Cheer. ... note that I've tried 2 different switches, both Linksys, but different models. Also, some other people have complained about the same exact thing so I lean to thinking that the issue is some bug in the IP stack or USB network drivers. Perhaps one can upgrade the drivers...

On the crossover... I can try that... is the idea to just use a crossover cat5 between the two machines... ?

I can also send you a more complete capture if that would help.

This sounds like a general networking problem rather than an mfs_ftp problem, so maybe it should be moved to a new thread.

Apparently there are well know network lockup issues with the stock USB drivers on the HD units. Have you tried the drivers here or here?

[cheer]

Thanks, Cheer. ... note that I've tried 2 different switches, both Linksys, but different models. Also, some other people have complained about the same exact thing so I lean to thinking that the issue is some bug in the IP stack or USB network drivers. Perhaps one can upgrade the drivers...

On the crossover... I can try that... is the idea to just use a crossover cat5 between the two machines... ?

I can also send you a more complete capture if that would help.

Yes a more complete capture would help, and yeah I was thinking just use a crossover cat5 between the two, but if you've tried different switches that's unlikely the issue.

I recommend the drivers suggestion posted by Jamie to see if that helps as well.

--chris

[drewcaplan]

Thanks.... stupid newbie question.... I downloaded the .bz2 object file but don't know how to unarchive .bz2. Quick pointer? Also, I hope it will be obvious how to install these files into my HD Tivo unit. Thanks.

[Jamie]

Thanks.... stupid newbie question.... I downloaded the .bz2 object file but don't know how to unarchive .bz2. Quick pointer? Also, I hope it will be obvious how to install these files into my HD Tivo unit. Thanks.

This is really not the appropriate thread for general network issues or for newbie 'how do I install X?' questions, where X!=mfs_ftp. I suggest you read the usb2 backport thread first, then search for any questions you have, and as a last resort post a question in the newbie forum if you still can't figure it out.

Hint on your bz2 question (quickly found via a search): link.

[tlphipps]

The symptom at that point is that is that the Tivo is unreachable on the network -- it has to be restarted to regain its IP address. It is as if its IP stack gets corrupted or something. Sometimes my switch needs to be reset -- my whole network gets messed up.

I actually have the exact same problem mentioned here. I've tried several different things: direct crossover cable, upgraded NIC drivers (the backport drivers), Jamie's "patched" version of mfs_ftp 1.2.9p, killhdinitrd kernel (I know this shouldn't make a difference, but it needed to be done anyway). All attempts have run into the same problem. I cannot fully insert a file. Sometimes I get several minutes inserted, and sometimes just a few seconds.

I'm running an DSR7000 with 3.1.1b currently with Jamie's patched version of mfs_ftp. What really gets me is I can't figure out when this cropped up. I used to be able to insert files with no problem.

FWIW, after the network "lockup", the activity light on my switch for the dtivo is just going crazy (like a network flood...which would explain the other hosts on the network being inaccessible). The only way I can clear it up is to restart the dtivo.

I've heard others alude to this error, but nobody else has ever explained my exact problem that I've seen until now, so I always assumed it was something on my end.

[CarlWalters]

I'm sure that mfs_ftp used to work a couple of months ago as I used to use it to grab .asx files for use in myHTPC. But now it's misbehaving - or I'm being stupid

I am running a UK S1 v2.5.5 and have re-installed mfs_ftp v 1.2.9p so as to be able to grab .asx files off my TiVo using these scripts

tivoftp.bat

c:  
cd c:\tivo  
mkdir asx_temp  
cd asx_temp  
del * /q  
ftp -s:c:\tivo\ftp\tivoftp_cmds.txt  
if exist c:\tivo\asx_temp\*.asx goto DEL  
goto END    

:DEL  
cd c:\tivo  
del asx /q  
rmdir asx  
ren asx_temp asx    
:END  
exit

which calls the ftp command file tivoftp_cmds.txt

op tivo 3105      


cd asx  
prompt off  
lcd c:\tivo\asx_temp  
mget m*  
quit

Hackman in TiVoWeb says that mfs_ftp is running, if I telnet into TiVo and run ps -ax I can see the ms_ftp process but when I run tivoftp.bat then the whole thing hangs at the mget m* and I have to kill it

C:\tivo\ftp>tivoftp    
C:\tivo\ftp>c:    
C:\tivo\ftp>cd c:\tivo    
C:\tivo>mkdir asx_temp  A subdirectory or file asx_temp already exists.    
C:\tivo>cd asx_temp    
C:\tivo\asx_temp>del * /q    
C:\tivo\asx_temp>ftp -s:c:\tivo\ftp\tivoftp_cmds.txt  

ftp> op tivo 3105  
Connected to tivo.  
220 Mfs_Ftp ver 1.2.9p - {sock31} from "192.168.0.2:3956"  
User (tivo:(none)):  
331 User name okay, need password.    

230 Running in TiVo Mode.  
ftp> cd asx  
250 Directory change successful.  
ftp> prompt off  
Interactive mode Off .  
ftp> lcd c:\tivo\asx_temp  
Local directory now C:\tivo\asx_temp.  
ftp> mget m*  

Connection closed by remote host.  
ftp>

and if I ftp into port 3105 manually and try something simple like "ls" then the connection gets closed

ftp> op tivo 3105
User (tivo:(none)):
Password:
ftp> ls
Connection closed by remote host.
ftp>

does anyone have any ideas as to what I'm doing wrong - or where to start de-bugging?

thanks in advance