Page 48 of 99 FirstFirst ... 3846474849505898 ... LastLast
Results 706 to 720 of 1477

Thread: Mfs_Ftp: extract, archive, restore & transfer recordings

  1. #706
    Join Date
    Aug 2004
    Posts
    4,075
    Quote Originally Posted by jbuehl
    It looks like mfs_ftp does stuff with the expiration date, but I don't see a tag for "Expiration Date" in showing.xml, so that would explain why this happens. It seems like that would be pretty easy to include by mfs_tmfstream, so unless there's a good reason not to, I'll make those changes and send them to Jamie.
    I think I saw something like this too, and it may have been with a show extracted using mfs_tmfstream. It's probably worth looking over the xml generated by mfs_tmfstream to compare it to what mfs_ftp produces when extracting in tmf format. If you want to do this and send me the changes, I'll be happy to merge them into the "unified" source tree.

  2. #707
    Join Date
    Mar 2002
    Posts
    1,335

    RTFM error

    the mfs_ftp settings file determins whether imported recordings are stored as save-until-delete or suggestion

    suggestion is the default because the season pass scheduler gets wierd if you have too many save-until-delete


    very rarely will the original expire info be of any use - use the remote or tivoweb to change the save until date
    ---
    Give a man a fish and he will eat for a day. Teach a man to fish and he will sit in a boat all day and drink beer

  3. #708
    Join Date
    Aug 2004
    Posts
    4,075
    Quote Originally Posted by rc3105
    the mfs_ftp settings file determins whether imported recordings are stored as save-until-delete or suggestion
    ok. my test box has a full MFS with no suggestions, which probably explains why newly inserted programs sometimes seem to disappear immediately after they are inserted with mfs_ftp.

  4. #709
    Join Date
    Sep 2004
    Location
    Los Angeles
    Posts
    71
    Quote Originally Posted by rc3105
    the mfs_ftp settings file determins whether imported recordings are stored as save-until-delete or suggestion

    suggestion is the default because the season pass scheduler gets wierd if you have too many save-until-delete

    very rarely will the original expire info be of any use - use the remote or tivoweb to change the save until date
    RTFM error? Well, partly. According to the manual:

    "info(saveuntil): determines how a recording is stored. options are
    suggestion (expires in a week) & delete (save until I delete)"

    For some reason, probably because of not much available space, shows imported with mfs_ftp were being instantly deleted with saveuntil=suggestion. I see in your code that you are setting the expiration date to today+7, but while the show was being imported and I went to the keep until screen, the setting was "keep until space is needed", not today+7. Maybe SelectionType has something to do with it.

    Granted it may not be too useful, but I don't think it would be a bad thing to allow the option to use the original expiration date. I'll send you the changes I made and you can include it in your distribution if you want.

    I haven't noticed the wierdness with the season pass scheduler that you mention.
    Last edited by jbuehl; 11-14-2004 at 12:25 PM.

  5. #710
    Join Date
    Sep 2003
    Posts
    3
    I've searched this thread, and don't see the answer to this.

    How do I mfs_ftp a program that has 2 partial recordings? I have a program that shows up twice as "{XXX}{Title}{00:00 Sun Jan 1, 2004}.ty" because the program was interrupted in the middle. (It shows up twice on TiVo).

    I'm using ncftp, and it 'get'ting the file just gets one part, and 'mget' with wildcards doesn't work.

    Thanks in advance.

  6. #711
    Join Date
    Dec 2001
    Location
    Austin, TX
    Posts
    34

    How to get 2 parts of a recording

    edit your settings.tcl file to set the info(name_detail) to a 1
    then phoenix your mfs_ftp. when you do a ls, you will see outpot like this:

    12345 - Show Title - Episode Title.ty
    12356 - Show Title - Episode Title.ty

    you can simply do a get 12345.ty then a get 12356.ty and you will get both parts of the recording...
    =-BAHitman

    3 HDVR2 - 1x160G 4.01b
    3 DSR7000 - 1x160G 4.01b
    1 Tivo 60hr - 1x60G 7.1

    TiVo - The best thing since Color TV!

  7. #712
    Join Date
    May 2004
    Posts
    34
    I noticed a problem with the tzoffset.tcl script when running against 4.0.1b-2-02-240. I have a HDVR2 and noticed that the dates reported by mfs_ftp were always way off. After some digging.. I noticed that in the tzoffset.txt file there was this line:

    set info(tzoffset) -103680000

    Well I knew this was way off, as this should be the number of seconds difference from GMT+0, and I am on the West Coast (GMT-8). I ran the tzoffset.tcl script on my same HDVR2 running 3.1.1e and it would return -28800. I tried again on 4.0.1b on the same box, and got -103680000.

    So I started tinkering with the tzoffset.tcl script, and found that the variable setupz that is set from /State/LocationConfig seems to be incorrect for 4.0.1b. In 3.1.1e the value in /State/LocationConfig was an integer that would map to the integer array later used in get_tzoffset, but in 4.0.1b the value was actually the number of seconds from GMT. So what was happening was that this value was being multipled by 60*60 unnecessarily causing the incorrect value.

    I changed the line in get_tzoffset_one from

    if { [string range $tivoswversion 0 2] >=4.0 } {
    set setuptz [dbobj $lconfig get TimeZoneOffset]
    }

    to this

    if { [string range $tivoswversion 0 2] >=4.0 } {
    set setuptz [expr [dbobj $lconfig get TimeZoneOffset]/3600]
    }

    and now it is returning the correct value of -28800.

    Has anyone else noticed this problem before? And does my change sound like it should work for all cases?

    -steve

  8. #713
    Join Date
    Feb 2004
    Location
    Chicago
    Posts
    877
    Quote Originally Posted by steve457
    I noticed a problem with the tzoffset.tcl script when running against 4.0.1b-2-02-240. I have a HDVR2...
    Steve,

    I have the exact same setup as you, and can confirm the same type of miscalculation for the offset. However, I never noticed it / ran into the problems, since I have 2 HDVR2s, and recently upgraded one from 3.1.1c to 4.0.1b. After rebuilding the one machine with 4.x, I simply tar'd the mfs_ftp directory on my 3.x machine and untar'd it on my 4.x machine. As a result, tzoffset.txt was already present and correct, and thus never got recalculated and generated with the incorrect offset value.

    I suspect this is why it has gone undetected for as long as it has...

    Of course, therefore, another quick fix, without addressing the root cause of the problem, is just to modify tzoffset.txt directly with the correct offset, since it only gets regenerated by tzoffset.tcl when tzoffset.txt is not present.

    John
    Last edited by JohnSorTivo; 11-18-2004 at 01:26 PM.
    1 HR10-250, upgraded to 570 SD hours, hacked, 6.3b.
    1 HDVR2, upgraded to 206 hours, hacked, 6.2.
    1 HDVR2, upgraded to 168 hours, hacked, 6.2.
    tyExtract - Automated batch extraction utility
    YacMon - YAC Server log monitor for new call(s) notification via email/text message

  9. #714
    Join Date
    May 2004
    Posts
    34
    John,
    I did realize that I could just modify the tzoffset.txt file directly, but kind of wanted to find the root cause, so that maybe the script could be modified in the mfs_ftp package so others won't encounter the problem.

    I just realized my fix won't work for all cases (if your timezone is greater than GMT+0), and a better fix would be to do this.

    In the procedure

    proc get_tzoffset {mfstz dst}

    modify this block:

    if { $mfstz <= 0 }
    {
    set tz $mfstz
    } else {
    set tzlist "-5 -6 -7 -8 -9 -10 0 1 2 3 4 5 6 7 8 9 10 11 12 -1 -2 -3 -4 -11 -12"
    set tz [lindex $tzlist [expr $mfstz - 1]]
    }

    to look like this:

    if { $mfstz <=-3600 || $mfstz >=3600 }
    {
    set tz [expr $mfstz/3600]
    } else {
    if { $mfstz <= 0 }
    {
    set tz $mfstz
    } else {
    set tzlist "-5 -6 -7 -8 -9 -10 0 1 2 3 4 5 6 7 8 9 10 11 12 -1 -2 -3 -4 -11 -12"
    set tz [lindex $tzlist [expr $mfstz - 1]]
    }
    }

    Basically, I just want to set the tz variable to the number of hours difference from GMT+0. So if the value that's passed in happens to be the number of seconds difference (as from v4.0) it will be converted to the number of hours.

    -steve

  10. #715
    Join Date
    Feb 2004
    Location
    Chicago
    Posts
    877
    Quote Originally Posted by steve457
    John,
    I did realize that I could just modify the tzoffset.txt file directly, but kind of wanted to find the root cause, so that maybe the script could be modified in the mfs_ftp package so others won't encounter the problem.
    Yep, I completely concur:
    Quote Originally Posted by JohnSorTivo
    Of course, therefore, another quick fix, without addressing the root cause of the problem, is just to modify tzoffset.txt directly
    Just wanted to put it out there for those looking for a "quick fix".
    1 HR10-250, upgraded to 570 SD hours, hacked, 6.3b.
    1 HDVR2, upgraded to 206 hours, hacked, 6.2.
    1 HDVR2, upgraded to 168 hours, hacked, 6.2.
    tyExtract - Automated batch extraction utility
    YacMon - YAC Server log monitor for new call(s) notification via email/text message

  11. #716
    Join Date
    Nov 2001
    Location
    Southern California
    Posts
    938
    Well Steve, I to am West Coast, running an HDVR2 @ 4.0.1b-2-02-240
    I just modified my script per your 1st fix, and it works for me.
    Everything seems to be accurate now.

  12. #717
    Join Date
    Jul 2004
    Posts
    26
    Does anyone know where I can find mfs_ftp 1.2.9Q ???

    I searched and searched and all I seem to come up with is Version P. If you post a like to the thread or directly to the file. It would greatly be appreciated.

  13. #718
    Join Date
    Jun 2003
    Location
    Somerset, England
    Posts
    1,124
    Q had a time out on it, and it expired. P is the most current available version.
    Stuart

    Newbies - see if your questions are answered here Experts - can you add to the knowledge stored here? Developers - are your hacks listed here?

  14. #719
    Join Date
    May 2002
    Posts
    234

    just downgraded from 1.2.9p

    I've been running a custom version of 1.2.5 (adding BLST to it) since it came out, but due to problems uploading files back to the tivo I upgraded a couple weeks ago to 1.2.9p and solved the upload problems.

    however I just downgraded back to 1.2.5 for normal use (listing and saving shows from the tivo) becouse of the following problems

    1. 1.2.9p doesn't seem to properly cache the listings so every list request takes 30 seconds while it rebuilds the list from scratch

    2. the nlst function doesn't work properly. it doesn't properly work with many wildcard filenames (for example *name* generates an error and restart of mfs_ftp) and it does not appear to properly match even on simple lings like FSID* (it appears to trim the last digit from the FSID before doing the match)

    as a result I'm going to have to run 1.2.5 for everything except inserting shows (it still has problems handleing errors on inserts so I'll have to keep 1./2.9p installed for that)

  15. #720
    Join Date
    Apr 2002
    Posts
    69
    Sorry for adding to the clutter here with a dumb question that may have been covered elsewhere, but I'm having problems navigating through this new fourum format. I haven't been back to this forum for many months, and I'm a bit out of touch.
    I have 2 unsubscribed series 1 TIVOs, both running version 2.51 of the TIVO software. About year ago, I installed MFS_FTP on both TIVOs. I experimented briefly just to verify that I could download and then upload recordings, and everything seemed to work. Since then, I have been occasionally pulling down recordings for archiving, but haven't had the occasion to ever play anything.
    Recently, I put in a new hard drive in my second TIVO, so I downloaded and installed a NEW version of MFS_FTP.
    Today, I tried to upload to TIVO2, a recording which had been downloaded from TIVO1, and it started uploading, but it said that it would take something like 12 hours to upload???? Also, it didn't appear in the now showing list. So I aborted the upload after a couple minutes. I tried two files, both of which downloaded in an hour or less on a slower (TIVONET) machine, so they should go faster up to my faster (TURBONET) machine.
    I also tried to copy this recording (a 5.7 GB file) from one PC hard disk to a second hard disk (a nearly empty 60GB drive), and it said that there wasn't enough disk space for the file to fit!?!?!?! Somehow, even though the file on the PC says that it is 5.7 GB, that it is being interpreted as something 10times bigger than that when I go to transfer it anywhere.
    I read the readme file with the new version, and now, I see some comment about downloading a DiskConfigurationKey. I don't understand this, because I remember that one of the original features was to be able to go from one TIVO to another, which would be to a different disk. Ie I don't remember this being an issue with the old version I had been using.
    Anyway, can anyone explain why it seems like these files are being interpreted as being so big, and why they don't show up on NowShowing? And can someone explain under what circumstances I need to use the DiskConfigurationKey thing?
    Thanks.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •