Page 47 of 99 FirstFirst ... 3745464748495797 ... LastLast
Results 691 to 705 of 1476

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

  1. #691
    Join Date
    Mar 2002
    Posts
    1,339
    Quote Originally Posted by blueman2
    I have moved all my hacks from the /var directory due to the fact that /var can be (and has been!) deleted by the Tivo. However, I cannot move mfs_ftp outside of /var because mfs_ftp requires a read/write capabilty (port3105 log file, cache files). Has anyone placed mfs_ftp outside of /var, and if so, did you change the location of the log and cache files so that they point to a directory in /var for read/write access? How?
    add this to rc.sysinit or rc.sysinit.author to make root writable before mfs_ftp loads
    Code:
    cd /
    mount -no remount,rw /
    ---
    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

  2. #692
    Join Date
    Jul 2004
    Location
    California
    Posts
    298
    rc3105,

    Thanks. I had heard that leaving your main partition (hda7 or hda 4 depending on setup) as r/w was dangerous. I guess I need to chose the lesser of two evils (risk losing hacks in /var or risk corruption of my main application directory by leaving it rw).

    I was hoping there was some way to direct mfs_ftp to use directories in /var/temp, for example, for its log and cache files.

  3. #693
    Join Date
    Mar 2002
    Posts
    1,339
    it's not preferred, but I've had root rw on some of the s1's for years now w/o any problem


    here's one method of auto-restoring hacks to var from rc.sysinit or rc.sysinit.author. first create the reference copy

    tivo:/var/tmp$ cd /
    tivo:/$ tar -zcvf /mfs_ftp.tgz /var/mfs_ftp

    then add something like this to the startup script before it tries to load mfs_ftp

    Code:
    #untar if mfs_ftp.tcl isn't found
    if [ ! -f /var/mfs_ftp/mfs_ftp.tcl ]; then
      echo "untarring /var/mfs_ftp"
      cd /
      tar -zxvf /mfs_ftp.tgz
    fi
    tar preserves file permissions & directory structure. if mfs_ftp.tcl exists it doesn't unpack, if var's been nuked a copy is restored

  4. #694
    Join Date
    Mar 2004
    Posts
    12

    a symlink might work...

    Quote Originally Posted by rc3105
    add this to rc.sysinit or rc.sysinit.author to make root writable before mfs_ftp loads
    Code:
    cd /
    mount -no remount,rw /
    Probably not ideal, but how about using symlinks?
    ln -s target name
    Not sure if it'de work, but u could recreate a symlink
    to /var/ on each bootup.

    ignac

  5. #695
    Join Date
    Jul 2004
    Location
    California
    Posts
    298
    Actually, symlinks might work perfectly. I could symlink the port.3105.log file over to /var/log and symlink the mfs_ftp/cache directory over to something like /var/mfscache. I remember how to do file symlinks, but need to bone up on doing directory symlinks.

    Thanks for the idea!

  6. #696
    Join Date
    Jul 2004
    Location
    California
    Posts
    298
    Yes, the symlink idea appears to work. I put mfs_ftp into a directory called /hacks in the root of hda7 (or hda4 depending on your setup). I did the following two commands:

    tivo:/hacks/mfs_ftp$ ln -s /var/log/port.3105.log ./port.3105.log
    This will direct any writes to the port.3105.log file over to the /var/log directory which is writable. I deleted port.3105.log before issuing this command.

    tivo:/hacks/mfs_ftp$ ln -sdF /var/cache ./
    This creates a virtual directory called "cache" in /hacks/mfs_ftp that is really just a link to a directory called cache in /var which is writable. You must first create the directory /var/cache, and delete the directory ~/mfs_ftp/cache.
    Last edited by blueman2; 11-06-2004 at 03:49 AM.

  7. #697
    Join Date
    Mar 2004
    Posts
    12

    glad it worked

    Quote Originally Posted by blueman2
    Yes, the symlink idea appears to work...
    glad it worked.
    i have never experience /var/hack being deleted by tivo
    and have a s2sa running 4.x software.
    if you have or ever figure out what causes the deletion,
    lemme know so it doesn't happen to me !

    ignac

  8. #698
    Join Date
    Jan 2004
    Location
    n.h. usa
    Posts
    957
    If you do some searching you will find your answer:
    var gets cleanup (ie deleted and rebuilt) automatically periodically by the tivo when it gets too big.. ie passes a certain size... so don't put too much junk on it... don't know what the size threshold is...

    also keep a complete backup of it on your pc ... I do in case it happens to you so you can easily rebuild the box...

  9. #699
    Join Date
    Jun 2003
    Location
    Somerset, England
    Posts
    1,124
    Quote Originally Posted by lgkahn
    If you do some searching you will find your answer:
    var gets cleanup (ie deleted and rebuilt) automatically periodically by the tivo when it gets too big.. ie passes a certain size... so don't put too much junk on it... don't know what the size threshold is...
    No size threshold - it rebuilds /var if it fails the boot time filesystem integrity check, after first having tried to fix it.
    Stuart

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

  10. #700
    Join Date
    May 2004
    Posts
    34
    Hopefully this isn't a repeat question.. I tried searching many times but didn't seem to see this problem mentioned. The problem I'm having is when transfering shows from a DVR40 (running 3.1.1c) to a HDVR2 (running 4.0.1b). I'm using SmartFTP to transfer the shows using the tmf format. The file transfer makes it over ok (albeit a bit slow ~450kB/sec), but the date information is incorrect. This causes error messages about the scheduled recording expiring.. similar to this thread http://www.dealdatabase.com/forum/sh...hlight=expires. The difference is that in my case mfs_ftp isn't being aborted and successfully transfers the shows.. the port.3105.log shows the show transferring, and exiting with a status of 0 (which I assume is fine).

    Some information about my systems:
    Hughes DVR40 - Sleepered (1.02), mfs_ftp (1.2.9p), sw 3.1.1c

    Hughes HDVR2 - sw 4.0.1b-02-2-240, killhdinitrd 4.0.1a kernel, mfs_ftp(1.2.9p), HMO superpatch 4-all

    I'm not using folders on the HDVR2.

    Has anyone else seen this problem before?

    thanks,
    steve

  11. #701
    Join Date
    Jan 2004
    Posts
    140

    Gong!

    I am using smartftp and am getting the following error. It seems as if on an hour show it will only ftp over 38 min and a 30 min show goes over fine. Any help would be greatly appreciated
    inserted 511 meg at 618k/sec
    Done

    Exiting with error code 0
    05:12:55:AM - ty2fsid: fsid{257852}
    05:12:55:AM - header descriptor is "crc m"
    05:12:55:AM - gong! not a header
    05:12:55:AM - ty2fsid: fsid{257852}
    05:12:56:AM - header descriptor is "@@@@@"
    05:12:56:AM - gong! not a header
    05:12:56:AM - ty2fsid: fsid{257852}
    05:12:56:AM - header descriptor is "DHG<J"
    05:12:56:AM - gong! not a header
    05:12:56:AM - ty2fsid: fsid{257852}
    05:12:56:AM - header descriptor is "ef@YN"
    05:12:56:AM - gong! not a header
    05:12:56:AM - ty2fsid: fsid{257852}
    05:12:56:AM - header descriptor is "> @.9"

  12. #702
    Join Date
    Mar 2002
    Posts
    1,339
    Quote Originally Posted by cdma
    I am using smartftp and am getting the following error. It seems as if on an hour show it will only ftp over 38 min and a 30 min show goes over fine. Any help would be greatly appreciated
    that's caused by the "junk" in the cracks between fsid space used & allocated

    anything destined to be re-inserted should be extracted as tmf instead of ty to avoid that

  13. #703
    Join Date
    Aug 2004
    Posts
    4,085
    Quote Originally Posted by rc3105
    that's caused by the "junk" in the cracks between fsid space used & allocated

    anything destined to be re-inserted should be extracted as tmf instead of ty to avoid that
    Just a thought, but would it help if mfs_export/mfs_stream and friends had an option to write only the used space rather than the allocated to stdout? Perhaps then the ty/ty+ streams could avoid having this junk in the cracks between parts. Since I've got those tools open for surgery anyway, it would probably be an easy change.

  14. #704
    Join Date
    Mar 2002
    Posts
    1,339
    wouldn't hurt
    ---
    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

  15. #705
    Join Date
    Sep 2004
    Location
    Los Angeles
    Posts
    71
    Quote Originally Posted by steve457
    Hopefully this isn't a repeat question.. I tried searching many times but didn't seem to see this problem mentioned. The problem I'm having is when transfering shows from a DVR40 (running 3.1.1c) to a HDVR2 (running 4.0.1b). I'm using SmartFTP to transfer the shows using the tmf format. The file transfer makes it over ok (albeit a bit slow ~450kB/sec), but the date information is incorrect. This causes error messages about the scheduled recording expiring..
    Something similar sounding happened to me. I have been moving some shows from a disk connected to a PC to an HDVR2 using mfs_tmfstream to extract and mfs_ftp to import. Older shows were transferring without errors from mfs_ftp, but would immediately disappear. I had the shows marked "keep until I delete" on the original disk, but that data evidently wasn't being transferred, so the receiving tivo would conclude that it needed to delete the show because it was old and it needed the space. I solved the problem by changing the keep until date while the transfer was still in progress using the tivo UI.

    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.

Posting Permissions

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