Mfs_Ftp: suggestions, feedback, etc

[Will]

got tired endless questions from folks running old/unauthorized versions so newer revisions expire after a month or three. (Q should be good through April)

I'm sure that cannon will take care of all the flies.

I noticed the new "feature" in Q. Not caring for boobytraps like that, I'm staying with P which hopefully won't _deliberately_ fail at an awkward time.

I appreciate your being forthright with the info, otherwise I might have returned from a trip and found that my DTivo harvesting scripts had malfunctioned from the sabotage (which clearly you have every right to inflict on your own software; as a big fan of mfs_ftp, I'm just sorry you felt you had to).

[rc3105]

ya well

mfs_ftp started out as a proof-of-concept & became much more popular / controversial / dangerous than expected

as Zirak noted, without deep pockets or unbridled youthfull optomism this type of project requires some legal groundwork to avoid major headaches. this step solved a couple of problems at once

*sigh

[NutKase]

got tired endless questions from folks running old/unauthorized versions so newer revisions expire after a month or three. (Q should be good through April) is your tivo clock correct?

Great. I too, will stay with an old/unathorized version.

Nutkase

[Will]

Ahh, I see you've established a thread for feedback. Though I'm sure you meant feedback of a practical nature, performance-related, I'll stretch a point to mention this:

This comment was posted on the TC forum 8-9 months ago by a fan:

"Though mfs_ftp is regarded in its 'home' territory as just another nice hack, IMO it is a seminal end-user product. The first real step forward in empowering home TV time-shifters with modern, flexible, easy to use video management tools. It makes Tivo really useful."

Since all you hear is problems, and grumbling from us malcontents who don't like expiration dates, it's possible you don't really know how much your effort is appreciated.

[Noneentered]

Sorry for going off half cocked.

[newbie]

I understand your reasons for having a "drop dead" feature in MFS_FTP. It's your program and you can do what you want. I just wish you had told us about this new feature. You're (trying) to stop distribution of older versions. Encouraging everyone to upgrade to the current version. You're basically making it easier for you to pull the plug on us.

[alldeadhomiez]

If not, could someone post the last version that isn't?

I believe most of the recent versions are under a restrictive license that prohibits redistribution.

You're basically making it easier for you to pull the plug on us.

You have the source code - read it and mod your copy to run forever. Just remember that modified and obsolete versions are unsupported and illegal to distribute.

There are developers out there who enjoy having "power" over their users. Frequently they withhold source code and knowledge, so nobody else can become as good as they are or maintain their projects after they lose interest. Riley is not like that - he is one of the good guys.

[rc3105]

alldeadhomiez:

ty, high praise indeed


newbie:

read up on dvd-jon. they nearly bankrupt a poor guy who didn't even break the law. dtv owns tivo now & loves to do lawsuit carpet bombing. if some yutz starts e-baying dvd's full of playboy channel episodes you can bet your a*s*s I'll be named in the suit just for writing the sw he used to extract the video digitally

allready been a couple of near misses settled out of court


do I want folks running old versions? nope - makes things more difficult for everyone

could I put trapdoors in? - sure, anybody could

have I put any in yet? - no. a built in "drop dead" at worst limits usefullness. check the readme/license/thread. it's as-is without warrenty. yeesh, how much do you want for free??? tivo provides support but charges $100 for much less functionality

lotta things need doing - it's all happening slowly & some are on hold till the hd units are out

[newbie]

I fully understand and appreciate your position. My ONLY point, I would have liked it if you had put some notice in the readme file, I may the only one who printed and read the entire file the first time I used MFS_FTP although I don't read the whole file with each revision.

alldeadhomiez:

ty, high praise indeed


newbie:

read up on dvd-jon. they nearly bankrupt a poor guy who didn't even break the law. dtv owns tivo now & loves to do lawsuit carpet bombing. if some yutz starts e-baying dvd's full of playboy channel episodes you can bet your a*s*s I'll be named in the suit just for writing the sw he used to extract the video digitally

allready been a couple of near misses settled out of court

[Noneentered]

You have the source code - read it and mod your copy to run forever. Just remember that modified and obsolete versions are unsupported and illegal to distribute.

Thank you for your insight, it kicked me in the tail enough that I researched TCL programming, and found what I needed.

Riley, thanks for everything. I'm sorry I posted without doing all my research first.

[rc3105]

I fully understand and appreciate your position. My ONLY point, I would have liked it if you had put some notice in the readme file, I may the only one who printed and read the entire file the first time I used MFS_FTP although I don't read the whole file with each revision.

generally the readme is only revised when there's a version number change. (1.2.8 to 1.2.9, etc) & the release method has been leapfrog. 1.2.9p (latest stable tried & true) remains available until r is posted & q is known to be good, then q becomes the fallback release while folks comment on r

[alldeadhomiez]

This is a trivial patch against 1.2.9Q that fixes 3 problems I have encountered:

1) The verbose progress messages make the log file nearly unusable IMHO (if you like the messages consider adding newlines if the output device is not a tty)
2) Some ftp clients annoyingly default to ASCII if the SYST response does not include "Type: L8"
3) mfs_ftp.tcl was redirecting its stderr to a file named "&"

