Reply With QuoteGive Riley a paypal appreciation, that will inspire him to finish R!Originally Posted by Hi8
Diamond Member
Thanks.. I guess that's what I get for NOT following this thread that closely!
ironic that the purpose of the expiration was to force people to upgrade, hence I had to downgrade to get things working! ;->
Thanks again Reily; for a truely foundation application for the TiVo. Has to be the most taken for granted app next to mfs_tools!
~Hi8
(4) Hughes SD DVR40
(1) Hughes HR10-250
(2) xbmc XBOX X2 & xbit
Charter Member
Give Riley a paypal appreciation, that will inspire him to finish R!
Riley
heh, ya never know. if I had a quarter for every dowload of version p I'd be working on utils for the hd models
---
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
Charter Member
I'm getting an error on uploading a TMF and TY file.
01:08:05:AM - 226 Transfer complete.
01:08:17:AM - 200 Type set to I
01:08:18:AM - 200 PORT command successful.
retrying after errTmActiveLockConflict ...
retrying after errFsLockConflict ...
01:08:33:AM - rec_info_from_db done
01:08:33:AM - 150 Opening BINARY mode data connection for "{showpart00.ty}"
Dumping mempool to /tmp/BlockFailure.123
-then it reboots-
117mb TY file inside. Tried TMF 1st, same thing.
Noticed in the XML:
<?xml version="1.1" tivoversion="3.1.0-01-1-011"?>
<Object type="Recording" id="_top">
<BitRate>0</BitRate>
<DiskPartitionId>10</DiskPartitionId>
<SubObject type="RecordingPart" id="Part">
<Begin>0</Begin>
My Tivo is version 2 though, is the 1st line a problem?
Riley
rage:
yep, next rev will expire more gracefully
newbr:
original sw version shouldn't make any difference
edit settings.tcl to increase the debug level to 5
# comment mfs_ftp out of rc.sysinit.author (so if it reboots it won't automatically start & overwrite the old log)
try the insert again
if it reboots dl the entire mfs_ftp log, zip & attach to a post
---
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
Diamond Member
I have noticed something strange and have a question about it... if you have two shows with the same name say the power went out in the middle of a recording or your box rebooted and it came back up and started to record again you get two recordings with exactly the same name but they are different recordings... mfs_ftp shows two file names exactly the same...
but which one does it get when you ftp it.. or it appears it is not possible to get both... maybe the next version should also add the fsid as part of the name????
i.e.
ftp> cd tmf
250 Directory change successful.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
-rwxr-xr-x 1 0 0 000226492416 Jun 09 09:00 {5 Days to Midnight}{2004-06-09}{Part Three}{09.00 PM Wed Jun 09, 2004}{SCFI}.tmf
-rwxr-xr-x 1 0 0 000780140544 Jun 09 09:00 {5 Days to Midnight}{2004-06-09}{Part Three}{09.00 PM Wed Jun 09, 2004}{SCFI}.tmf
226 Transfer complete.
ftp: 278 bytes received in 0.68Seconds 0.41Kbytes/sec.
ftp> bye
thanks
Last edited by lgkahn; 06-10-2004 at 10:30 AM.
Diamond Member
You get the first one, no matter which one you select. Use TiVoWeb to cahnge the name of one, or switch to a mfs_ftp naming convention which has the fsid in it.
Charter Member
Here is the debug level 5 log.
02:43:05:PM - abort_check: "STOR"
02:43:05:PM - readlinefromsocket: "sock47 192.168.1.105 1201"
02:43:05:PM - echo to verify: "PORT 192,168,1,105,4,183"
02:43:05:PM - parseline:
"PORT 192,168,1,105,4,183"
02:43:05:PM - PORT 192,168,1,105,4,183
02:43:05:PM - data channel "sock49" to 192.168.1.105:1207
02:43:05:PM - 200 PORT command successful.
02:43:05:PM - readlinefromsocket: "sock47 192.168.1.105 1201"
02:43:05:PM - echo to verify: "STOR {Mike}{2001-06-22}{Quest}{05.30 PM Sat Sep 27, 2003}{TBS}.tmf"
02:43:05:PM - parseline:
"STOR {Mike}{2001-06-22}{Quest}{05.30 PM Sat Sep 27, 2003}{TBS}.tmf"
02:43:05:PM - STOR:
"STOR {Mike}{2001-06-22}{Quest}{05.30 PM Sat Sep 27, 2003}{TBS}.tmf"
02:43:05:PM - make_blank_rec: "{Mike}{2001-06-22}{Quest}{05.30 PM Sat Sep 27, 2003}{TBS}.tmf"
bgerror invoked with error
" commit failed (0x00070009)
"
re-initializing mfs_ftp
close the current ftp connection and simply open another
"core dump"
...then it restarts....recording is scrambled, but I've inserted scrambled recordings w/o probs before. Of the 200 or so recordings I've reinserted back to Tivo after rebuilding it, about 5 of them failed similarly. They show up on NP but they won't play [error playing a recording] even with autoscramble on. They don't play in windows media player for obvious reasons (since they are scrambled) but the tmf extract came from MFS_FTP before.
Charter Member
here's another one:
STOR {Cocoon}{1984-12-31}{}{03.40 AM Wed Jan 14, 2004}{FMC}.tmf"
07:41:24:PM - make_blank_rec: "{Cocoon}{1984-12-31}{}{03.40 AM Wed Jan 14, 2004}{FMC}.tmf"
07:41:24:PM - created blank recording {1186562}
07:41:24:PM - rec_info_from_db: recobj{1186562}
07:41:24:PM - Cocoon}{1984-12-31}{}{03.40 AM Wed Jan 14, 2004}{FMC}.tmf k
07:41:24:PM - cache_xml_2_disk: recobj{1186562} force cache = "0"
07:41:24:PM - recording in progress, don't cache 1186562.xml yet
07:41:24:PM - calc_tertiary_info: recobj{1186562}
07:41:24:PM - rec_info_from_db done
07:41:24:PM - 150 Opening BINARY mode data connection for "{{Cocoon}{1984-12-31}{}{03.40 AM Wed Jan 14, 2004}{FMC}.tmf}"
07:41:24:PM - parse_tmf:
07:41:24:PM - xml_from_tmf:
07:41:24:PM - tarpart is "showing.xml"
07:41:24:PM - open/create "./cache/1186562.xml" & writing
<?xml version="1.1" tivoversion="3.1.0-01-1-011"?>
<Object type="Recording" id="_top">
----------- snip XML and XMl analysis seemed OK ----------------
07:41:25:PM - setrecinfo: recobj{1186562}
07:41:25:PM - {Cocoon}{}
Retirees (Don Ameche, Wilford Brimley) swim among alien pods and feel young again.
07:41:25:PM - tmf2fsid: recobj{1186562}
07:41:25:PM - filename: part00.ty
07:41:25:PM - fname4: part
07:41:25:PM - partnum: 00
07:41:25:PM - starting segment "part00.ty"
07:41:25:PM - Bytes from file: 142606336
07:41:25:PM - AddPart: "1186562" - "142606336" bytes
07:41:25:PM - AddPart stream allocate errval
"1186565"
07:41:25:PM - AddPart: retryev
""
07:41:25:PM - added part "1186565" of "136" meg
07:41:25:PM - set priorities: mfs_ftp 1 % I/O chan 10 %
importing fsid 1186565 of size 142606336
100% 136 meg 1254k/sec
inserted 136 meg at 1254k/sec
07:43:15:PM - tmf2fsid: recobj{1186562}
07:43:15:PM - end of file or invalid segment - leaving tmf2fsid
07:43:15:PM - tmf2fsid: recobj{1186562}
07:43:15:PM - parse_tmf: catch close info(dc) errval ""
07:43:15:PM - recobj{1186562} is 136 meg
07:43:15:PM - 226 File transfer complete
07:43:15:PM - set_rec_csos: recobj{1186562}
07:43:15:PM - "1" xml parts and "1" db parts
07:43:15:PM - finalize_rec: "1186562
07:43:15:PM - abort_check: "ping_pong"
bgerror invoked with error
" commit failed (0x00070009)
"
re-initializing mfs_ftp
Charter Member
Of the 400 I reinserted as TMFs, about 20 didn't go; they were various sizes. Is there a util to detect if the TMF is corrupt? They all open in Winrar.
here's xml and a log from one insert.
Charter Member
I'm having trouble running mfs_ftp on one of my 2 S1 DTivos. One unit has a relatively medium size Now Showing list (around 80 entries) - mfs_ftp ver p runs fine on that one. The other Tivo has a large Now Showing list (over 200 entries). On the large unit I can launch mfs_ftp - I can connect - but when I try to list the contents of the tmf directory it crashes while retrieving it (usually within about a minute).
Here's the tail from my log with the logging level set to 5.
tivo_down:/var/mfs_ftp # tail log
02:44:50:PM - 150 Opening ASCII mode data connection for file list.
02:44:50:PM - list_type is "LIST"
02:44:50:PM - update_rec_fsids: forced 1
02:45:12:PM - updating cached recording info
................................................................................
................................................................................
................................................................................
...........................................................................
02:45:12:PM - build_rec_filenames:
................................................................................
................................................................................
................................................................................
...........................................................................
Dumping mempool to /tmp/BlockFailure.170
tivo_down:/var/mfs_ftp # Tmk Assertion Failure:
BlockFailure, line 2150 ()
Tmk Fatal Error: Thread tivosh <170> died due to signal -2
1ad0738 1acf054 1ac9358 1cf0f40 1cfcd18 1d485f8 1d6cd00 1d6ce10 1d71084 19d3490
1d59f5c 1d479cc 1d6c778 1d59f5c 1d479cc 1d4d2e0 1d59f5c 1d479cc 1d6c778 1d59f5c
1d479cc 1d6c778 1d59f5c 1d479cc 1d47754 19b8500 19ca800 19ca33c 1bc9cbc 1bc90dc
1bc93ec 19c1834 1d4718c 1d59f5c 1d479cc 1d64a64 1d65b70 1cfccb8 1cfca00 1800134
I recall reading something on the site about known issues with mfs_ftp and large Now Showing lists - is there anything I can do to configure mfs_ftp to tolerate it more? I'm thinking maybe it's time for a cachecard.
Thanks for any help - and thanks for mfs_ftp - great tool.
Banned
Did you try re-inserting any, after they failed?
Charter Member
Q seemed to work with large NP lists, so I presume R will too. You can change the name in settings.dsl to shorter to help.
Charter Member
Yup. Still the same failure - it seems to crash the tivo sometimes. My logs before are from reinsertion.
I haven't figured out if I could insert the TY file by itself though or run a repair util and then reinsert the TMF. Not sure if anything is wrong with these since they are scrambled - can't watch on mplayer or wmplayer.
Charter Member
Just like to say thanks rc3105, I last used this program about 8 months ago and could not get faster than a few k per second. With the latest version of the program I'm getting 900k-1300k per sec. Uploads are a little slower, about 400-500k but wow, what a difference.
I also noticed when uploading the file name is correct, where before It had alot of extra characters.
Whatever you did, great job.
Posting Permissions
