Can't see anything amiss there.
Printable View
Can't see anything amiss there.
nothing so sinister ( allthough I am left handed :p ) just split 'em out to a discussion thread - this being in the support forum - and added a link in the first postQuote:
Originally Posted by NutKase
Questions & Comments. / Mfs_Ftp: suggestions, feedback, etc
will get some structure one of these days...
this'll be moved over to the discussion thread in a day or three, but here's a partial reply:Quote:
Originally Posted by Noneentered
knowing then what I know now, would've done SO many things differently :eek: since the way-back machine is on the fritz hopefully the mid-course corrections won't be too painfull
gotta finish the legal thing to cover my posterior in case DTV/RIAA/HMO/Playboy/Discovery/whoEVER take exception lossless digital archives
the revision numbering schema needs an overhaul (release candidate 1,2,3...final method seems reasonable) non-expiring versions may be even numbers or some such, still pondering
fork a version + thread for folks willing to test new features (now that there's a development forum)
rework / polish / finalize features & implement a modular extension system
talk some people into releasing some very cool utils that've been private for a while, and 17 other things I can't think of right this second
all of which takes time, energy & inclination. when somebody buys a hacked s2 off ebay, trashes mfs trying to insert tytool extracts & pm's or phones very little gets done. (just as happy tinkering with xbox / ps2 / astronomy projects) when somebody paypals a few bucks I check if there's a feature they'd like and add it (if feasable). when e-mail comes in from a 4 year old watching his fav blues clues (that dad/aunt sally/whoever transferred) there may be a flurry of activity & a dozen upgrades in a week (funny how folks get all their friends / family hooked on tivo - then shuffle recordings around via rw dvd or broadband)
got a working dtivo with blown tuners? plenty of munchkins sure could use it - might even make for a nice deduction - think daycare tivos stocked with sesame street ;)
not trying to be flip or anything, but 3k downloads (not counting folks perfectly happy with 1.2) & the paypal donations wouldn't cover an afternoon's salary. the code remains tcl so anyone can read / learn from it and in an effort to help keep this site / hobby solvent it's hosted here with alternate distribution restricted to encourage board membership (which in part determins advertising revenue) - I don't see any of that $ or board donations, but Vadim's got bandwidth to pay for :eek:
it's a hobby. only so many hours in the day...
Hey, well I'm left handed too. I'll learn the new structure soon. :)Quote:
Originally Posted by rc3105
NutKase
I'm having a similar problem as mbriody and I think after reading this post, I am on the trail to figuring it out. First, I've installed and reinstalled several versions of mf_ftp and all have the same problem. I'm currently at version 1.2.9Q on an S1 SA and note that other things are working (telnet, ftp, tivo_web, etc.). I start mfs_ftp and after about 10 seconds, the following message appears:Quote:
Originally Posted by mbriody
can't open object (0x11029)
while executing
"db $db openid $fsid"
("uplevel" body line 1)
invoked from within
"uplevel $body"
invoked from within
"transaction {uplevel $body}"
(procedure "RetryTransaction" line 5)
invoked from within
"RetryTransaction { set xml "[dump_xml [db $db openid $fsid]]" }"
(procedure "cache_xml_2_disk" line 15)
invoked from within
"cache_xml_2_disk $fsid"
(procedure "rec_info_from_db" line 22)
invoked from within
"rec_info_from_db $fsid"
(procedure "update_rec_fsids" line 24)
invoked from within
"update_rec_fsids 1"
(procedure "init_procs" line 11)
invoked from within
"init_procs"
(file "./mfs_ftp.tcl" line 1672)
After this happens, ps shows that the process no longer exists. It's interesting to note that when veiwing the "Now Showing" list in TivoWeb Plus, sorted by classic, I get an error that also references not being able to open object (0x11029).
So my guess is that something is corrupted. Maybe something in my now showing list? If my guess is correct, I could probably delete a bunch of shows like mbriody and eventually it would run. However, the purpose of running mfs_ftp on the S1 is so that I can copy shows from it to the new DTiVo S2. (Note that mfs_ftp is working just fine on the DTiVo S2.)
So I was wondering if you all think I'm on the right track here. And if so, how could I figure out which specific show (or shows) is corrupted so I could delete it?
Thanks!
P.S. I bought my original S1 over 2 years ago and I must say that hacking has come a long way since then. I got my DTiVos (2 of them) just a couple of weeks ago and I'm way further along in hacking them than I ever was on my S1. At some point over a year ago, I got 2 TiVo updates in a row which trashed all my hacks. I was frustrated and didn't want to take the driver back out of the TiVo to start over. So thanks to ALL who have written such great software and to those who have contributed to these forums.
You might want to look in mfs (in tivoweb?) at fsid 69673 -- that's 0x11029 in decimalQuote:
Originally Posted by hpt42
I suspected something in my Now Playing was causing the problem.
The entries in my cache directory were all 6-digit numbers except 657.pts and 657.xml. This happened to be the one before the entry that it was crashing out on.
How does your cache directory look?
Yeah, I was (and still am) going down that path, but I can't find that fsid anywhere. But then again, this is a bit new to me so I'm not entirely sure I'm looking in the right place. I've been browsing /Recording/NowShowingByTitle and other similar places. Is this the right place to look?Quote:
Originally Posted by BTUx9
There are 10 .pts files and 10 .xml files. I deleted them all and re-ran mfs_fpt, and sure enough, it created the exact same files in the cache before quitting. I've matched these 10 ids to shows in my now playing list, but I can't figure out what the order is. That means I can't figure out which entry would be next. How did you figure out which entry it was crashing out on?Quote:
Originally Posted by mbriody
Doh! Just remembered that ls -l sorts alphabetically, not by date. I figured out the order.
I had a different error from you (see earlier) and the name was in the error.
Have you tried looking at the mfs_ftp.log?
try looking at the 10th and 11th items in /Recording/NowShowingByClassicQuote:
Originally Posted by hpt42
the 11th should be the fsid that's crashing (or it may be within the 10th)
also try http://<tivoaddress>/object/69673
It appears to be working now. Thanks for mbriody and BTUx9 for your help!
Yep... and it wasn't too helpful. Before I fixed (?) the problem, it looked something like this:Quote:
Originally Posted by mbriody
06:38:16:PM - sourcing settings
02:38:19:PM - updating cached recording info
Along with some dots. (I'm guessing 10 of them) Now it has two lines worth of dots and other messages from where I logged in successfully.
Once I figured out which show it was, I simply clicked on it using the MFS browser (?) in TivoWeb Plus. What's surprising to me is that I didn't have to delete it. Not sure the problem is completely fixed, but at least MFS_FTP is running now.Quote:
Originally Posted by BTUx9
(Thanks for the tip!) This is what makes me believe there is still a problem. Here's what I get in my browser:Quote:
Originally Posted by BTUx9
INTERNAL SERVER ERROR
--cut here--
action_object '/69673' ''
no such object (0x10009)
while executing
"mfs size $objectid"
("uplevel" body line 2)
invoked from within
"uplevel $body"
invoked from within
"transaction {uplevel $body}"
(procedure "RetryTransaction" line 5)
invoked from within
"RetryTransaction {
set size [mfs size $objectid]
set chunksize 4096
fconfigure $chan -translation binary
for {set i 0} {$i < $size} {i..."
(procedure "do_file" line 2)
invoked from within
"do_file $chan $objectid"
(procedure "::action_object" line 13)
invoked from within
"::action_$action $chan $part $env"
("eval" body line 1)
invoked from within
"eval {::action_$action $chan $part $env}"
--cut here--
Anyway, I learned a lot today. Thanks for all of your help.
That was co-incidence in your case I think. IDs are allocated sequentially; the 657 on yours was the "Welcome to TiVo" video - ie, one of the very first IDs ever allocated. On most TiVos the IDS are in a fairly tight range.Quote:
Originally Posted by mbriody
Pretty sure 0x11029 is an error code, not a reference to the missing object?Quote:
Originally Posted by BTUx9
Yep, couldn't be sure from the context, so thought it was at least worth a look, but I'm pretty sure you're right.Quote:
Originally Posted by sanderton
Guess that's why I couldn't find it. ;)Quote:
Originally Posted by sanderton
Status update: I've transfered most of the programs I wanted to keep from my S1 to S2. mfs_ftp is amazing! It just works. Kudos to Riley! And also to many others for posts that helped me get this far.
-T
dunny what's causing the 0x11029 errors, but there's also a tivoweb module you can try to extract tmf archives
I have a problem here :
UK tivo, latest version tivowebplus, new working cachecard 512Mb, latest version Mfs_Ftp - installed as per readme using tar -xvf mfs_ftp.tar and starting from bash.
Connecting using FileZilla. Connects OK I can download and upload successfully, but live tv is seriously affected, pixelation freezing etc. especially while connecting and moving between directories.
I've looked around but can't find similar probs/solutions reported
Any one got any ideas?
I don't have a cachecard, but it sounds like the priority on its driver may not be set right, since what you're describing is heavy access to mfs, and that's when the cachecard is used.Quote:
Originally Posted by ponto
Another thought: You don't have multithreaded turned on in mfs_ftp, do you? That could result in heavier loads, too.
Thanks for the quick response, I haven't enabled multithreading, may well be the cachecard driver priority, anyone here using a cachecard successfully?Quote:
Originally Posted by BTUx9
What settings are you using for priorities on mfs_ftp?Quote:
Originally Posted by ponto
On inserts I can quite easily get the symptoms you describe (UK, Cachecard) if I turn up the throttle and insert proprity too high.
Not seen it with downloads though. Don't know if it does it on connect as I'm by my PC when I do that!
I haven't changed the default settings.tcl, if thats what you mean?Quote:
Originally Posted by sanderton
Still don't know why I'm seeing this problem, solved it though using setpri after seeing post from alphawolf here:
http://www.dealdatabase.com/forum/sh...ad.php?t=33819
d/l from here for s1 http://tivo.samba.org/download/mbm/bin/setpri
usage: setpri fifo 1 $$
Thanks for a great utility, works well!!
I keep trying to load ty+ files onto my DirecTivo running the latest mfs_ftp w/ the v4 binaries (running 4.0.1b) but it keeps failing for some reason. In TWP, it shows up as a 42MB file, if I try to play it, TiVo reboots. The ftp upload finishes just fine... it just doesn't get loaded correctly.
I was able to successfully load .ty files though. Any ideas on how I could fix this? Is there a ty+ -> ty converter?
IIRC ty=ty+ the only time it's different is if you use a different app besides mfs_ftp to extract. Then it's a 'true' ty file (with no embedded xml data). Either one should insert fine, though. I think true ty files just insert with the file name as the recording name and no other data shown in the NP and prgr description.
The ty+ files I have were extracted with the exact same version that I'm trying to use to insert them. I've tried renaming them to .ty, .tmf, neither works.
I looked in the logs, and the only error that shows up is from the .ty+ files renamed to .tmf, otherwise... everything looks fine.
Quote:
Originally Posted by hd_lone_rider
I don't see any answer to this question. I have exactly the same error message when I start up MFS_FTP 1.2.9Q. This is the first time that I've started MFS_FTP after the install so all configuration is default.
Dale
hrm, that means the xml data in the /Recording/Active item is overwhelming the dump_obj procedure. guess you'll need to stick with plain old info(active) 0 until I get that reworked
Riley,
Thanks for the reply. I meant to say that the error message was identical to the one quoted. Mine has nothing to do with the set info(active) configuration since, as I mentioned in the previous post, the configuration is set to the default. Default for set info(active) is 0.
I have 3 Series 1 tivos. I just installed MFS_FTP 1.2.9Q on one of the other ones and it works fine. I assume that I've got a problem in MFS, but I have no idea how to identify what showing it is. Can you help me with that? I'll be happy to delete that showing if I can figure out which one it is. The other thing that I've wondered about is the number of showings in NowShowing. I have around 250. Is that too many?
Dale
this sounds like the old problem with Taken episodes (they're re-running those btw) where the recording object included a whole slew of new AuxInfo objects that broke the dumper. those have been excluded, but perhaps something new's been added
250 recordings could be the issue, but try this first. set info(dbl) to 5 (in settings.tcl) reboot the tivo, zip & attach the log to a post.
I don't have the Taken Series on there. I will set the logging up. I started trying to do a file transfer between an old version of MFS_FTP and the new one that I installed on the other Tivo and the new MFS_FTP disconnects as soon as the transfer begins. So, though I don't know that it isn't an incompatibility with the old one and the new one I wanted to correct the impression that the second install worked. It runs and doesn't abort with the error that I had before, but I haven't actually transferred a showing with it yet.
Here is the log file after running MFS_FTP with the set active(db1) set to 5.
Since it doesn't abort until tertiary info, it's probably a list length issue... try set info(name_detail) 0Quote:
Originally Posted by TivoMind
I have already tried set info(name_detail) 0. It still aborts at startup.
well, the recording it's processing when it aborts is 2269545Quote:
Originally Posted by TivoMind
You can look at that in tivoweb to see if something looks funky.
(it's a Biography)
BTUx9,
The only thing that looks odd about the MFS around that showing is that it does have AuxInfos. I have attached the html source from Tivoweb. I can traverse to the parts, the showing, and from showing to the program. All seems well except the AuxInfos.
I will watch this one, delete it, and let you know if that takes care of it.
Dale
Riley & BTUx9,
Ok, I've got a pretty mixed bag of stuff. I deleted the specific show that was causing the abort error. I launched MFS_FTP with set info(name_detail) 0 and set active(db1) 5. It launched without error this time.
Next I changed set info(name_detail) 5 and set active(db1) 0. I launched MFS_FTP and it aborted. I, of course, have no log as logging was set to 0. When I changed set active(db1) back to 5 and left set info(name_detail) 5. This time it launched without an abort. I have attached the log after the launch.
Next I tried to connect to another Tivo using SmartFTP and do a show transfer. It immediately disconnects when I drag the show between the Tivos. I have tried to drag it between two Tivos running 1.2.9Q. In that instance they both disconnect. I also tried to do a file transfer between 1.2.9Q (the one with the abort difficulties) and a third Tivo running MFS_FTP 1.2.9G (if I remember correctly). In this instance the 1.2.9Q disconnects immediately while the 1.2.9G tries to receive the file and ultimately times out.
The ps aux display on the 1.2.9Q Tivo looks like this during this disconnect status...
root 73 0.0 0.0 0 0 ? SW 01:04 0:00 /tvbin/switcherstartlipCache1:43 0:00 bus handler
root 76 0.4 6.2 6872 868 ? S 01:04 0:09 /tvbin/mfsdSink
root 147 0.3 15.6 1740
root 87 0.0 2.8 1108 392 ? S 01:04 0:00 fancontrolmCs22Sink
04:42:17:PM - calc_t
root 91 0.0 4.5 1268 628 ? S 01:04 0:00 /sbin/dhclient -q ethch0 2964 ? S 00:45 0:19 tivosh ./httpd-tt.tclash-2.02# ls
root
root 117 0.0 0.0 0 0 ? SW 01:04 0:00 /tvbin/mcp
abort.doc license.txt mfs_tarstream set
root 119 0.0 0.0 0 0 ? SW 01:04 0:00 tnlited 23 /bin/bas
bash-
root
root 123 0.0 0.0 0 0 ? SW 01:04 0:00 FsMpStreamSTART TIM
root 131 0.0 0.0 0 0 ? SW 01:04 0:00 FsMpStream
root 132 0.0 0.0 0 0 ? SW 01:04 0:00 PipeListener
root 133 0.0 0.0 0 0 p0 SW 01:04 0:00 /bin/bash -login
root 135 0.0 0.0 0 0 ? SW 01:04 0:00 TmkSinkMixAud
root 136 0.0 13.0 17348 1824 ? S 01:04 0:01 TmkClipCache0
root 137 0.0 0.0 0 0 ? SW 01:04 0:01 TmkClipCache1
root 138 2.5 13.9 17348 1952 ? D 01:04 0:56 TvMomCs22Sink
root 139 0.0 0.0 0 0 ? SW 01:04 0:00 TvMomCs22Sink
root 140 0.1 14.0 17356 1960 ? S 01:04 0:02 Mediaswitch0
root 141 0.0 17.3 17348 2420 ? S 01:04 0:02 TvVideoManager
root 142 0.0 20.4 17348 2856 ? S 01:04 0:01 TvRecorder
root 143 0.0 19.0 17348 2652 ? S 01:04 0:01 TmkTaskManager
root 144 10.4 22.9 17352 3196 ? S 01:04 3:49 Scheduler
root 145 0.0 19.7 17348 2748 ? S 01:04 0:01 Prioritizer
root 146 0.0 17.9 17356 2504 ? S 01:04 0:00 EventLog event
root 147 0.1 19.5 17368 2732 ? S 01:04 0:03 PvrMain
root 148 0.0 0.0 0 0 ? SW 01:04 0:00 bus handler
root 149 0.1 29.0 17400 4044 ? S 01:04 0:04 ContextMgr eve
root 174 4.7 17.8 8316 2484 p0 S 01:17 1:07 tivosh ./mfs_ftp.tcl
root 179 0.0 0.0 0 0 ? SW 01:04 0:00 ./tivoftpd
root 181 16.7 4.6 1460 648 p0 S 01:29 1:56 ./mfs_tarstream -x -s
root 184 0.0 0.0 0 0 p0 RW 01:04 0:00 ps aux
bash-2.02#
It shows ./mfs_tarstream as an executing process.
I don't know what could be the problem here. Can either of you suggest another course of action for me?
1.2.9Q disconnects the control connection whenever you start a fxp transfer. (between tivos or between a ftp server & a tivo) this is intentional & new to Q. transfers should complete on their own w/o any intervention from the ftp client. use the tivoweb logs module & refresh to monitor progress
I assume you mean set info(dbl) 5Quote:
Originally Posted by TivoMind
I would try getting straight ftp xfers working in both active and passive modes, before trying fxp transfers. They're easier to debug.
BTUx9,
Yes, I did mean set info(dbl) 5. Sorry for being imprecise.Quote:
Originally Posted by BTUx9
Riley and BTUx9,
Any idea why set info(dbl) 0 would cause the abort to come back?
Sorry, I didn't realize the control disconnect feature. I will update the third Tivo to 1.2.9Q and move on. I have two of them transferring files (fxp) now. I imagine that they were working before, but I kept interrupting them because I didn't know what was going on.
Sorry to have been such a pest today. Other than the fact that it aborts if I turn logging off on that one machine, I believe I have it working now. If you have any ideas on that I will be happy to hear them.
If I leave logging set to 5 (set info(dbl) 5), how is the log file managed? Do I need to worry about disk space?
Thanks for your help.
Dale
Dale
You may just want to set info(dbl) 1Quote:
Originally Posted by TivoMind
It's hard to imagine under what conditions turning off debugging would cause mfs_ftp to abort, it may just have been coincidence. Did you try turning it to 0 more than once?