--- mfs_ftp.tcl.orig    2004-04-18 12:29:36.000000000 -0500
+++ mfs_ftp.tcl.new     2004-04-18 12:31:10.000000000 -0500
@@ -866,7 +866,7 @@
        fcopy $info(dc) $outf -size $s ; if { [eof $info(dc)] == 1 } { set i $bytes }
        incr chunknum ; if { $info(ithrottlems) >= 0 } { after $info(ithrottlems) }
        set dr "[expr $chunknum * $chunksize/([clock seconds]-$stime) /1024]k/sec"
-       puts -nonewline stdout "\t[expr $chunknum / 16] meg\t$dr\r" ; flush stdout
+       #puts -nonewline stdout "\t[expr $chunknum / 16] meg\t$dr\r" ; flush stdout
        if { $info(bmfsid) != 0 } {
                puts "the if worked, setting bm to $info(bookmark)"
                set_bm $info(bmfsid) $info(bookmark)
@@ -1154,7 +1154,7 @@
 }

 proc SYST { args fsock } {
- tee $fsock "215 UNIX"
+ tee $fsock "215 UNIX Type: L8"
 }

 proc TYPE { args fsock } {
@@ -1577,7 +1577,7 @@
        default {
         set info(ac_interval) 14
         catch { close $control_socket(main) }
-        exec $info(path)/mfs_ftp.tcl $info(port) backgrounded 2>& stdout &
+        exec $info(path)/mfs_ftp.tcl $info(port) backgrounded 2>@stdout &
        }
   }
  }
@@ -1608,7 +1608,7 @@
 global info
  tee $fsock "$callingproc quiting mfs_ftp.tcl and forking a new one"
  after 200
- exec $info(path)/mfs_ftp.tcl $info(port) $info(background) 2>& stdout &
+ exec $info(path)/mfs_ftp.tcl $info(port) $info(background) 2>@stdout &
  exit_proc stdout phoenix_mfs_ftp
 }

[alldeadhomiez]

I haven't seen this posted yet either. This (might) fix tzoffset.tcl on 4.x and 5.x. Tested on 4.0 in central daylight time.

--- tzoffset.tcl        Thu Dec 18 03:09:36 2003
+++ tzoffset.tcl.new    Sun Apr 18 14:42:53 2004
@@ -83,11 +83,15 @@
                set lconfig  [db $db open /State/LocationConfig]
                set setup [db $db open /State/ServiceConfig]
                if { [string range $tivoswversion 0 2] >=4.0 } {
-                 set setuptz [dbobj $lconfig get TimeZoneOffset]
+                 set setuptz [expr [dbobj $lconfig get TimeZoneOffset] / 3600]
                } else {
                  set setuptz [dbobj $lconfig get TimeZoneOld]
                }
-               set daylightsavings [dbobj $lconfig get DaylightSavingsPolicy]
+               try {
+                 set daylightsavings [dbobj $lconfig get DaylightSavingsPolicy]
+               } catch foo {
+                 set daylightsavings ""
+               }
        } else {
                set setuptz [dbobj $setup get TimeZone]
                set daylightsavings [dbobj $setup get DaylightSavingsPolicy]

I would expect that the offset is relatively foolproof when read this way, but locales which do not support DST might be handled differently in 4.x/5.x.

[mogulguy]

I was wondering if there was an easy way to insert tmf extracted shows directly on the tivo from the command line. I have a large ext2 partition on my tivo which I would like to use to backup shows. mfs_ftp is awesome, but what I need is an easy local way (on the tivo) to take advantage of it. This leaves me with 3 questions:

1) Is there already a script to insert a tmf file into the NowShowing list manually from the command line?

2) Does anyone have a tivo ftp client (this might be a roudabout way to use mfs_ftp?)

3) Any thoughts of hacking mfs_ftp to have cmd line parameters to insert/extract directly? Would it be easy enough to simply hack the $info(dc) port to point to a local file or fifo? (I've never done any tcl programming.)

Thanks,
-Martin

[rc3105]

insertion from ext2 & network mounts was public a good 6 months before mfs_ftp, search oughta turn up the utils