Printable View
Is it possible to have this program also have MPEG available? (Sorry if this has already been asked, this thead is gigantic...) It seems that TyStudio just tags some header info onto the TY file to convert to mpeg; could this do that as well dynamically? Would be great to get rid of one extra step.
There are other Tivo hacks that already do that pretty well. The strength of mfs_ftp is that you can use a regular ftp client to extract a recording as well as INSERT a recording. Right now, it's the only way to move recordings between Tivos. The fact that is uses FTP means that you can easily develop your own front end.Quote:
Originally posted by Dank
Would be great to get rid of one extra step.
I believe tystudio can go direct to MPG in one step but I'm not sure that tystudio is still actively developed.
What would be sweeter is if we had a process whereby we go straight to a ready-to-burn DVD directory structure. Though, We're pretty close to that already with tytool. I think there's a 5 step process that can have you burn an already extracted recording in less than 1 hour.
That is definitely a stength of this, but in my mind (and my usage) the strength of this program is that it brings the tivo closer to being a true internet multimedia device. By using FTP instead of TyTool or TyStudio, just about any computer that can access the network my tivo is on can grab the files with no additional software necessary. But since most computers cannot play TY files, they need additional software installed to either convert it to MPEG (using TySyudio or TyTool) or to install MPlayer or the DirectShow plugin in order to watch the video.Quote:
Originally posted by cojonesdetoro
There are other Tivo hacks that already do that pretty well. The strength of mfs_ftp is that you can use a regular ftp client to extract a recording as well as INSERT a recording.
If the files could just be grabbed by FTP and then watched via any random DVD player program, with no extra steps required, it would be awesome.
The closest you can get right now is to watch a direct stream from mplayer. Mplayer will play a file without even copying it. I think it will stream and play right from the Tivo. I haven't read the details but I believe they have it working. I think it still doesn't support random access (FF/Rew/skip,etc ), it just plays the stream as it gets it.Quote:
Originally posted by Dank
If the files could just be grabbed by FTP and then watched via any random DVD player program, with no extra steps required, it would be awesome.
There is an mplayer version on the Xbox that supposedly works in this manner.
Yes, there is such an mplayer. I use it. But it is nothing close to what I am asking for for this software...Quote:
Originally posted by cojonesdetoro
The closest you can get right now is to watch a direct stream from mplayer. Mplayer will play a file without even copying it. I think it will stream and play right from the Tivo.
Why are you so against having the mpeg header put on the front of the file? Do you not see the benefit of being able to use generic, non-tivo, software to be able to extract and watch the tivo? Why are you against this seemingly simple feature??
many many MANY moons ago I looked into direct mpeg / vob extraction. (before this was released actually) works great, 'bout 700k/sec. the bottleneck being the tivo doesn't have a lot of horsepower & ty->mpg is more than just adding header info
2 main problems
most folks wanting mpg plan to burn dvd or vcd - exporting mpg directly opens a pandora's box of support / format questions (even as mpg tivo video is still kinda wacky)
mplayer, XBMP, XBMC & mythtivo allready play ty and there's a ms mediaplayer directshow filter in the works. why burden the tivo with the extra load when there are plenty of ty enabled apps???
--
Riley
"seemingly" is the operative word. I'm not trying to belittle your idea but I have followed the development of a lot of these projects. I am no developer myself but have worked around them enough to know that what seems simple can sometimes require a great deal of effort to materialize.Quote:
Originally posted by Dank
Why are you against this seemingly simple feature??
MFS_FTP was designed to be an extraction and insertion tool but not a conversion tool. There are already other hacks to do that well so there's no point in "re-inventing the weel". It would be better to create a script that can FTP a file down to a PC from a mfs_ftp tivo server and then use tytool to convert it to mpg all in one motion. That can be done in a batch file or written in VB.
BTW, the best procedure I have found for getting a recording to a DVD is here:
http://www.dealdatabase.com/forum/at...&postid=102993
Written by DDB user Just4Fun
It works for all recordings that are not "broken" (there are some recordings that have problems whereby the Tivo can still play them but nothing else will play or convert them properly).
ABTW, the Tivo does not record dvd compliant mpg streams but there are hacks for that too. Without these hacks, the Tivo makes mpg streams that will play properly on a lot of new DVD players but some older ones are screwey.
Yes, and since the developer has said it isn't actually as simple as I thought, then I understand why it isn't in product. Oh well, it would have been nice.Quote:
Originally posted by cojonesdetoro
"seemingly" is the operative word.
Actually, you are trying to belittle my idea... You are saying there is no use for it, because there is other software for extraction, when the whole point of my idea is the need for no tivocentric software on the PC. So saying "other conversion tools do this" is 100% misguided, because my whole goal is making a system that needs no clientside conversion tools. That means no VB scripts, no TyTool batches, nothing other than a standard FTP client and standard DVD software.Quote:
I'm not trying to belittle your idea but I have followed the development of a lot of these projects. I am no developer myself but have worked around them enough to know that what seems simple can sometimes require a great deal of effort to materialize.
MFS_FTP was designed to be an extraction and insertion tool but not a conversion tool. There are already other hacks to do that well so there's no point in "re-inventing the weel". It would be better to create a script that can FTP a file down to a PC from a mfs_ftp tivo server and then use tytool to convert it to mpg all in one motion. That can be done in a batch file or written in VB.
I know how to write batches, I know how to convert the FTP'd TY to MPEG, I know how to write software to automate that process. I am a programmer by profession. But if I have to write clientside software or scripts, then it isn't what I'm looking for here. Makes sense? I understand that YOU don't see the need in this, and YOU want mfs_ftp to just move files between your tivos, but that doesn't mean other people can't use the tool for other purposes.
But since rc3105 says its too much drain on the TiVo, then I guess it can't be done. I'll accept a technical rationale, but you can't convince me that nobody wants the feature that I want, because I know at least one person who wants it...
it's perfectly doable, 700k/sec is still better than realtime for most recordings. I just don't have any compelling reason to release / support it ;)
for the do-it-yourselfer, 1.2.9f, line 508 is
exec $info(path)/mfs_stream -s $fsid >@$info(dc) 2>/dev/null
port typrocess from TyStudio to the tivo and change line 508 to something like this
exec $info(path)/mfs_stream -s $fsid 2>/dev/null | typrocess -pipe -mplex { -V -f 3 } -demux >@$info(dc) 2>/dev/null
don't think that syntax is quite right but you get the generall idea, pipe from mfs_stream into typrocess & then from typrocess out the ftp data channel
--
Riley
Well... good for you. I didn't write anothing about it not being useful. I merely stated that mfs_ftp was not designed with that in mind whereas other tools are more evolved along those lines. I think that's a fair statement. I'm sorry that you found my response insulting. I wasn't trying to "talk down" to you but I thought I was dealing with a newb. So, seriously, I apologize if I ruffled any feathers.Quote:
Originally posted by Dank
I know how to write batches, I know how to convert the FTP'd TY to MPEG, I know how to write software to automate
Riley seems to have given you a pretty good answer. Piping it the way he shows looks like it would work. You'd just have to make sure you name the file with an mpg extension.. but I'm sure you already knew that. If you manage the CPU usage, the Tivo may even be usable while doing all this work. Let us know how it goes.
BTW, if you have an FTP client that can output to <stdout> like wget or curl you can pipe it right at the client side without having to have an intermediary file. That would be easier than porting typprocess to the Tivo.
maybe something like:
wget ftp://tivo:3105/ty/recording -o - | typrocess ... > mpegfile
(not sure of syntax here, of course)
I use a technique like this to transfer recordings between tivos using my linux box as an intermediary with a command like this:
curl --options get tivo1 | cur --options put tivo2
the bytes come into the linux box from tivo1 and make a hairpin turn (through a buffer) to tivo2. Fun stuff. It... mostly works. :-/
I've been able to automate the batch transfer of many recordings without the need of intermediate disk space. It still craps out once in a while and I haven't figured out why.
This should even work under cygwin/windows
AsI stated in earlier threads. FXP would be even better but I could never get it working right. This technique let's me watch the transfer and detect an error which can trigger an automated response (restart mfs_ftp, retry copy, delete partial file, etc.)
Would there happen to be any work underway to get mfs_ftp to work with ftpfs? I would like to mount my tivo mfs_ftp as a drive on my linux box that I am using for an ftp server. It would allow for simpler sharing of ty files over the internet with the security of my linux Proftp server.
If there is any other way to add security to MFS FTP, I would appreciate ant tips from the pros.
Milhouse.
I think more securtiy for mfs_ftp was in rc3105's to do's that he listed earlier in the thread.
Also remember that mfs_ftp is a single threaded app. You have to make sure that two people don't try to get a recording at once. Most FTP servers are tunable in this way so I'm sure ProFTP can accomodate this.Quote:
Originally posted by milhouse
sharing of ty files over the internet with the security of my linux Proftp server.
I like the idea of sharing directly from the Tivo. THe alternative is to copy the tmf files to your PC and using that edonkey program some guys are using to share shows. It creates a lot of storage demands. The advantage of Edonkey/PC is that more than one recording can be shared at once and the recording can be dloaded from multiple sources if more than one person is sharing the same tmf file.
Don't worry about those errors... It installed. Everyone gets those.Quote:
Originally posted by CptKirk
I just tried to install v129f on the Tivo and got the following errors.
...
tar: Error exit delayed from previous errors
Just try it out and verify that its working; if it isn't then ask again.
RC;Quote:
Originally posted by rc3105
if savepath.txt is in the directory with tmf2ty_cfg.exe the first line of the file is used as the output path. these are tcl paths so use forward slashes like so
x:/extracts/ - d:/my_recordings/ - v:/video_files/
having troublegetting path to change to my d:/extracts/ line specified in the savepath.txt that resides in the same directory as the .exe
it says it can't create the path or doesn't exist. Yet it does create it on c: however I don't have enough room for the file to be extracted there, and it fails about 3/4 the way through.
it just seems to ignore my savepath.txt file.
I had this issue as well.Quote:
Originally posted by Hi8
RC;
having troublegetting path to change to my d:/extracts/ line specified in the savepath.txt that resides in the same directory as the .exe
it says it can't create the path or doesn't exist. Yet it does create it on c: however I don't have enough room for the file to be extracted there, and it fails about 3/4 the way through.
it just seems to ignore my savepath.txt file.
put the savepath.txt file in the same folder that you have the TMF file in, NOT where the EXE file is.
So for all my TMF folders, I have the same savepath.txt file there.
It will create a folder with the name of the show under the path specified in your savepath.txt file
my savepath.txt file is
e:/tivo/video/ty
I created it on the tivo with JOE and then ftp'd it down to my computer, because i didn't have a copy of dos2unix.exe handy.
HTH
I had the same sluggish upload performance that others had reported earlier in this thread. It was taking 40 min to insert a 30 min show.
The fix was: (As previously mentioned)
runideturbo=false
For example: (Make sure of the parms, and the reboot)
bash-2.02# bootpage -p /dev/hda
root=/dev/hda7
bash-2.02# bootpage -P 'root=/dev/hda7 runideturbo=false' /dev/hda
bash-2.02# bootpage -p /dev/hda
root=/dev/hda7 runideturbo=false
bash-2.02# reboot
Now it can insert a 30 min show in 10 min.
I have found that lftp (http://lftp.yar.ru/) may be the best CLI FTP client for linux to use with MFS FTP. It uses FXP which facilitates direct tivo-to-tivo transfers. It also has nice scripting and bandwidth throttling features.
It also has a workaround that stymies other FXP clients. Since MFS_FTP is single threaded, I think you can't "talk" to it while it's doing an FXP transfer. This means you can't get stats to see how fast the transfer is going. LFTP has an option to turn off stat checking. You also have the option of doin tivo-to-tivo transfer using the LFTP client as a hairpin (no local storage of files needed). It seems to transfer much more slowly this way but you can monitor progress.
EDIT: of course, you can still tail -f /var/mfs_ftp/port.3105.log to view progress so there's not real reason not to use fxp
.
Here's a sample script of the syntax I've used:
script listing:
open tivo2 -p 3105
set ftp:use-stat false
cd tmf
get "{Beer, Hot Chix and Baby Oil}{1970-01-01}{}{11.35 PM Tue Sep 09, 2003}{PPVP}.tmf" -o ftp://tivo:3105/tmf/
set cmd:move-background false
wait all
quit
called with:
lftp -f tempftpscript.txt
Note: The two tivos I have resolve to 'tivo' and 'tivo2'. Substitute your names or IP addresses for those in the script.
EDIT: lftp is also available for cygwin so it may be the best CLI FTP client for Windows and MFS_FTP as well.
http://cygwin.com/cgi-bin2/package-c....6-1&grep=lftp
(I haven't tried it.)
I have an unsubbed SA1 16MB and it's pretty stable. In fact, I've seen more stability issues with tivoweb. Maybe you've got a corrupt DB? Riley suggested that mfs_check program earlier. He says it's mostly harmless but I found that it shuts down one of the main tivo programs and you have to reboot after using it.Quote:
Originally posted by philhu
Does the newest mfs_ftp work with Series 1 standalones with 16meg? But loaded with 2 120g HD's?
I've tried a few versions. It crashes the tivo while trying to enumerate the list of programs......
Edit: Did you find any messages in /var/mfs_ftp/port3105.log?
Just to add a little perspective to the "why can't mfs_ftp generate clean mpeg" question, I've been using mfs_ftp since 1.2.5 (and in fact am still using that version) and was one of the alpha tresters for tystudio. I think some here would not believe the amount of work that went into tystudio to get it to the point of being usable (and I was just testing it, not developing it), and it was (maybe still is) imperfect when I lost track of the project.
The version I have (and I think it's been pretty much static since Olaf went travelling), does a pretty good job of converting .TY files to MPEG, using the resources of a regular PC, but still doesn't (didn't) handle AV sync correctly in cuts.
So for material requiring editing (eg removing commercials), I still do an analog capture and edit and re-encode the resulting AVI files.
For material requiring only start and end trimming (eg uninterrupted movies), here's my procedure:
Extract from tivo using mfs_tools v1.2.5
Convert the TMF file to TY using a version of tmf.exe that Riley whipped up for me way back. It puts the result into X:\extract (hardcoded path), but subst lets me manufacture an X: drive if my PC doesn't already have one.
Convert to MPEG with TyStudio 0.5.0. Trim only the start and end. Bounce the end point 8 clicks beyond where I want the actual cut and I'll ususally get all the program material. (It has trouble stopping where I tell it, so the extra margin is necessary.)
remux the MPG file with TMpegEnc. This seems to reduce problems down the line.
Simple demux, again with TMpegEnc
Pull the audio into my general editor, look at the audio waveform by eyeball. Usually requires 2X or 3X amplification to achieve anything approaching correct recording levels. Apparently the tivo amps up audio more than my DVD playback card and TV together can. Maybe this is a way to shave bandwidth?
Recompress the amplified audio to MPA (time consuming, but it works. Leave it at 48 kHz to avoid any further degradation from resampling.
Remux the video with the new MPA file.
Done!
Sounds like a lot of handling, and it is, but I can do it faster than real time end to end... if I watch 1 movie while I work on the next, I can keep the TV running continuously as long as I can stay awake. And I'm using 1.5 gHz class PCs.
Comment:
I imagine the current tools are in some way better than the ones I've been using, or they wouldn't still be in flux. But I stopped uograding when things became workable and reliable. First rule of software: if it's not too badly broken, don't fix it any more.
2nd Comment: Can y'all imagine the CPU drain on the poor little tivo if it had to do all that work itself, to spare the much bigger/faster PCs the job of post processing?
3rd Comment:
Many thanks to:
Surgeon for 25Xtreme (and to all the people who made the pieces that went into it),
Kraven for his update (and those who made the bits that went into *it*),
Riley for mfs_ftp
Olaf and the gang for TyStudio (I hope the bugs eventually get worked out, but I use it almost every day anyway)
I love my Tivo, but I love it 10 times as much with tivoweb, the extraction tools, and mfs_ftp.
Riley's my HERO! (He, if we can single out any one person, made extraction work for me. After all, for me, it's not the tinkering that's fun, but getting results.)
You may want to consider extracting a "ty+" file with mfs_ftp instead of a tmf file. The "ty+" filetype is re-insertable like a tmf but can also be directly used by tystudio without an additional conversion step.Quote:
Originally posted by misato
Convert the TMF file to TY using a version of tmf.exe that Riley whipped up for me way back.
That's a thought. The TMF.EXE step is by far the fastest of the bunch, so there's not a lot of speed motivation to try upgrading, but it's something to try when I get the itch.
So there is a benefit to Ty+ file extraction over tmf.Quote:
Originally posted by rung
The "ty+" filetype is re-insertable like a tmf but can also be directly used by tystudio without an additional conversion step.
Is there any benefit to tmf extraction?
Can tmf files be considered 'deprecated'?
I imagine that support would have to be continued because there are archived recordings around that need to be inserted.
the ty & ty+ from mfs_ftp and tmf2ty are exactly the same thing
they're insertable and can be processed into mpg or played by any current utility
tmf are only required for archiving scrambled recordings and some of mfs_ftp's optional features (check the readme)
Before I try it I thought I would ask.
If I record a ppv or HBO or Showtime ect. movie on my dtivo and insert it onto a friends dtivo that did not buy the ppv and/or does not subscribe to the movie channels are we asking for DTV/tivo legal trouble?
Just wondering,
thanks,
mikey
Hi. First off, just like to say wow! I love this little gem you whipped up Riley! I had some shows that I stored about a year ago on my hd and I have been dumping them back onto my DTivo T60 all day now. I love it! BTW, they were extracted with TivoApp if that helps anyone out.
I've been reading through this thread and I see a few people who have reported insertion bottlenecks. I am another one I guess. I can't really make out what has worked for others though. On the extraction side, I get about 1900 KB/s. I'm very satisfied with that of course. On the insertion side though, I only get about 250 KB/s if I'm lucky. I've tried changing the insertion priority from 10 to 3 and ithrottle from 1 to 4 in both the settings.tcl and mfs_ftp.tcl files. That didn't seem to do a darn thing. Maybe even slowed me down a touch.
Anyway, did I miss something? Did I adjust these settings in the wrong direction? What can I do to bump up my insertion throughput? I even tried putting the machine into standby mode which made little to no change. Any suggestions. I'm willing to try anything.
Thanks.
edit: the most likely problem is the ideturbo module is loaded. check the readme & earlier in the thread where that's discussed - Riley
I think it falls under "fair use" like giving a friend a video tape. As long as you don't circumvent encryption then you do not violate DMCA ( in USA). "fair use" says you can give a friend a video tape but you can't distribute the tape widely and show it to a large audience.Quote:
Originally posted by mikey
Before I try it I thought I would ask.
If I record a ppv or HBO or Showtime ect. movie on my dtivo and insert it onto a friends dtivo that did not buy the ppv and/or does not subscribe to the movie channels are we asking for DTV/tivo legal trouble?
Just wondering,
thanks,
mikey
Sharing the shows ala napster/gnutella might more likely be illegal but that doesn't seem to be stopping some people.
My .02$, though. Someone will correct me with great pomposity, I'm sure. ;^>
Okay... I just noticed something else. First let me explain quickly how FTP works (forgive me if you already know this stuff)Quote:
Connecting to 192.168.1.101
Connected to 192.168.1.101 Port 3104
220 Mfs_Ftp ver 1.2.9F - {sock23} from "192.168.1.100:2989"
[/B]
FTP needs to open two connections, a control connection and a data connaction. The control connection will always orginate from the client to some fixed port on the server. The data connection will either originate from the client, if in passive mode, or the server, if in active mode.
In the case of mfs_ftp, 3105 is the control channel but, somehow, you're using 3104 as the control channel. That might explain why passive mode is choosing 3103. Did you make a change in mfs_ftp to listen on 3104?
Make sure your forwarding
port 3105 on the outside to tivo port 3105 on the inside
port 3104 on the outside to tivo port 3104 on the inside
Oh, yeah, remember... Pokemon.. ;-/
when inserting a large file, the tmf file will stream, the ty file will get stuck after some time until the transfer is complete and the xml information that is at the end is processedQuote:
Originally posted by rc3105
tmf are only required for archiving scrambled recordings and some of mfs_ftp's optional features (check the readme)
<slap to the forehead>Quote:
Originally posted by cojonesdetoro
Okay... I just noticed something else. First let me explain quickly how FTP works (forgive me if you already know this stuff)
Y'know... I just looked at the readme and it has a whole lot of valuable information in there. Yes, active FTP is supported and its the prefered method because it's faster. So try getting the router/firewall working with active. Opening port 3105 should be enough if you do active transfers.
well, yes & no. the new recording doesn't have the same type of "roots" in the mfs db as a regular recording. as far as dtv/tivo knows you just recorded something manually & renamed it with tivowebQuote:
Originally posted by mikey
Before I try it I thought I would ask.
If I record a ppv or HBO or Showtime ect. movie on my dtivo and insert it onto a friends dtivo that did not buy the ppv and/or does not subscribe to the movie channels are we asking for DTV/tivo legal trouble?
Just wondering,
thanks,
mikey
this is partly lazy & partly on purpose. personally I DO NOT want the tivo to skip recoding something because it was inserted once upon a time & went into the recording history :)
edit:
an inserted ppv won't be logged to the access card or phoned in by the dtv side of the unit - however - the tivo logs will contain the original ppv info (name, date, time, channel) & upload to the mothership unless you run something like logsnull. it's unlikely tivo / dtv compare notes that closely but better safe than sorry. if you insert janet-superbowl & slowmo the halftime show 50 times tivo will know :eek:
one other thing
the terms of use explicitly prohibit any commercial or illegal use
you can record home videos, security camera footage, product demos or anything you hold copyright to & transfer / share it (I actually do this btw) but please don't distribute anything illegally - hollywood will freak, tivo will have to respond (again) and it'll just make things difficult for everybody
Is the remote computer behind a firewall? If it is, the firewall needs to know how to handle active FTP. Active FTP means that the Tivo will be originating a TCP connection back to the remote computer whe you try to copy or do dir listing. Look at the firewall documentation to see if it supports active FTP. If it doesn;t then either use the PC outside the firewall or you're stuck with passive.Quote:
Originally posted by Karpa
I can run in active mode inside my firewall, but outside I have to run passive. I assume that I would have to open a port on my remote computer to get the back route for active. Is this correct?
If you must use passive then make sure you forward port 3105 on the outside-of-the tivo router to port 3105 on the tivo. Do the same for 3104.
There's not much more you can do beyond this here. If it's not working then keep trying. What you showed me before showed that you were forwarding 3105 to 3104 on the tivo.
First of all thanks Riley for a superb utility!:)
With tivo -> tivo transfers, using smartftp, I'm getting an active outgoing connection but passive incoming connection, so overall transfer speed is about 263 KB/s. Both tivos have port 3105 open and are within my LAN and behind my NAT/Router (as is the PC running smartftp). mfs_ftp is of course running on both tivos having opened up 3105 by default.
Is this the limit or can tivo->tivo run active connx?
Thanks
dialanothernumb,
From reading about FXP on the SmartFTP it appears that FXP can only use passive mode transfers. Or, perhaps SmartFTP only supports passive transfers using FXP. Either way, it seems we are limited to passive.
To everyone/anyone:
I tried using MFS_FTP for the first time last night. I got the latest versions from the first post in this thread and installed/ran it on two DSR6000s. I then got the latest SmartFTP (v1.0 build 979) and installed/ran it on my laptop. I initiated an FXP transfer of an NFL Sunday Ticket game (so it is better than 4 hours of recording) from one box to the other. I left it running over night.
This morning I checked the destination DTivo and found that it was showing the new "Now Playing" entry as still recording. Checking the MFS_FTP logs I found a "broken pipe" error. I don't have the full error message with me (had to hurry in to the office). From what I have read here, I understand that I should be able to delete the failed recording through the MFS_FTP program. Is there anything in particular I should look at regarding the "broken pipe" error message?
a ftp transfer is between server & client tcp sockets. when the server is active then the ftp client is passive. when the transfer is server - server one server must act as a client & run passiveQuote:
Originally posted by dialanothernumb
First of all thanks Riley for a superb utility!:)
With tivo -> tivo transfers, using smartftp, I'm getting an active outgoing connection but passive incoming connection, so overall transfer speed is about 263 KB/s. Both tivos have port 3105 open and are within my LAN and behind my NAT/Router (as is the PC running smartftp). mfs_ftp is of course running on both tivos having opened up 3105 by default.
Is this the limit or can tivo->tivo run active connx?
Thanks
passive mode extracts don't suffer from the tivo tcp bug as much as inserts do. if the sending tivo happens to run passive & the recieving tivo runs active then fxp transfers run pretty much full speed, otherwise you see the passive mode insert slowdown :eek:
rc3105-
I've asked in here a few times now. It seems to be ignored.
Does the latest version fix the problem with a large series 1 tivo with ALOT of shows and 16 meg crashing as mfs_ftp tries to enumerate the files in the tivo?
We spoke about this a while back and you said it was due to the way you get the names and I should try an older version and you'd look at it for a future version.
Any fixes found?
try it & see, I dunno. it works fine here on a hdr112 with 300+ recordings. the tivo itself is so slow as to be unusable with that many shows, (2 mins to go from livetv to nowplaying) but insert & extract works fine
RC3105... I want to start off by thanking you for MFS_FTP...
I just upgraded from 1.2.8g to 1.2.9F and everthing seems to be working. I can transfer shows but I noticed a couple of things that seem different.
1. When I initially sign on it seems like it takes considerably longer between entering the username and prompting for the password. 1.2.8g used to prompt almost immediately. .9F takes about 15 seconds to prompt for password. Is this normal?
2. When I start up mfs_ftp it displays: catch close lastsock val "can't read "info(lastsock)": no such element in array". Is this nomal?
Again, Thanks for the great tool.
yes & yes. F builds the cache before enabling the control socket so login can take a bit longer. the failed catch close on startup is normal - verbose logging on new functions/features makes troubleshooting from posted logs easier :)
I thought I read somewhere in this thread that you can now extract and insert ty+ files. I tried to do this and the file seems to insert ok except the show info is incorrect - it uses the filename (i.e. 123456 {Seinfeld...). Is that supposed to happen?
What format should I use to extract if I want to reinsert and also play files directly from my PC? Are there players that can play tmf files?
Is there some documentation available for mfs_ftp beyond what is in the readme.txt file. It doesn't go into too much detail on this issue.
Can anyone point me in the correct direction to troubleshoot slow insertions? When inserting I am lucky to get 160k/sec (according to the log). I am using the network drivers that came with version 3.0 of the TiVo software and I don't believe I have made any changes to the mfs_ftp.tcl file. I have tried looking through this thread but it is like looking for a needle in a haystack.