Mfs_Ftp: extract, archive, restore & transfer recordings

[rc3105]

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

cd /
mount -no remount,rw /

[blueman2]

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.

[rc3105]

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

#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

[ignacvucko]

add this to rc.sysinit or rc.sysinit.author to make root writable before mfs_ftp loads

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

[blueman2]

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!

[blueman2]

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.

[ignacvucko]

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

[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...

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...

[sanderton]

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.

[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.. 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

[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

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"

[rc3105]

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

[Jamie]

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.

[rc3105]

wouldn't hurt

[jbuehl]

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.