Mfs_Ftp: extract, archive, restore & transfer recordings

[Sbmocp]

Okay, finally some measure of success!

I ditched FileZilla and BPTFP and tried CoreFTP. I'm now downloading a file and it's giving me 3.2 MB/sec speed over a 1 Gigabit ethernet connection. Is this speed about par?

Revised: I'm having some problems. THe program was working (dumped a bunch of files to my local hard drive), then it stopped. When I tried to download a file, the file started to download then stopped. The "time to complete" in CoreFTP started climbing up to years (!) until I manually aborted. No parameters I could play with would get it to work again, so I uninstalled and re-installed the program. It worked again for a while then started misbehaving. CoreFTP's log files show nothing amiss, but mfs_ftp.log does show some info about the problem. Could someone please look at my log file and tell me what's going on?

[bsdimp]

I'm using this version of mfs_Ftp and have notice one bug. The date/time that's returned to the FTP clients is always AM. This means that if something is recorded at 9:00am, then the right time is returned and my client sets the time of the extracted file to the start of program time. However, if I recorded it at 9:00pm, it returns a time that is also 9:00am. Is this a known issue?

This is with wget on FreeBSD, if that matters.

[wundernaut]

I'm using this version of mfs_Ftp and have notice one bug. The date/time that's returned to the FTP clients is always AM. This means that if something is recorded at 9:00am, then the right time is returned and my client sets the time of the extracted file to the start of program time. However, if I recorded it at 9:00pm, it returns a time that is also 9:00am. Is this a known issue?

This is with wget on FreeBSD, if that matters.

I see pretty much the same thing on my directory listings under Directory Opus on my XP. Most of the dates are AM, but there are a few PMs. This is true from my Sony series 1, DirecTivo, and HD TiVo.

Looking at the mfs_ftp.tcl code, it seems there's a difference between recordings that are less than one year old, and recordings older than one year old. For recordings that are greater than one year old, the time of day is not returned, just the year. Thus your ftp client just makes up a time for these files, and it's probably the same for all of them.

For files that are less than a year old, a time of day is returned in 12-hour format, but no AM or PM indicator. After doing some experimentation on my DirecTiVo, it seems that the TiVo always knows the proper time is, but returning an "AM" or "PM" string just gets ignored, at least on my ftp client. So I changed the code to return the time in a 24-hour format, and it seems to work for me.

In the mfs_ftp.tcl file, look for a "proc get_ldate" string. You should see:

proc get_ldate { recsec tzoffset } {
 if { [expr [clock seconds] + $tzoffset - $recsec ] > 31449600 } {
 	set ldate [clock format $recsec -format "%b %2d  %Y"]
 } else {
	set ldate [clock format $recsec -format "%b %2d %I:%2M" ]
 }
 return $ldate
}

In the second "set ldate" statement, change the "%I" to "%H" so you have

	set ldate [clock format $recsec -format "%b %2d %H:%2M" ]

You'll have to restart the mfs_ftp process to make the change effective. You can do it from a telnet session manually if you know how to do that (if you need someone to tell you how, best not try). Otherwise, in the top level mfs_ftp / directory of your TiVo on your ftp client, simply try transferring "phoenix.txt" to your PC. That should restart mfs_ftp.tcl (be prepared to wait the usual several minutes for it to rebuild its cache on the TiVo). If that doesn't work, you'll have to reboot your TiVo.

[tas3086]

proc get_ldate { recsec tzoffset } {
 if { [expr [clock seconds] + $tzoffset - $recsec ] > 31449600 } {
 	set ldate [clock format $recsec -format "%b %2d  %Y"]
 } else {
	set ldate [clock format $recsec -format "%b %2d %I:%2M" ]
 }
 return $ldate
}

I thought that I was up-to-date, but I do not find this "Proc get_ldate" code anywhere in my code. Did I miss a patch somewhere along the line?

[wundernaut]

I thought that I was up-to-date, but I do not find this "Proc get_ldate" code anywhere in my code. Did I miss a patch somewhere along the line?

Sorry, my fault. It's from a modification of the mfs_ftp.tcl code I made years ago and forgot about but never released publicly. In the standard 1.29p release mfs_ftp.tcl, look for

proc calc_tertiary_info	{ fsid } {
global info db ; set p 2
 outd $p "calc_tertiary_info: recobj\{$fsid\}"
 if { [info exists info($fsid,State)] == 0 } { rec_info_from_db $fsid }
 set recsec [expr $info($fsid,Date) * 86400 + $info($fsid,Time) + $info(tzoffset)]
 set info($fsid,date) [clock format $recsec -format "%2m-%2d-%y  %I:%2M%p" ]
 set info($fsid,ldate) [clock format $recsec -format "%b %2d %I:%2M" ]
 if { [expr [clock seconds] + $info(tzoffset) - $recsec ] > 31449600 } { set info($fsid,ldate) [clock format $recsec -format "%b %2d  %Y"] }
 set recdate "[clock format $recsec -format "%I.%M %p %a %b %d, %Y"]"

Try changing the "%I" to "%H" in the line for set info($fsid,ldate). The others set fields in the metadata stored for each recorded program and I don't know what effect they would have if you changed them to a 24-hour format (in fact, I can't find anyplace where the "date" variable actually gets used). Note, I don't run standard 1.29p code anymore, don't know if other standard patches since then have affected this code, and haven't tested this fix against it. However, I'm pretty sure the ldate variable is only used for the ftp LIST command and if you track down all uses of it and where it's written you will solve the problem.

[tas3086]

Infinite loop in receiving a tmf file found and fixed.

in proc parse_tmf update the while eof line to look like:

while { ([eof $info(dc)] != 1) && ($info(finished) != 1) } { tmf2fsid $newrecording }


When an error is detected in tmf2sid, the error indicator is not being checked in the calling proc, and the while loop continues indefinitely. To be absolutely correct, a "Transmission Successful" should not be returned to the FTP issuer. This part was not done yet, but at least the loop is fixed.

Sorry, I can't do a patch because my version has lots of changes and diagnostics added.