Mfs_Ftp: extract, archive, restore & transfer recordings

[rc3105]

If I change saveuntil to delete will mfs_ftp delete shows that are deleteable (ones with yellow circle and exclamation point), or only suggestions?

space issues: if needed mfs_ftp will reclaim space from deleted-but-
recoverable recordings. if there aren't any it'll delete suggestions
as necesary. it will NOT delete anything besides a suggestion. if the
tivo is truly full it will abort the transfer & put this msg into the log

"unable to allocate space for recording, you MUST delete something from
Now Playing"

this is normal tivoapp behavior, when you tell it to record something it
makes room if possible. while insertion isn't strictly recording it's
the same deal - you told it to put a show in NowPlaying. if it was
allready full something had to go to make room.

nope, only suggestions. if you change "set info(active) 0" to "set info(active) 1" in settings.tcl the ftp client will list deleted recordings - you can tell at a glance if there's enough space to insert w/o bumping anything

[goony]

Installed mfs_ftp just a few days ago on two HDVR2s.

I can pull a .tmf file just fine from "Box A" to my PC (using WS_FTP client), but when I try to push the file to "Box B" it conks out quickly... any suggestions on where to start looking/troubleshooting?

Thanks!!

sending {While You Were Out}{2004-02-13}{San Diego Flight Path Patio}{07.00 PM Sat Feb 21, 2004}{TLC}.tmf as {While Yo
TYPE I
200 Type set to I
PORT 192,168,0,30,6,196
200 PORT command successful.
STOR {While You Were Out}{2004-02-13}{San Diego Flight Path Patio}{07.00 PM Sat Feb 21, 2004}{TLC}.tmf
150 Opening BINARY mode data connection for "{{While You Were Out}{2004-02-13}{San Diego Flight Path Patio}{07.00 PM S
! Send error: connection reset
Transmitted 90112 bytes in 2.0 secs, (433.28 Kbps), transfer failed

[tivoq]

AddPart frequently fails for me on an insertion and tvlog shows

FsRegion Free space too low

I presume this is because there is not enough available disk space, or a big enough
contiguous block, or some other filesystem structure.

In reality there is plenty of free disk space on this machine, but it almost all shows in TWP/info as deleted. THe TWP ui/deleted files shows me several days of deleted files.

This is never a problem when I do an actual recording, since myworld knows how to reclaim the space from the deleted space as needed. My guess is that mfs_sdtinsert does not.

Can I force the deleted files to be reclaimed?

This is on a 3.0 SA series 1 machine.

[rc3105]

1) mfs_stdinsert has nothing to do with allocating space for a recording

2) turn your mfs_ftp debuglevel up to see why it's failing

3) mfs_ftp 1.2.9 reclaims space from deleted recordings & will even nuke suggestions to make room

4) make sure you have the current version. old corrupted copies from cobelli/sleeper/etc don't work right, bumping/allocation is one of the missing features

[SteveJenkins]

Hey, guys!

I'm running mfs_ftp 1.2.9, and I'm trying to use FXP with FTP Voyager to transfer a show from TiVo2 (in the theater) to TiVo1 (in the living room). I've been hit and miss in the past when transferring shows between TiVos with mfs_ftp (about 50/50 success rate) and so I figured I'd see if there is anything I can do to increase that rate.

The attachment is what I'm seeing in my FTP clients (TiVo2 is the source on the left, and TiVo1 is the destination on the right).

Even after those timeouts (and after I've pressed cancel in the FTP client for the transfer), a ps aux on TiVo2 shows:

root 271 12.0 4.5 1452 640 ? S 03:05 1:29 /var/hack/mfs_ftp/mfs_tarstream -x -s 2518937 2518939 2518940 2518941

And a ps aux on TiVo1 shows:

root 261 0.0 3.4 1540 484 ? D 06:44 0:43 /var/hack/mfs_ftp/mfs_stdinsert 113588 -

Which leads me to believe it's still TRYING, but it never gets anywhere.

If I kill the mfs_tarstream process (#271 in this example) on TiVo2, then an FTP client can once again log in to mfs_ftp and display the shows. But extraction still no worky. The mfs_stdinsert process on TiVo1 (destination) goes away on its own a few moments after I kill the process on TiVo2 (source).

Extracting from TiVo2 to my PC works fine (in fact, I'm doing that as I type this, and getting about 1.33MB per second). Once the file is done, I'll test to see if inserting to TiVo1 from PC goes without a hitch, too.

I'd appreciate any nudges in the right direction.

Thanks,

Steve Jenkins

[SteveJenkins]

Also, FWIW - it seems that the upload/insert craps out at 512MB (two times in a row, same place). That's a "computery" enough number (divisible by 8) that I can't believe it's cooincidence. Is that some sort of limit that I can overcome?

Thanks,

Steve

[rkshack]

bootpage -q /dev/hda command reported root as hda7.

Looks like something caused my hda9 partition to wipe out--there are ON files in /var
Therefore, I assume I need to rebuild all my hacks--unless I'm missing something.

I'm running DTivo Series 1 DSR6000--with straight 3.1.0b software--(non-extreme). So an additional question is should the ideturbo=false work?

Thanks again for your help!

Don V.

My hacks all disappeared. I reinstalled them but did you ever find out what caused it?

[BTUx9]

Also, FWIW - it seems that the upload/insert craps out at 512MB (two times in a row, same place). That's a "computery" enough number (divisible by 8) that I can't believe it's cooincidence. Is that some sort of limit that I can overcome?

512M is Very computery, and happens to be the largest part size for a recording. (anything >512M has multiple parts)
If you have bjuggle on, turn it off.
If that doesn't help, try turning debug level (dbl) up to 9, and share the results.

[BTUx9]

My hacks all disappeared. I reinstalled them but did you ever find out what caused it?

When the var partition gets close to full, the tivo cleans it out (including any hacks therein)

[joeyfig]

How do you Shut down mfs_ftp?
368 posts and it does not tell you that. guess its something you should know

Thanks

[jodell]

How do you Shut down mfs_ftp?
368 posts and it does not tell you that. guess its something you should know

Thanks

I am pretty sure that the readme that comes with mfs_ftp tells you to log into the tivo vis ftp and get "shutdown.txt".

Getting "phoenix.txt" will restart mfs_ftp.

Happy shutting down.....

Jeff

[NutKase]

Also, FWIW - it seems that the upload/insert craps out at 512MB (two times in a row, same place). That's a "computery" enough number (divisible by 8) that I can't believe it's cooincidence. Is that some sort of limit that I can overcome?

Thanks,

Steve

I had this for weeks. It's a bad mfs_stdinsert binary. Try some others.

NutKase

[SteveJenkins]

512M is Very computery, and happens to be the largest part size for a recording. (anything >512M has multiple parts)
If you have bjuggle on, turn it off.
If that doesn't help, try turning debug level (dbl) up to 9, and share the results.

I'm sorry... bjuggle?

Edit: Ah... set info(bjuggle) 0. Yeah, mine is zero.

Cranking debug to 0 and giving it a go.

[SteveJenkins]

It's a bad mfs_stdinsert binary. Try some others.

To your knowledge, is the MrBlack version limited to S2?

Thanks,

Steve

[BTUx9]

To your knowledge, is the MrBlack version limited to S2?

Yes, it is. Try re-installing from the latest 1.2.9p tar file.