Beta: Start mfs_ftp transfers from the TiVo interface

[sanderton]

A patch for mfs_ftp which allows TiVo to TiVo transfers to be initiated from within the TiVo interface.

This patch allows a networked TiVo to display in its Now Playing list the contents of the Now Playing of a second TiVo on the network. If you play any of the remote items, then an mfs_ftp transfer is initiated. If your network and TiVo config is up to it, you can watch the show as it copies over.

The patch also allows viewing of the copying recording while it copies without the periodic interruptions of the bookmark juggle used by standard mfs_ftp.

CREDITS

This is a patch for mfs_ftp, and as such contains much code by, and relies heavily on the work of, Riley Cassell. Riley also gave me much valuable help and assistance in building this patch; many thanks to him.
VERSION HISTORY
1.0 Beta 11 - Fixed bug in item positioning, and suggestion filter under 3.x
1.0 Beta 10 - Fixed bug with multiple transfers
1.0 Beta 9 - Updated for 1.2.9Q
1.0 Beta 9 - Updated for 1.2.9Q
1.0 Beta 8 - first public release

SYSTEM REQUIREMENTS

mfs_ftp version 1.2.9Q running on both machines. Earlier versions of mfs_ftp will not work. An earlier vesionw hich works with 1.2.9P is in the archive, but is not supported.

To date this software has been tested on a UK stand-alone running 2.5.5 and on US machines running 3.0.

It will not work on 4.x as it uses SendKey.

The mwstate bug must be fixed for software below v 3, see here:

http://www.dealdatabase.com/forum/showthread.php?t=27366

INSTALLATION

1) If you are running v2.5.x, fix the mwstate bug
2) Check that you are running mfs_ftp v 1.2.9Q
3) Check that you can get an acceptable FXP transfer going from one TiVo to the other using SmartFTP or similar.
4) Shut down mfs_ftp
5) Unzip the enclosed on your PC
6) Edit the p1.tcl file to include the IP addresses of the local and remote TiVos, and any other settings you wish to change (see below) If you have other patches already installed as p1.tcl, rename this file so it loads last.
7) FTP the file p1.tcl to the same directory as mfs_ftp.tcl
8) Start mfs_ftp
9) If you want the remote items to be marked in Now Playing, use TivoWeb's Logos module to associate remotetivo-tw-s2-p2.png with channel 1000, REMOTE_TIVO (Will require a restart to be visible)
10) Repeat on second TiVo.

USE

When you go to Now Playing after installing SNP, you should see two items at the top of the list: Refresh Remote Now Playing Items and Delete Remote Now Playing Items

Select "Refresh Remote Now Playing Items" and press Play on the remote. An error message should appear fleetingly and you will returned to NP with two pings. A couple of seconds later you should be moved to TiVo Central while the remote TiVo's NP list is loaded. This can take several minutes, and when complete the TiVo will automatically return you to NP.

NP will now contain the entries of the remote TiVo as well as the local one. The remote entries are marked with a logo. You can select them and view the episode details as normal. If you Play them, then you will be bounced back to NP (on S2s you may have to go through the Delete/Don't Delete screen first), and after a few seconds an mfs_ftp transfer will be started and the new recording will appear next to the one you have selected. If your mfs_ftp is configured appropriately, you can start watching it.

Playing "Delete Remote Now Playing" will remove all the remote NP entries from the TiVo.

If you "Play" a remote recording and you get an error message that there was no video input, then mfs_ftp is not running on the local TiVo.

If you press "Play" and get bounced to NP but no transfer starts then either mfs_ftp was not running on the remote TiVo, or there was an error - check the logs.

OPTIONS

There are a few options you can set by editing the p1.tcl file.

You can filter out shows based on their broadcast channel, or their genre code. This is to keep the size of the NP to manageable proportions. You can also exclude suggestions.

You can select for the remote NP entries to be shown in their normal place in NP, or all grouped at the top or all at the bottom.

You can edit the channel number which SNP associates remote entries with, in case the default of 1000 is actually in use.

KNOWN ISSUES & OTHER STUFF

If you can't make an FXP transfer work reliably, or get a good enough speed to watch while it copies, then get that fixed first - this won't help. No insertion speed Q's in this thread please!

If you have too many entries in NP, then mfs_ftp in regular use can time out in displaying the contents of the various subdirectories (Buy a CacheCard!)

You cannot interrupt a transfer once it has started.

If you delete the menu items for some reason, then removing the file ../mfs_ftp/snp/snp.ini will cause them to be recreated.

There is no error messaging system at the TiVo display end, so if it doesn't work it's guesswork why.

[cojonesdetoro]

I still haven't gotten home to mess with it but this looks great.

If people start asking for feedback from the hack you could consider using osdconsole. I've been messing with it and it's pretty handy for hacks that use the Tivo interface. It gives you a 24x40 screen that understands ANSI codes. You can add it as a flag variable in the code.

Might be nice to write a little hack that spits the last 100 lines of port3105.log to the console... Maybe I'll do that and see how it works. I've been checking out how TCS does it and it looks pretty easy. You just have to use a key sequence that 'does nothing' at the live video screen. Something like:

clear-3-1-0-5-clear

might work.

newtxt2osd might be easier for this because osdconsole works as a running deamon that reads a fifo.

[eastwind]

I know, I know...How can I be a serious TiVoer if I only have 1 TiVo. But the obvious question (to me at least) is will this hack eventually be enabled to remote stream .tmf files stored remotely on a PC? I haven't tried to pick apart the code from this hack or from mfs_ftp, so I don't really know how difficult this task might be. But I thought I would ask, just in case.

Sounds like a great hack, and I'm sure you're right about Riley already having done most of this stuff because of some of the things he's already admitted to. :)

ew

[sanderton]

I know, I know...How can I be a serious TiVoer if I only have 1 TiVo. But the obvious question (to me at least) is will this hack eventually be enabled to remote stream .tmf files stored remotely on a PC? I haven't tried to pick apart the code from this hack or from mfs_ftp, so I don't really know how difficult this task might be. But I thought I would ask, just in case.


It leans heavily on mfs_ftp to provide the file handling intelligence and the info on the remote Now Showing, plus it messes with the file transfer a little to allow the seamless playback of a streaming show.

You could in theory sort it out, but it would need the adoption of a new file format for extracted TiVo video; something which has been discussed on alt.aorg, plus some kind of dedicated TiVo video server running on the PC.

[dialanothernumb]

I've been using this hack for a week or so now. It works well on my UK SA TiVos. The only element of the setup that's a bit hairy is the requirement (for most UK machines) to fix the mwstate bug, as it requires you to shut down tivoapp, edit and reload. The key for non-linux types it to remember the file permissions and backup your backups. The patch itself is neat and a clever way to make this hack useable for non-hackers.
Thanks Stuart.

[Meklos]

[QUOTE=sanderton]SYNCH NOW PLAYING

A patch for mfs_ftp which allows TiVo to TiVo transfers to be initiated from within the TiVo interface.

Excellent job! Going forward, do you think the code can support more than two Tivos? I have two today, but will have three soon... A unified onscreen interface for all of them is my eventual goal. Your software gets me one giant leap closer.

[edit] Also, how about periodic NP sync via a cron job or other timed function instead of / in addition to on-demand sync? Maybe a small hash of the NP list could do your "has it changed" check... Just thinking out loud...

[sanderton]

[QUOTE=sanderton]SYNCH NOW PLAYING

A patch for mfs_ftp which allows TiVo to TiVo transfers to be initiated from within the TiVo interface.

Excellent job! Going forward, do you think the code can support more than two Tivos? I have two today, but will have three soon... A unified onscreen interface for all of them is my eventual goal. Your software gets me one giant leap closer.

[edit] Also, how about periodic NP sync via a cron job or other timed function instead of / in addition to on-demand sync? Maybe a small hash of the NP list could do your "has it changed" check... Just thinking out loud...

More than two TiVos is possible in theory - although you start to have a seriously large Now Showing! As I only have two it would be hard for me to build.

I thought long and hard about the synching; originally I had it automatic, but it got very messy to code, and you don't want to be doing anything on the TiVo when its synching.

To trigger it from cron I'd need to make some changes, but it's a thought.

[cojonesdetoro]

Stuart,

I've been playing around with the hack but it's difficult. It seems to keep making my Tivos reboot. :eek: I don't see any errors in the logs. I've managed to export just one item from the remote 'now playing' list. I'll keep messing around to see where the problem lies. I run a few hacks so I'll disable those and see what happens.

HDR312/SA1/3.0/Cachecard w/256MB subbed 2x120GB drives
HDR312/SA1/3.0/turbonet unsubbed 2x120GB drives

[sanderton]

I had some problems with reboots in development, but haven't had one for months.

In my case the problems were to do with the get_mwstate proc in mfs_ftp, which crashed my Tivos with an Assertion Failiure every other time or so it was called. That's why I replaced the proc with a modified one which seems Ok.

In case it's related, you could try deleteing the get_mwstate proc in p1.tcl, which will revert it to using Riley's original.

Often a sudden failure seems to beat the log-writing to it; I found I could catch them by running mfs_ftp foregrounded, and the telnet session would capture the crash.

[C_Monkey]

I've installed on one Tivo so far, (SVR2000) patched tivoapp with the mwstate issue...

running 1.2.9E on Tivo in question, editted my p1.tcl file to reflect the correct IPs.. but get this error when attempting to start mfs_ftp.tcl.

bash-2.02# cd /var/mfs_ftp
bash-2.02# ./mfs_ftp.tcl
bash-2.02# invalid command name "finalize_rec"
while executing
"finalize_rec $newrecording"
(procedure "snp_createmenuitem" line 44)
invoked from within
"snp_createmenuitem "Delete Remote Now Playing items" "Play this to remove the remote Now Playing entries - this may take some time.""
(procedure "snp_init" line 49)
invoked from within
"snp_init"
(file "/var/mfs_ftp/p1.tcl" line 855)
invoked from within
"source $info(path)/$file.tcl "
(procedure "init_procs" line 5)
invoked from within
"init_procs "
(file "/var/mfs_ftp/mfs_ftp.tcl" line 1498)

[mini__me]

I've installed on one Tivo so far, (SVR2000) patched tivoapp with the mwstate issue...

running 1.2.9E on Tivo in question, editted my p1.tcl file to reflect the correct IPs.. but get this error when attempting to start mfs_ftp.tcl.



SYSTEM REQUIREMENTS

mfs_ftp version 1.2.9P running on both machines. Earlier versions of mfs_ftp will not work. ;)


I'm just about to give this a go, running on my UK tivo. Having read the mwstate fix I assume it doesn't matter if I change mwstate to mwstat1 rather that mstat1 as embeem says, as it's just a name for a file, right?

It seems alot easier to change the "e" to a "1" in hextreme than it would be to try and delete the "w" as well :)


Looking forward to giving this a try another great sanderton prog in the making :D

[C_Monkey]

;)


I'm just about to give this a go, running on my UK tivo. Having read the mwstate fix I assume it doesn't matter if I change mwstate to mwstat1 rather that mstat1 as embeem says, as it's just a name for a file, right?

It seems alot easier to change the "e" to a "1" in hextreme than it would be to try and delete the "w" as well :)


Looking forward to giving this a try another great sanderton prog in the making :D

hummm.. I was reading the README : It stated this...

INSTALLATION

1) If you are running v2.5.x, fix the mwstate bug
2) Check that you are running mfs_ftp v 1.2.8P or later

but you are correct his POST reflects "9P" not '8P' -- I was using the Install docs that came with the file not the DDB forum post :rolleyes:



<edit> That did it! sofar so-good!

[sanderton]

Sorry, typo in the readme. It requires the CURRENT version of mfs_ftp.

[sanderton]

;)


I'm just about to give this a go, running on my UK tivo. Having read the mwstate fix I assume it doesn't matter if I change mwstate to mwstat1 rather that mstat1 as embeem says, as it's just a name for a file, right?

It seems alot easier to change the "e" to a "1" in hextreme than it would be to try and delete the "w" as well :)


Yes, you're right. What you call that second entry doesn't matter as that file is not used, but changing the length of the file is not agood idea!

[mini__me]

As I suspected, cheers m8 :)

[C_Monkey]

sanderton;

have you thought of making a server-side-based "TiVoClone" as the REMOTE TiVo?

If there were a PC - Win32 or NIX version of MFS_FTP running on a network server, and you used that as an archive of TMF files -- As I often do, moving stuff over for storage. This way the Multi-Tivo (more than 2) household could just point all their TiVos to the server as the REMOTE TiVo.

I know that there is no MFS database server available, however, if MFS_FTP was just working with a file list, or perhaps a standard FTP server running on port 3105 may work? Sorry to state stupid possibilities - I don't know the under the covers workings of MFS_FTP - so perhaps this is all a "wet" dream!

But I could imagine having a 500gig+ or even a tera-byte or so, That would be really something, for all my TiVos to select from!

[sanderton]

A PC "version" of mfs_ftp to connect to this hack is perfectly possible in theory. To make it easier, it would need a modification to the .tmf format, but you could do it without that if you could live without the seamless viewing of a streaming recording.

Basically, you'd just put something together which looked to mfs_ftp at the TiVo end as though it were another copy of mfs_ftp. The parts of mfs_ftp where it reads the TiVo database would be replaced with reading the XML from the stored .tmf file. I presume there are PC ultils for reading the parts of a tarball.

How many people might be interested in that?

[C_Monkey]

A PC "version" of mfs_ftp to connect to this hack is perfectly possible in theory. To make it easier, it would need a modification to the .tmf format, but you could do it without that if you could live without the seamless viewing of a streaming recording.

Basically, you'd just put something together which looked to mfs_ftp at the TiVo end as though it were another copy of mfs_ftp. The parts of mfs_ftp where it reads the TiVo database would be replaced with reading the XML from the stored .tmf file. I presume there are PC ultils for reading the parts of a tarball.

How many people might be interested in that?

well ME for sure, I would even dabble in it my-ownself but never touch .tcl before. I use to play around with perl a few years back in a former life - before javascript, jars & servlets took over the web development side of things. I now work more in production automation & PLCs. Lost the edge on script-like programming. I'm a ladder-logic guy now. Perhaps I'll blow the dust off an ole' hard-drive and take a look see.

I'm guessing but I think Reily would be able to knock this off in his sleep? :p

[sanderton]

Riley's probably built it already. :)

Actually, it should be pretty simple, as PC server built solely to connect to mfs_ftp on a TiVo would not have to deal with general client connections or insertion, so you could skip most of the logic.

[feldy]

How many people might be interested in that?

I definitely would be interested in a PC version.
Only one of my Tivo's is available for playing around with, but I also keep a collection of .tmf's on a file server for storage. With a PC mfs_ftp and a simple script to extract all the video let's say 3 days old, we could have a automatic synched external file server.

[C_Monkey]

I definitely would be interested in a PC version.
Only one of my Tivo's is available for playing around with, but I also keep a collection of .tmf's on a file server for storage. With a PC mfs_ftp and a simple script to extract all the video let's say 3 days old, we could have a automatic synched external file server.

EXACTLY! shoot -- you could probably get by with a 40gig drive in the TiVo!

I'm thinking the only issue would be multiple xfer requests down to the TiVos. Or would that be handled as simply as spawning another connection?

[C_Monkey]

With a PC mfs_ftp and a simple script to extract all the video let's say 3 days old, we could have a automatic synched external file server.

yeah; if the script were 'smart' enough, you could just have it get triggered from when the recording was complete. Extracting and transfering every recording to the server.

So on the TiVo side you could just let your recordings expire as "space available" settings.

[sanderton]

Probably just have multiple instances of the server on 3106, 3107, etc. One for each TiVo.

[C_Monkey]

Probably just have multiple instances of the server on 3106, 3107, etc. One for each TiVo.


to minimize development, couldn't you just install "activestate's tcl" on say a win2k box and use the majority of the mfs_ftp.tcl source?

[tivomaster]

A PC "version" of mfs_ftp to connect to this hack is perfectly possible in theory. To make it easier, it would need a modification to the .tmf format, but you could do it without that if you could live without the seamless viewing of a streaming recording.

Basically, you'd just put something together which looked to mfs_ftp at the TiVo end as though it were another copy of mfs_ftp. The parts of mfs_ftp where it reads the TiVo database would be replaced with reading the XML from the stored .tmf file. I presume there are PC ultils for reading the parts of a tarball.

How many people might be interested in that?

In my opinion this would be GREAT....

[sanderton]

to minimize development, couldn't you just install "activestate's tcl" on say a win2k box and use the majority of the mfs_ftp.tcl source?

Yes, that's exactly how I'd do it. Then wrap it up with FreeWrap or similar to make a Windows .exe. All with the author's permission of course!

[rc3105]

to minimize development, couldn't you just install "activestate's tcl" on say a win2k box and use the majority of the mfs_ftp.tcl source?
that's exactly what I did with the 2TB servers, (mfs_ftp_pc) most of a year ago ;)

the rewrite (in progress) will run the same code on pc/mac/tivo/xbox, auto-detect the platform & support connected TB changers (now that I can plug them into the s2's easily)

if this script could negotiate a ftp password challenge and retrieve header chunks from server tyfiles via REST cmds (restart allows for random access within a file on the server - see Rung's chunkedit.tcl patch for how that works) a new format & mfs_ftp_pc would be unnecesary, any old ftp server would work

[sanderton]

Figured you'd be there already! :)

You'd still need some way to populate the To Do List of the recieving TiVo with the contents of the files held on the server. You could parse the filename for the very basics, I guess. I was thinking of just copying the XML out of the tmf and storing it in a folder, which could then be accessed in the same way as this patch does it now.

Any ETA on the cross platform mfs_ftp? Or shoudl I have a go anyway?

Here's a feature request for mfs_ftp - enable the login name to call a defined script, so you can patch without having to wholesale replace entire procs, eg if you login as "patchfile", mfs_ftp would source patchfile.tcl

[rc3105]

the xml dir was added so a client util could populate nowplaying easily

the txt dir was added to facilitate fxp transfers by inserting a txt - easy to attach to e-mail ;) - or can be used to populate nowplaying

resume was implemented so a client can grab xml or header chunks with REST cmds and not care whether the server was mfs_ftp or standard ftp


don't hold your breath on the rewrite, lots going on & bills to pay :eek:

[sanderton]

I think I need to look at this REST function. If I can use that to extract the XML and the header chunks from a file on a bog standard FTP server...

[cojonesdetoro]

I had some problems with reboots in development, but haven't had one for months.

In my case the problems were to do with the get_mwstate proc in mfs_ftp, which crashed my Tivos with an Assertion Failiure every other time or so it was called. That's why I replaced the proc with a modified one which seems Ok.

In case it's related, you could try deleteing the get_mwstate proc in p1.tcl, which will revert it to using Riley's original.

Often a sudden failure seems to beat the log-writing to it; I found I could catch them by running mfs_ftp foregrounded, and the telnet session would capture the crash.


Sho'nuff.. I caught this error on the console from which mfs_ftp was run

Tivo1# Tmk Assertion Failure:
BlockFailure, line 2073 ()
Tmk Fatal Error: Thread tivosh <16274> died due to signal -2
1aa90ac 1aa79c8 1aa2290 1cda374 1ce64ec 1d37004 1d53e64 1d53c08 1d3977c 1d48968 1d363d8 1d5b1


However, this was AFTER I commented out the get_mwstate proc in the p1 script. I will see if I can manifest the error with it left in.

BTW: I am running one Tivo as unsubbed.

EDIT found this in the log after the Tivo rebooted:


Dumping mempool to /tmp/BlockFailure.16274

To view the blocks, run:
$TIVO_ROOT/devbin/poolview.tcl <app-with-symbols> /tmp/BlockFailure.16274

In the UI that comes up, find your leaked block by address (see above)
This will help you identify the type and ownership of the blocks.

Common causes for leaks:
- Circular refs. Redefine ownership without circular dependency
- Explicit Malloc or GetChunk without Free or ReturnChunk
- Use of non-TmkCore objects, without using delete operator (TmkLock for example)

[cojonesdetoro]

I put your proc back in but now I get this (Lot's more info entries above these):

.
.
info(1142666,rec_filename): {Discoveries This Week}{2004-02-13}{}{08.00 PM Fri Feb 13, 2004}{}
info(1147330,State): 4
info(1134678,sizes): 411041792
info(648047,State): 4
info(1147297,StreamFileSize): 411041792
info(1154995,sizes): 536870912 180355072 5242880
Dumping mempool to /tmp/BlockFailure.820

To view the blocks, run:
$TIVO_ROOT/devbin/poolview.tcl <app-with-symbols> /tmp/BlockFailure.820

In the UI that comes up, find your leaked block by address (see above)
This will help you identify the type and ownership of the blocks.

Common causes for leaks:
- Circular refs. Redefine ownership without circular dependency
- Explicit Malloc or GetChunk without Free or ReturnChunk
- Use of non-TmkCore objects, without using delete operator (TmkLock for example)

[sanderton]

Those are the standard unhelpful full-on crash messages. :(

You are not using the very latest beta (unless I forgot to take the bgerror proc out of p1 in B7 - I certainly meant to!).

It looks like the code crashed, gave a normal TCL error, and then that took the Tivo out. We need to figure out which line of code wasa being executed before the crash.

[sanderton]

Ok, I've reinstated some of the code I used in testing which cured the reboots on my Tivos. I'd though that it was no longer necessary as I chnaged some other stuff, but seems I was wrong.

Beta 8 is now in the first post.

What seems to happen on certain machines is thet that take an inordinate amount of time to close the mwstate file, and the script reading it clashes with MyWorld writing it, result ka-boom. (This is a guess, but it fits the facts ma'am.)

I've put back the code which only reads the first 1k of the file (as the info we need is right at the top); this seems to solve the issue.

[cojonesdetoro]

Sounds good. I will try tonight and report my results. Thanks for the quick response.

[rbiro]

If it doesn't work right out of the box, save yourself some time and anguish and check the FULL IP addresses you enter in p1.tcl

These are configured for 192.168.0.XXX.
Most Linksys routers are set for 192.168.1.XXX.

I was so eager to get this up and running, that I just changed the last 8-bit number on both sides, rebooted my tivo, and... NOTHING!
I re-checked to make sure that I had .20 for my local tivo and .25 for my remotetivo and not reversed. But did I pay attention to the .0 to their left??? NOOO!!!

I ran DOS2UNIX on the files because maybe that was the problem. But did I pay attention to the .0 to their left??? NOOO!!!

I checked everyday for an update and when that came I installed it. But did I pay attention to the .0 to their left??? NOOO!!!

Finally, I saw the light!!!! I changed the zeros to ones and IT WORKS.
Shocking how paying attention to details can make things work!

[cojonesdetoro]

Ok, I've reinstated some of the code I used in testing which cured the reboots on my Tivos.

I tried b8 and now it does not reboot my Tivo but it also never gets the now showing list from the remote Tivo. I select the 'refresh' recording, it bongs me back to now playing, then to tivo central then back to now playing but the remote recordings never show up. I also see nothing in the logs.

[sanderton]

If it's taking you back to TiVo Central then the the mwstate code has done its stuff correctly (it's that which figures out what you tried to play).

Most likely cause of nothing else happening is that the the patch and/or mfs_ftp isn't running on the remote TiVo.

If mfs_ftp is running, try telnetting to the remote TiVo on 5103; you should get a load of XML straeming at you.

[Generiq]

I would love to try this, but each time I try and transfer the file, I get

503 Only ASCII and binary modes are supported

I get this if I try to transfer in auto or ASCII mode. If I try in binary, it works, but the file has the problems you'd expect when I check it out in joe. Any tips?

Thanks!

BTW - I have your conflict resolve module running... very cool!

[cojonesdetoro]

If it's taking you back to TiVo Central then the the mwstate code has done its stuff correctly (it's that which figures out what you tried to play).

Most likely cause of nothing else happening is that the the patch and/or mfs_ftp isn't running on the remote TiVo.

If mfs_ftp is running, try telnetting to the remote TiVo on 5103; you should get a load of XML straeming at you.

I made sure that mfs_ftp is running onboth and the XML spits out at port 5013 as well. I do run a dos2unix command against the script because I notice that it unzips with a bunch of CR-LFs. I will try it now without running dos2unix against it.

[cojonesdetoro]

I made sure that mfs_ftp is running onboth and the XML spits out at port 5013 as well. I do run a dos2unix command against the script because I notice that it unzips with a bunch of CR-LFs. I will try it now without running dos2unix against it.

No dice. I'm not sure why I am not getting the remote now playing list.

Has anyone else got this working between two SA1/3.0 machines? It would help to know if this was unique to my rig or a SA1/3.0-related issue.

[rbiro]

Has anyone else got this working between two SA1/3.0 machines? It would help to know if this was unique to my rig or a SA1/3.0-related issue.

Yeah. I have a Sony SVR-2000 and a Phillips HRD-212.
Take a close look at the IP addresses and make sure that your subnet setting is correct. The defaults are for .0.XXX networks (dlink defaults) .1.XXX are defaults for Linksys'es.

[sanderton]

I would love to try this, but each time I try and transfer the file, I get

503 Only ASCII and binary modes are supported

I get this if I try to transfer in auto or ASCII mode. If I try in binary, it works, but the file has the problems you'd expect when I check it out in joe. Any tips?

Thanks!

BTW - I have your conflict resolve module running... very cool!

Transfer in binary. Don't worry about the ^Ms etc - that only effects directly executables as it screws the #/tvbin/tivosh at the beginning of the file; TCL which is run from another bit of TCL like this patch or TivoWeb modules don't mind DOS line ends.

[sanderton]

No dice. I'm not sure why I am not getting the remote now playing list.

Has anyone else got this working between two SA1/3.0 machines? It would help to know if this was unique to my rig or a SA1/3.0-related issue.

You get nothing from a telnet from your pc to the remote TiVo on 5013?

Then it is not installed properly on the remote TiVo.

[cojonesdetoro]

You get nothing from a telnet from your pc to the remote TiVo on 5013?
Then it is not installed properly on the remote TiVo.

No, I apologize for not making it clear. I definitely get the entire xml streamed at me when I telnet to port 5013 on both units. (see below).

I'm still curious to know if anyone has it working on 3.0/SA1. It would help me know where to look for the problem.


$ telnet tivo 5013
Trying 192.168.33.219...
Connected to tivo (192.168.33.219).
Escape character is '^]'.
<Data Entry>
<Filename>{Refresh Remote Now Playing items}{2032-02-16}{}{12.52 AM Mon Feb 16, 2032}{REMOTE_TIVO}{1177250}</Filename>
<?xml version="1.1" tivoversion="3.0-01-1-000"?>
<Object type="Recording" id="_top">
<BitRate>0</BitRate>
<SubObject type="RecordingPart" id="Part">

.
.
.
<StreamFileSize>622592</StreamFileSize>
<SubPriority>268501408</SubPriority>
<UsedBy>1</UsedBy>
</Object>

</Data Entry>
::DONE::
Connection closed by foreign host.


EDIT:
That Smiley face above was added by the board software but the line does appear like this without spaces:

: : D O N E : :

[sanderton]

OK, in that case, run mfs_ftp in the foreground:

/var/hack/mfs_ftp/mfs_ftp.tcl 3105 foreground

to make it easier to see what's happening.

Play the Refresh NP item, and dash back to your PC.

You should see:

a) all your NP items scrolling through as SNP checks them to see if they are remote entries to9 be deleted
b) a pause while it gets the xml (you can see if that bit works by the presence of the xml.txt file in ../snp/)
c) each xml entry scrolling past as SNP processes it.

Takes about 3 mins.

If instead you get the mfs_ftp core dump, then please post the error message and the last few lines of the telnet session.

There are definitely SA1/3.0 users who have got it going.

I just noticed thie "unsubbed " in your sig. I'll have a think about whether any of the code might break because of that.

[rbiro]

I'm still curious to know if anyone has it working on 3.0/SA1. It would help me know where to look for the problem.



Sorry, If I was'nt fully explicit.

I have no problem with my Series 1 stand alone units.
Sony SVR-2000 and Phillips HDR-212. Both run 3.0 software.

[luv2tivo]

I am having similar problems, Running mfs_ftp in foreground as suggested (repeated error messages removed to make 5000 character limit to post):

/var/mfs_ftp# ./mfs_ftp.tcl 3105 foreground
TmkLogger: <134>Feb 23 05:52:33 tcl[240]: Tcl created pool of 1458176 bytes
05:52:34:AM - sourcing settings
05:52:34:AM - Running SNP patch 1.0b8
09:52:34:PM - sourcing p1
09:52:41:PM - updating cached recording info
.................................................................................................... ....................
.................................................................................................... ....................
........

catch close lastsock val "can't read "info(lastsock)": no such element in array"
TmkLogger: <134>Feb 23 05:53:45 tivosh[240]: Active Upgrade Lock Conflict on fsid 2909
retrying after errTmActiveLockConflict ...
TmkLogger: <134>Feb 23 05:53:48 tivosh[240]: Active Upgrade Lock Conflict on fsid 15921
retrying after errTmActiveLockConflict ...
retrying after errFsLockConflict ...

retrying after errTmActiveLockConflict ...
retrying after errFsLockConflict ... (REPEATED 3 MORE TIMES)

TmkLogger: <134>Feb 23 05:54:18 tivosh[240]: Active Upgrade Lock Conflict on fsid 15921
retrying after errTmActiveLockConflict ...
retrying after errFsLockConflict ... (2X)

retrying after errTmActiveLockConflict ...
retrying after errFsLockConflict ...
TmkLogger: <134>Feb 23 05:54:56 tivosh[240]: Active Upgrade Lock Conflict on fsid 2909
retrying after errTmActiveLockConflict ...
TmkLogger: <134>Feb 23 05:55:05 tivosh[240]: Active Upgrade Lock Conflict on fsid 15921
retrying after errTmActiveLockConflict ...
TmkLogger: <134>Feb 23 05:55:08 tivosh[240]: Active Upgrade Lock Conflict on fsid 15923
retrying after errTmActiveLockConflict ...
TmkLogger: <134>Feb 23 05:55:14 tivosh[240]: Active Upgrade Lock Conflict on fsid 15921
*** PREVIOUS LINE REPEATED 5 TIMES ***
...
retrying after errFsLockConflict ...

retrying after errTmActiveLockConflict ...
TmkLogger: <134>Feb 23 05:57:41 mempool[240]: tivosh block: 1177kB/1426kB chunk: 0kB/0kB unused: 0kB search: 0 (size=
1462272)
TmkLogger: <134>Feb 23 05:57:41 tivosh[240]: Current (total pool size = 1462272, unused = 32):
TmkLogger: <134>Feb 23 05:57:41 tivosh[240]: tmk 2364/ 0 bytes ( 28 blocks/ 0 chunks)
TmkLogger: <134>Feb 23 05:57:41 tivosh[240]: database 48/ 0 bytes ( 2 blocks/ 0 chunks)
TmkLogger: <134>Feb 23 05:57:41 tivosh[240]: mom 204/ 0 bytes ( 3 blocks/ 0 chunks)
TmkLogger: <134>Feb 23 05:57:41 tivosh[240]: tcl 1202676/ 0 bytes (31710 blocks/ 0 chunks)
TmkLogger: <134>Feb 23 05:57:41 tivosh[240]: executive 168/ 0 bytes ( 1 blocks/ 0 chunks)
TmkLogger: <134>Feb 23 05:57:41 tivosh[240]: tmkevent 32/ 0 bytes ( 1 blocks/ 0 chunks)
TmkLogger: <134>Feb 23 05:57:41 tivosh[240]: TOTAL 1205492/ 0 bytes (31745 blocks/ 0 chunks)
TmkLogger: <134>Feb 23 05:57:41 tivosh[240]: pool is out of space, requesting 24 bytes
TmkLogger: <134>Feb 23 05:57:41 tivosh[240]: total pool size: 1462272 bytes
TmkLogger: <134>Feb 23 05:57:41 tivosh[240]: BT: 1cfcc28 1d48508 1d68740 1d686e0 1d63cfc 1d59e6c 1d478dc 1d6c688

*** 12 LINES ABOVE REPEATED AGAIN ***

Dumping mempool to /tmp/BlockFailure.240


TmkLogger: <129>Feb 23 05:58:04 TmkAssertionFailure[240]: (BlockFailure, line 2150 ())
Tmk Assertion Failure:
BlockFailure, line 2150 ()
TmkLogger: <129>Feb 23 05:58:04 tivosh[240]: Tmk Fatal Error: Thread tivosh <240> died due to signal -2
Tmk Fatal Error: Thread tivosh <240> died due to signal -2
1ad0644 1acef60 1ac9264 1cf0e50 1cfcc28 1d48508 1d68740 1d686e0 1d63cfc 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c688
1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d48464 1804670 18040ec 1bc8fec 1bc92fc 19c1740 1d4709c
1d59e6c 1d478dc 1d64974 1d65a80 1cfcbc8 1cfc910 1800134
TmkLogger: <129>Feb 23 05:58:04 tivosh[240]: Tmk Thread Backtrac
e: 1ad0644 1acef60 1ac9264 1cf0e50 1cfcc28 1d48508 1d68740 1d686e0 1d63cfc 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c6
88 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d48464 1804670 18040ec 1bc8fec 1bc92fc 19c1740 1d470
9c 1d59e6c 1d478dc 1d64974 1d65a80 1cfcbc8 1cfc910 1800134
TmkLogger: <129>Feb 23 05:58:04 tivosh[240]: Tmk Fatal Error: Thread died due to signal -2
TmkLogger: <129>Feb 23 05:58:04 tivosh[240]: Invoking rule 834: rebooting system
TmkLogger: <134>Feb 23 05:58:09 TmkReboot[240]: Programatic box reboot initiated

Any help would be appreciated...

TIA,

luv2tivo

[sanderton]

Don't worry about all the errFsLockConflicts, they come with ther territory, as the hack hammers the database inserting the Now Showing entries.

The hack has run out of memory; I've not ever seen that. The memory pool is shared by all TCL apps; are you running lots of other hacks as well?

It's possible to set the memory allocation to a higher value withe poolsize command; I'm reluctant to do it as a default though.

I'm away from my TiVo right now, so I'll post the exact memory allocation command later - unless someone else can remember it?

[cojonesdetoro]

The hack has run out of memory

I have 32MB on-board on one of my Tivos. I still haven't had a chance to run through the foreground test (My 3 year old keeps me busier than my Tivo). I can say that I have pretty large 'now playing' lists. I have dual 120GB drives in both TIvos. Do you keep the entire list in memory? maybe it would be better to read to/from a temp file?

[sanderton]

I have 32MB on-board on one of my Tivos. I still haven't had a chance to run through the foreground test (My 3 year old keeps me busier than my Tivo). I can say that I have pretty large 'now playing' lists. I have dual 120GB drives in both TIvos. Do you keep the entire list in memory? maybe it would be better to read to/from a temp file?

A highly abbreviated Now Showing is held in RAM in order to check for duplicates when loading the romote list - just the channel ID and the start time. This is way less that TivoWeb etc use all the time. The incoming Now Showing entries are processed one at a time from a file on the disk.

I've not seen any memory problems at all - this report is a first.

[luv2tivo]

Sanderton,

Thanks for the insight. Perhaps there is something to the long now playing list that cojonesdetoro brought up combined with other hacks running to consume the memory.

I do have 2x160GB drives on the SAT-T60 and around 250 items in Now Showing (like to keep alot around :). It's running the 3.1 version of xtreme with the standard stuff- noscramble, turbonet, xPlusz... but I got the impression from your post that you believe that your method for holding the local now playing is efficient, would a really large list of now playing cause it?

Other area to look at: I did go out and add alot of the optional tivoweb modules (folders, etc can't remember them all as I can't access it from work).

Would you expect that removing some of the tivoweb tcl modules help (or do they only get loaded when invoked from the tivoweb gui)? If so, I will try renaming these files so they don't get loaded.

Finally, where might I find the syntax for the poolsize command and in which file is set? Sounds like that would be the second thing to try.

TIA,

Luv2tivo

[mini__me]

Hey great little integration :)

One thing though, I installed it quickly just to test it and now want to remove the channel 1000. Will this vanish and be replaced with the channel of my choice when I re-instate the p1.tcl to the tivo. Or will I now have to delete channel 1000? If so is there I quick way to do this or should I start searching now :)

ta

mini

[sanderton]

A little util to strip out Channel 1000's is on my TDL!

[mini__me]

I'll get searching then ;)

Will report back if I find out.

[NutKase]

SYNCH NOW PLAYING

A patch for mfs_ftp which allows TiVo to TiVo transfers to be initiated from within the TiVo interface.
It will not work on 4.x as it uses SendKey.

Another great hack that won't work on my machines.

I sure do wish someone with more brains than me would work on the sendkey issue.


NutKase

[SteveJenkins]

I found I could catch them by running mfs_ftp foregrounded, and the telnet session would capture the crash.

Great app - I'm still messing with it to get it working right, but mfs_ftp keeps shutting down on me. The log shows nothing, so I'm wondering how you were able to force it to run foregrounded to see the crashes in the telnet window. Even running just ./mfs_ftp from the prompt it bg's itself.

Thanks,

Steve

[SteveJenkins]

As I've played with this a bit more, I decided to slightly modify the png file that came with the package by changing the lightening bolt into four arrows.

If you've already loaded yours into your TiVo, just use the TiVoWeb module to re-import (it will overwrite), then restart your TiVo.

sanderton: feel free to use this graphic in your distribution if you like it. I mean no disrespect by offering it - I just preferred the arrows to the lightening.

[DocTauri]

I too was having some issues in that, I'd select to refresh the remote list, get the boing, menu jump, and nothing would retrieve. Come to find out (not sure if it's me or in general), but it simply won't retrieve the list (or a remote program) if the list is sorted alphabetically. If I set it back to the standard date sort, it works. Resort by alpha, and it stops working again.

Anyone else seen this?

Doc

[SteveJenkins]

Mine is sorted by record date, and it still isn't retrieving any new items for the NP list. I get the bong, the quick error, then it returns to NP, then to TiVo Central, then eventually to NP (as it should). But no remote shows appear in the NP list.

[sanderton]

Great app - I'm still messing with it to get it working right, but mfs_ftp keeps shutting down on me. The log shows nothing, so I'm wondering how you were able to force it to run foregrounded to see the crashes in the telnet window. Even running just ./mfs_ftp from the prompt it bg's itself.

Thanks,

Steve

/var/mfs_ftp/mfs_ftp.tcl 3105 foreground

Closing the telenet session before shutting down mfs_ftp will lock it up requiring a reboot, so careful!

[sanderton]

I too was having some issues in that, I'd select to refresh the remote list, get the boing, menu jump, and nothing would retrieve. Come to find out (not sure if it's me or in general), but it simply won't retrieve the list (or a remote program) if the list is sorted alphabetically. If I set it back to the standard date sort, it works. Resort by alpha, and it stops working again.

Anyone else seen this?

Doc

I have never seen what an alpha sorted NP looks like, so it was never tested doing that.

What does a sorted list look like in MFS - is it a separate subdir of /Recording or a new tag in the Recording object?

[sanderton]

Mine is sorted by record date, and it still isn't retrieving any new items for the NP list. I get the bong, the quick error, then it returns to NP, then to TiVo Central, then eventually to NP (as it should). But no remote shows appear in the NP list.

What is in port3105.log? Could you post it? Is there a file "xml.txt" in /var/mfs_ftp/snp/ ? If so could you post a snippet?

[sanderton]

As I've played with this a bit more, I decided to slightly modify the png file that came with the package by changing the lightening bolt into four arrows.

If you've already loaded yours into your TiVo, just use the TiVoWeb module to re-import (it will overwrite), then restart your TiVo.

sanderton: feel free to use this graphic in your distribution if you like it. I mean no disrespect by offering it - I just preferred the arrows to the lightening.

Thanks. Graphics are not my strong point. :)

[mrblack51]

I have never seen what an alpha sorted NP looks like, so it was never tested doing that.

What does a sorted list look like in MFS - is it a separate subdir of /Recording or a new tag in the Recording object?

3.x has 3 different sections:
/Recording/NowShowingByClassic
/Recording/NowShowingByExpiration
/Recording/NowShowingByTitle

[sanderton]

Steve, could you have a look in /Recoding/Active in TiVoWeb and see if they are there?

The NS entry creation code is basically the same as in mfs_ftp; do inserted recordings appear OK?

The only other think I can think of is the

set remotepos normal

line in the init procedure; I didn't do a lot of testing of the other two settings - is yours still on normal?

[JackBlack]

As I've played with this a bit more, I decided to slightly modify the png file that came with the package by changing the lightening bolt into four arrows.

If you've already loaded yours into your TiVo, just use the TiVoWeb module to re-import (it will overwrite), then restart your TiVo.

sanderton: feel free to use this graphic in your distribution if you like it. I mean no disrespect by offering it - I just preferred the arrows to the lightening.
When I try to import either of the logos with TivoWeb I get "Invalid file format" error. Any ideas? I got rest of it working. Thanks.

[sanderton]

Are you using TiVoWeb plus? There was a bug in its logos module.

[JackBlack]

Are you using TiVoWeb plus? There was a bug in its logos module.
Yes, it is 1.9.4.2 per the tar/gz file. I' see there is a newer version. I will try that. Thanks

[JackBlack]

Yep, that was it.
http://www.dealdatabase.com/forum/showthread.php?p=148456&highlight=logo#post148456

[SteveJenkins]

What is in port3105.log? Could you post it? Is there a file "xml.txt" in /var/mfs_ftp/snp/ ? If so could you post a snippet?

I've attached source and destination logs. TiVo1 is the destination that I am trying to download TO, and TiVo2 is the source I am trying to download FROM.

My files are in /var/hack/mfs_ftp/ (not /var/mfs_ftp/) and there is nothing in /var/hack/mfs_ftp/snp/ except for the default snp.ini file.

If you need anything other files or want me to test anything out, just say the word. I love messing with my TiVos, especially if it can help resolve bugs!

[sanderton]

I've attached source and destination logs. TiVo1 is the destination that I am trying to download TO, and TiVo2 is the source I am trying to download FROM.

My files are in /var/hack/mfs_ftp/ (not /var/mfs_ftp/) and there is nothing in /var/hack/mfs_ftp/snp/ except for the default snp.ini file.

If you need anything other files or want me to test anything out, just say the word. I love messing with my TiVos, especially if it can help resolve bugs!

It's not making the connection to Tivo2 to get the Now Showing data. TiVo 2 appears to be listening and Tivo1 is trying to open a socket, so check that you have the correct IP address set in p1.tcl on Tivo 1.

[fredisdead]

I have the same problem as previously reported partial console log attached.

TmkLogger: <134>Mar 2 19:39:45 tivosh[234]: Active Upgrade Lock Conflict on fsid 61935
retrying after errTmActiveLockConflict ...
TmkLogger: <134>Mar 2 19:40:59 tivosh[234]: Active Upgrade Lock Conflict on fsid 422492
retrying after errTmActiveLockConflict ...
TmkLogger: <134>Mar 2 19:41:06 mempool[234]: tivosh block: 1176kB/1426kB chunk: 0kB/0k
B unused: 0kB search: 1 (size=1462272)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: Current (total pool size = 1462272, unused
= 28):
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: tmk 2364/ 0 bytes ( 28 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: database 48/ 0 bytes ( 2 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: mom 204/ 0 bytes ( 3 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: tcl 1202168/ 0 bytes (31776 b
locks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: executive 168/ 0 bytes ( 1 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: tmkevent 32/ 0 bytes ( 1 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: TOTAL 1204984/ 0 bytes (31811 b
locks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: pool is out of space, requesting 24 bytes
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: total pool size: 1462272 bytes
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: BT: 1cfcc28 1d48508 1d68740 1d686e0 1d
63cfc 1d59e6c 1d478dc 1d6c688
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: Current (total pool size = 1462272, unused
= 28):
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: tmk 2364/ 0 bytes ( 28 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: database 48/ 0 bytes ( 2 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: mom 204/ 0 bytes ( 3 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: tcl 1202168/ 0 bytes (31776 b
locks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: executive 168/ 0 bytes ( 1 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: tmkevent 32/ 0 bytes ( 1 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:41:06 tivosh[234]: TOTAL 1204984/ 0 bytes (31811 b
locks/ 0 chunks)
Dumping mempool to /tmp/BlockFailure.234

To view the blocks, run:
$TIVO_ROOT/devbin/poolview.tcl <app-with-symbols> /tmp/BlockFailure.234

In the UI that comes up, find your leaked block by address (see above)
This will help you identify the type and ownership of the blocks.

Common causes for leaks:
- Circular refs. Redefine ownership without circular dependency
- Explicit Malloc or GetChunk without Free or ReturnChunk
- Use of non-TmkCore objects, without using delete operator (TmkLock for example)

TmkLogger: <129>Mar 2 19:41:28 TmkAssertionFailure[234]: (BlockFailure, line 2150 ())
Tmk Assertion Failure:
BlockFailure, line 2150 ()
TmkLogger: <129>Mar 2 19:41:28 tivosh[234]: Tmk Fatal Error: Thread tivosh <234> died d
ue to signal -2
Tmk Fatal Error: Thread tivosh <234> died due to signal -2
1ad0644 1acef60 1ac9264 1cf0e50 1cfcc28 1d48508 1d68740 1d686e0 1d63cfc 1d59e6c 1d478dc
1d6c688 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c688 1d59e6c
1d478dc 1d48464 1804670 18040ec 1bc8fec 1bc92fc 19c1740 1d4709c 1d59e6c 1d478dc 1d64974
1d65a80 1cfcbc8 1cfc910 1800134 TmkLogger: <129>Mar 2 19:41:28 tivosh[234]: Tmk Thread
Backtrace: 1ad0644 1acef60 1ac9264 1cf0e50 1cfcc28 1d48508 1d68740 1d686e0 1d63cfc 1d59e
6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c6
88 1d59e6c 1d478dc 1d48464 1804670 18040ec 1bc8fec 1bc92fc 19c1740 1d4709c 1d59e6c 1d478
dc 1d64974 1d65a80 1cfcbc8 1cfc910 1800134


the remote tivo has a very large now playing...

how can one uninstall the patch and clear out the dummy now playing entries?

fred

[fredisdead]

this is the log on the 'other side' same symptom while doing 'refresh' this is the box with the large np list the other side has only 20 or so entries in np.

so.. is there ahard limit on the np size? btw these are dtivo s1 boxes (see below) with stable mfs_ftp transfers....

/var/mfs_ftp# ./mfs_ftp.tcl 3105 foreground
TmkLogger: <134>Mar 2 19:54:53 tcl[214]: Tcl created pool of 1458176 bytes
07:54:55:PM - sourcing settings
07:54:55:PM - Running SNP patch 1.0b8
11:54:55:AM - sourcing p1
11:55:10:AM - updating cached recording info

***dots cut for size***

catch close lastsock val "can't read "info(lastsock)": no such element in array"
TmkLogger: <134>Mar 2 19:57:36 tivosh[214]: Active Upgrade Lock Conflict on fsid 125091
2
retrying after errTmActiveLockConflict ...
TmkLogger: <134>Mar 2 19:57:39 tivosh[214]: Active Upgrade Lock Conflict on fsid 125062
0
retrying after errTmActiveLockConflict ...
TmkLogger: <134>Mar 2 19:57:45 tivosh[214]: Active Upgrade Lock Conflict on fsid 125091
2
retrying after errTmActiveLockConflict ...
TmkLogger: <134>Mar 2 19:57:47 tivosh[214]: Active Upgrade Lock Conflict on fsid 166264
1
retrying after errTmActiveLockConflict ...
TmkLogger: <134>Mar 2 19:57:52 tivosh[214]: Active Upgrade Lock Conflict on fsid 125091
2
retrying after errTmActiveLockConflict ...
TmkLogger: <134>Mar 2 19:59:48 mempool[214]: tivosh block: 1174kB/1426kB chunk: 0kB/0k
B unused: 0kB search: 0 (size=1462272)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: Current (total pool size = 1462272, unused
= 24):
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: tmk 2364/ 0 bytes ( 28 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: database 52/ 0 bytes ( 2 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: mom 204/ 0 bytes ( 3 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: tcl 1199608/ 0 bytes (32084 b
locks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: executive 168/ 0 bytes ( 1 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: tmkevent 32/ 0 bytes ( 1 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: TOTAL 1202428/ 0 bytes (32119 b
locks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: pool is out of space, requesting 24 bytes
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: total pool size: 1462272 bytes
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: BT: 1cfcc28 1d48508 1d68740 1d686e0 1d
63cfc 1d59e6c 1d478dc 1d6c688
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: Current (total pool size = 1462272, unused
= 24):
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: tmk 2364/ 0 bytes ( 28 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: database 52/ 0 bytes ( 2 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: mom 204/ 0 bytes ( 3 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: tcl 1199608/ 0 bytes (32084 b
locks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: executive 168/ 0 bytes ( 1 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: tmkevent 32/ 0 bytes ( 1 bl
ocks/ 0 chunks)
TmkLogger: <134>Mar 2 19:59:48 tivosh[214]: TOTAL 1202428/ 0 bytes (32119 b
locks/ 0 chunks)
Dumping mempool to /tmp/BlockFailure.214

To view the blocks, run:

****cut for size***

TmkLogger: <129>Mar 2 20:00:21 TmkAssertionFailure[214]: (BlockFailure, line 2150 ())
Tmk Assertion Failure:
BlockFailure, line 2150 ()
TmkLogger: <129>Mar 2 20:00:21 tivosh[214]: Tmk Fatal Error: Thread tivosh <214> died d
ue to signal -2
Tmk Fatal Error: Thread tivosh <214> died due to signal -2
1ad0644 1acef60 1ac9264 1cf0e50 1cfcc28 1d48508 1d68740 1d686e0 1d63cfc 1d59e6c 1d478dc
1d6c688 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c688 1d59e6c
1d478dc 1d48464 1804670 18040ec 1bc8fec 1bc92fc 19c1740 1d4709c 1d59e6c 1d478dc 1d64974
1d65a80 1cfcbc8 1cfc910 1800134 TmkLogger: <129>Mar 2 20:00:21 tivosh[214]: Tmk Thread
Backtrace: 1ad0644 1acef60 1ac9264 1cf0e50 1cfcc28 1d48508 1d68740 1d686e0 1d63cfc 1d59e
6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c688 1d59e6c 1d478dc 1d6c6
88 1d59e6c 1d478dc 1d48464 1804670 18040ec 1bc8fec 1bc92fc 19c1740 1d4709c 1d59e6c 1d478
dc 1d64974 1d65a80 1cfcbc8 1cfc910 1800134
TmkLogger: <129>Mar 2 20:00:21 tivosh[214]: Tmk Fatal Error: Thread died due to signal
-2
TmkLogger: <129>Mar 2 20:00:21 tivosh[214]: Invoking rule 834: rebooting system
TmkLogger: <134>Mar 2 20:00:26 TmkReboot[214]: Programatic box reboot initiated

[sanderton]

I can't actually make out from the log you've posted what it was doing when it errored out - had you pressed to refresh Remote Now Showing? I'd expect to see log entries as it does it stuff, but there are none.

What version of the TiVo software are you running?

My problem is that I've never seen this error or anything like it, and that makes it rather hard to solve!

You're getting entries of:

TmkLogger: <134>Mar 2 19:54:53 tcl[214]: Tcl created pool of 1458176 bytes

in the telnet window when you start mfs_ftp?

I've never seen anything like that on my TiVos.

There seems to be a memory leak, or at least the mempool is running out of space. Thing is, the patch does not explictly use the mempool (to be honest, I wouldn't know how!) It doesn't do anything particularly memory intensive.

Erm....

Edit: can you set the dbl to 999 in settings.tcl and try again? That might give me some more clues.

[sanderton]

how can one uninstall the patch and clear out the dummy now playing entries?


Delete p1.tcl.

The easiest way to delete all the entries is to use your FTP client and mfs_ftp! Sort by size and all the dummy entries are only 1Mb.

So you're getting dummy entries? What were you doing whne it rebooted then?

[sanderton]

Aha:

http://www.dealdatabase.com/forum/showpost.php?p=150599&postcount=425

Perhaps it's not my bit of the code.

[eee]

A PC "version" of mfs_ftp to connect to this hack is perfectly possible in theory. To make it easier, it would need a modification to the .tmf format, but you could do it without that if you could live without the seamless viewing of a streaming recording.

Basically, you'd just put something together which looked to mfs_ftp at the TiVo end as though it were another copy of mfs_ftp. The parts of mfs_ftp where it reads the TiVo database would be replaced with reading the XML from the stored .tmf file. I presume there are PC ultils for reading the parts of a tarball.

How many people might be interested in that?

Im real interested in this modification to the mfs_ftp. to be able to store the Tivo's recordings on a central server and simply use the Tivo as the client is a dream. This hack would get me closer to having something similar to the Denon central server PVR system anounced this year.

what is the requirement that you mentioned that would require a modification to the tmp format ?

Im just now ramping up on the code so I can't imagine being of too much help at least for the next couple of weeks. But Im certianly interested in any way I can be of assistance.

[fredisdead]

It reboots while repopulating the now showing. I get many/most of the entries before it blows up. It seems to die towards the end of the Now Showing transfer.

Delete p1.tcl.

The easiest way to delete all the entries is to use your FTP client and mfs_ftp! Sort by size and all the dummy entries are only 1Mb.

So you're getting dummy entries? What were you doing whne it rebooted then?

[rc3105]

http://www.dealdatabase.com/forum/showthread.php?t=21915&page=428&pp=1

fwiw, I list shows available for transfer as tivo messages. whenever a new recording is available it sends recording.txt to "subscribed" tivos/pc. more of an e-mail / newsfeed style than tivo-hmo, but same result

[sanderton]

<duff reply>

[sanderton]

If you've been tinkering with this and ended up with some surplus channel 1000s in you line up, this will delete them.

It will delete the active one too, so you'll also have to delete the ../mfs_ftp/smp/snp.ini file to put a new set in!

[mini__me]

Excellent stuff :D

[sanderton]

I've added a second patch, p2.tcl, to the top post which should work with 1.2.9Q which Riley recently released. However it's completely untested as I'm still running 1.2.9P.

[SteveJenkins]

I've added a second patch, p2.tcl, to the top post which should work with 1.2.9Q which Riley recently released. However it's completely untested as I'm still running 1.2.9P.

Do we have to install both? What's the diff between the two?

BTW - finally got mine working AOK. Great stuff. Even my wife likes it :)

[sanderton]

Glad it's working for you. :)

It's either one or the other: p1.tcl if you have 1.2.9P, p2.tcl if you have 1.2.9Q. The difference is that the patch file replaces four of Riley's routines with my slightly amended ones, and I've re-made those amendments to the versions of the four routines in 1.2.9Q. The changes Riley has made to those four were not significant, so I don't anticipate problems. Unless he's changed any key variable names which I haven't spotted!

[SteveJenkins]

Glad it's working for you. :)

Perhaps I spoke too soon :)

I just installed a fresh version Q, and here's what I get when starting it up for the first time:

TiVo1: {~/mfs_ftp} % ./mfs_ftp.tcl
TiVo1: {~/mfs_ftp} % invalid command name "versioncheck"
while executing
"versioncheck"
(file "./p2.tcl" line 852)
invoked from within
"source $info(path)/$file.tcl "
(procedure "init_procs" line 5)
invoked from within
"init_procs"
(file "./mfs_ftp.tcl" line 1672)

[DocTauri]

One thing I haven't seen anyone comment on is the speed of this add-on. For me, it takes quite a while from the time I select to either populate the list, or retrieve a program, to the time it actually does it (usually about a minute). Is this the norm, or just me?

Other than that, it's great. Finally something my wife can do without hurting herself ;)

Thanks,
Doc

[sanderton]

Steve - thanks. As I said I haven't installed Q so I haven't tested it. Looks like the name of that procedure has changed (Riley seems to have developned an undercore fetish is names with Q :) ). I'll have a look later.

DocTauri - That time is normal. It has to mess around a bit in the background getting all the part headers in place, allocating the full disk space etc. before it actually starts the FTP transfer. It's required to be able to watch the programme while it copies uninterrrupted and with working trick play.

[SteveJenkins]

Steve - thanks. As I said I haven't installed Q so I haven't tested it. Looks like the name of that procedure has changed (Riley seems to have developned an undercore fetish is names with Q :) ). I'll have a look later.No problemo. Happy to be your lab rat. Let me know if you get an updated patch and I'll give it a go.

[Meklos]

Sanderton,

How possible is it to insert this as a Showcase instead of in the local Now Playing list?

Just wondering if this would gain us anything for everyday performance. If you want to see the list of remote stuff, go to showcases, then you could see the remote lists. Select what you want to move, then it would show up in the local NP.

Just a thought...

[sanderton]

Sanderton,

How possible is it to insert this as a Showcase instead of in the local Now Playing list?

Just wondering if this would gain us anything for everyday performance. If you want to see the list of remote stuff, go to showcases, then you could see the remote lists. Select what you want to move, then it would show up in the local NP.

Just a thought...

While I expect it might be possible to load the remote NP into the Showcase menu somehow,we don't get them here so I don't know!

[Meklos]

Can anyone provide any insight into this? Does anyone know how someone would insert a list (of programs) into a showcase, or anywhere other than the Now Showing list?

I'm thinking that if you could keep the remote listings out of the main NS database, performance could be greatly improved. Maybe the function could read a list of files instead of having to walk the NP database? Somehow generate that list on the remote Tivo (or other box? FTP server?) and have the local Tivo just download that list instead of bringing things into the local database?

Just thinking out loud...

[cojonesdetoro]

Can anyone provide any insight into this? Does anyone know how someone would insert a list (of programs) into a showcase, or anywhere other than the Now Showing list?

How about sending it to the Tivo messages?

I have a piece of code I could never make stable that has client and server components. it gets the list of recordings with FSIDS from a remote Tivo and inserts it as a message in the local Tivo. You can then browse the list of recordings, memorize the FSID of a recording you want, go to the program description screen and launch an interface that let's you request the FSID from the other Tivo. It then initates an FXP transfer from the other Tivo. It's cumbersome but very lightweight. It can also 'send' a recording to another Tivo. I also have DIAG screens where you can select the remote Tivo, if you have more than two Tivos, restart mfs_ftp on local and remote Tivos and other diag stuff.

The only issue I never overcame was the 'event bug'. My script registers a remote event as per an example script I found (merge.tcl) . Eventually, the tivo stops responding to the remote control if you leave my script running. I never found a viable way around it and have since given up because Stuart's and Cwingert's projects have rendered my stuff pretty much obsolete.

If anyone is interested in it I can send you a copy. It would be even better if someone could find an easy method for circumventing the event bug. The guy who wrote TCS (zirak?) said he has a way around it but I haven't had a chance to investigate his code. He wrote a TCS module for the chunkedit project that has everything I need to make my script work. I've also considered porting my stuff to be a TCS module. But time, time, time... it's a scarce commodity... I gotta find a way to pick the stuff up again. I guess if there's enough interest I might take a crack at fixing it.

[Meklos]

How about sending it to the Tivo messages?

I have a piece of code I could never make stable that has client and server components. it gets the list of recordings with FSIDS from a remote Tivo and inserts it as a message in the local Tivo. You can then browse the list of recordings, memorize the FSID of a recording you want, go to the program description screen and launch an interface that let's you request the FSID from the other Tivo. It then initates an FXP transfer from the other Tivo. It's cumbersome but very lightweight. It can also 'send' a recording to another Tivo. I also have DIAG screens where you can select the remote Tivo, if you have more than two Tivos, restart mfs_ftp on local and remote Tivos and other diag stuff.

The only issue I never overcame was the 'event bug'. My script registers a remote event as per an example script I found (merge.tcl) . Eventually, the tivo stops responding to the remote control if you leave my script running. I never found a viable way around it and have since given up because Stuart's and Cwingert's projects have rendered my stuff pretty much obsolete.

If anyone is interested in it I can send you a copy. It would be even better if someone could find an easy method for circumventing the event bug. The guy who wrote TCS (zirak?) said he has a way around it but I haven't had a chance to investigate his code. He wrote a TCS module for the chunkedit project that has everything I need to make my script work. I've also considered porting my stuff to be a TCS module. But time, time, time... it's a scarce commodity... I gotta find a way to pick the stuff up again. I guess if there's enough interest I might take a crack at fixing it.



Well, the reason I thought the showcases is... They're already "video" entries. If they could be formatted into a list, similar to the NP list, then the same code for retreiving the remote file and inserting it into the local NP list could be used.

[sanderton]

I think Riley said in one thread the he used messages similarly.

[rc3105]

wow, 'n I thought I was absent minded... :p (that was post #80 of this thread!)

I use dummy nowshowing entries like "season passes" for content avail on other tivos & messages more like suggestions. ALL Stargate are allways availble in nowshowing whereas recent evening news & such are in msgs


a sendmail style daemon ftp's the .txt of new recordings to "subscribed" tivos, then another little daemon grabs / converts each recording.txt into a tivo message. an event monitoring script keeps it's ear to the ground for context changes and a remote keypress while viewing a msg initiates a fxp transfer

messages expire when the recording save-till runs out or it get deleted when initiating the fxp or the original tivo sends a follow up "no longer avail" msg

[cojonesdetoro]

:confused:

Oh, GREAT ONE, WE ARE NOT WORTHY!!! :D

What are the chances of you publishing this wonderful 'recording distribution and messaging system'?

I, for one, would be willing to accept it and never, EVER ask for support. ;)

[Meklos]

wow, 'n I thought I was absent minded... :p (that was post #80 of this thread!)

I use dummy nowshowing entries like "season passes" for content avail on other tivos & messages more like suggestions. ALL Stargate are allways availble in nowshowing whereas recent evening news & such are in msgs


a sendmail style daemon ftp's the .txt of new recordings to "subscribed" tivos, then another little daemon grabs / converts each recording.txt into a tivo message. an event monitoring script keeps it's ear to the ground for context changes and a remote keypress while viewing a msg initiates a fxp transfer

messages expire when the recording save-till runs out or it get deleted when initiating the fxp or the original tivo sends a follow up "no longer avail" msg


Do the additional entries in Now Showing end up in database performance degradation for you? That was the whole reason I asked if it could be entered as a Showcase, or really anywhere else OTHER than NS.

But if it doesn't affect list performance, then it would only be a cosmetic 'list size' thing...


Also, do you know if anyone has overcome the S1>S2 audio header problems?


Thanks for everything you've done so far. Some of us are very thankful for your help and guidance... :)

[rc3105]

Meklos:

lots of messages don't seem to have any impact, but nowshowing entries do. for more than 300 or so you need to restore with the mfstools -p option, use large/multiple swapfiles, remove ideturbo, optomize hdparm settings & maybe even get a cachecard (guess the tivoapp programmers never expected needing to manage a zillion recordings)

I can fix the s1->s2 audio issue, but so far it breaks mpg conversion with tytool / tystudio. don't have access to the tytool source, haven't had the energy/need to update tystudio & don't really feel like opening that can of worms publicly yet


cojonesdetoro:

had planned to post some new utils on mfs_ftp's 1 yr anniversary, but this (http://www.dealdatabase.com/forum/showthread.php?t=32035) pissed me off, then the oztivo peeps also ignored the redistribution restrictions. still debating whether to put my tivos & mfs dev knowledgebase on ebay + get a different hobby...

[cojonesdetoro]

still debating whether to put my tivos & mfs dev knowledgebase on ebay + get a different hobby...

That would be a great loss.

Don't let the few people who pervert your good work ruin it for the rest of us. I hope I can speak for the vast majority of people here when I state that your good work and talents are greatly appreciated. I have tried, with my limited time and skills to contribute and I hope many more do. I think anyone who contributes anything in the way of hacks to the Tivo community today should be humble enough to acknowledge, as Newton did, that they 'stand on the shoulders of giants' .

You, my friend, are one of the 'giants' here. I would hate to see you go.

[johndickjr]

I am having some success and some problems ... any assistance would be appreciated. I can get my DirecTivos to populate the list of the other Tivo in Now Playing but cannot get the transfer between them to work.

1) If you are running v2.5.x, fix the mwstate bug
Not running 2.5
2) Check that you are running mfs_ftp v 1.2.9P
Confirmed 1.2.9.P
3) Check that you can get an acceptable FXP transfer going from one TiVo
to the other using SmartFTP or similar.
Confirmed FXP transfer with SmartFTP (never knew that type of FTP was possible, cool)
4) Shut down mfs_ftp
Done
5) Unzip the enclosed on your PC
Done
6) Edit the p1.tcl file to include the IP addresses of the local and remote TiVos, and any other settings you wish to change (see below) If you have other patches already installed as p1.tcl, rename this file so it loads last.
Used as p1.tcl on both
7) FTP the file p1.tcl to the same directory as mfs_ftp.tcl
Done
8) Start mfs_ftp
Was running it in BG, but tried it in FG to attach results below
9) If you want the remote items to be marked in Now Playing, use TivoWeb's Logos module to associate remotetivo-tw-s2-p2.png with channel 1000, REMOTE_TIVO (Will require a restart to be visible)
Can't get logo to import because of invalid file format (I have looked at the previously mention thread on this subject and will fix this independent of this post)
10) Repeat on second TiVo.
Repeated

I removed mfs_ftp from startup, rebooted each Tivo, loaded mfs_ftp in foreground. Then Refreshed Remote from each of the units. Then tried to play a remote recording once/twice

It goes directly to the screen after you are done watching a video, the one that asks it you want to delete it now ......
Any ideas ?

--------------Captured info-------------------
tivo:/$ /var/mfs_ftp/mfs_ftp.tcl 3105 foreground
12:12:37:AM - sourcing settings
12:12:37:AM - Running SNP patch 1.0b8
07:12:37:PM - sourcing p1
07:12:42:PM - updating cached recording info
..................................................................

..................................................................

catch close lastsock val "can't read "info(lastsock)": no such element in array"
bgerror invoked with error

" /tmp/mwstate: context.pTitleListCtrlM.iCurrent: context not found "

re-initializing mfs_ftp

close the current ftp connection and simply open another

"core dump" :p

info(version): 1.2.9p
info(tswv): 3.1.1-01-2-351
info(dbl): 0
info(ithrottle): 2
info(insert_priority): 10
info(multithreaded): 0
info(saveuntil): suggestion
info(name_detail): 5
info(bjuggle): 0
info(active): 0
info(ac_interval): 1800
info(gatewayip): 127.0.0.1
info(gatewayport): 3105


catch close lastsock val "can't read "info(lastsock)": no such element in array"
retrying after errTmActiveLockConflict ...
Repeats 7 times
07:17:28:PM - updating cached recording info
............................................................................

............................................................................

07:35:16:PM - 220 Mfs_Ftp ver 1.2.9p - {sock14} from "192.168.0.2:1025"
07:35:36:PM - 331 User name okay, need password.

------------------ Second unit ----------------------
tivo:/var/tmp$ /var/mfs_ftp/mfs_ftp.tcl 3105 foreground
12:13:29:AM - sourcing settings
12:13:29:AM - Running SNP patch 1.0b8
07:13:30:PM - sourcing p1
07:13:33:PM - updating cached recording info
...........................................................................

...........................................................................

catch close lastsock val "can't read "info(lastsock)": no such element in array"
retrying after errFsLockConflict ...
retrying after errTmActiveLockConflict ...
retrying after errTmActiveLockConflict ...
07:21:12:PM - updating cached recording info
..............................................................................

..............................................................................

07:29:01:PM - 220 Mfs_Ftp ver 1.2.9p - {sock12} from "192.168.0.3:1025"
07:29:21:PM - 331 User name okay, need password.
07:34:36:PM - 220 Mfs_Ftp ver 1.2.9p - {sock13} from "192.168.0.3:1026"
07:34:56:PM - 331 User name okay, need password.

[SteveJenkins]

still debating whether to put my tivos & mfs dev knowledgebase on ebay + get a different hobby...Nononononono.... Don't do it, man!

[sanderton]

I am having some success and some problems ...

" /tmp/mwstate: context.pTitleListCtrlM.iCurrent: context not found "


This looks like it might be the problem. Can you try "playing" a remote recording, then ftp off /tmp/mwstate and post it?


07:29:01:PM - 220 Mfs_Ftp ver 1.2.9p - {sock12} from "192.168.0.3:1025"
07:29:21:PM - 331 User name okay, need password.
07:34:36:PM - 220 Mfs_Ftp ver 1.2.9p - {sock13} from "192.168.0.3:1026"
07:34:56:PM - 331 User name okay, need password.


I presume this is you doing stuff from your PC, as there isn't any corresponding log at the other end.

[johndickjr]

The /tmp folder is a link to /var/tmp.
The mwstate file is a zero byte file that get a current date/timestamp.

I had installed mfs_ftp 1.2.9Q, but had the problem mentioned earlier in this thread, p2.tcl did not fix it. I loaded 1.2.9p over top of 1.2.9Q; had problems and posted the message above.

Today, I completely remove the /var/mfs_ftp directory and reloaded
mfs_ftp 1.2.9p from here (http://www.dealdatabase.com/forum/attachment.php?attachmentid=2940) and the series 2 binaries from here (http://www.dealdatabase.com/forum/attachment.php?attachmentid=2900).

Then I re-downloaded your SNP 1.08B from here (http://www.dealdatabase.com/forum/attachment.php?attachmentid=2775) , extracted p1.tcl and edited it for my Tivo addresses.

Put it up in the /var/mfs_ftp directory. Started mfs_ftp and it added a second set of "Refresh Remote" and "Delete Remote" selections.
I deleted all 4 "Remote" selections, ran the remchan.tcl script and restarted mfs_ftp. It did not repopulated the "Remote Refresh" and "Remote Delete" entries. How do I get them back?

I confirmed that I can FXP videos back and forth between the two Tivos using SmartFTP. I can also watch them while transferring similar to a show that is being recorded by the Tivo natively.

I noticed under Logos in TivoWebPlus v1.0-rc5 that there are two entries for TIVOD and TIVOR on channels 1100 and 1101 even after running remchan.tcl, in case it is related.

Thanks for sharing this bit of code, I cannot wait to seamlessly watch video independent of where they were recorded.

John

[sanderton]

To get the menu entries back, delete the ../mfs_ftp/snp dircetory and phoenix mfs_ftp.

mwstate gets deleted pretty soon after its created, so you need to copy it off right away after trying to trigger a transfer.

TIVOD and TIVOR are nothing to do with this hack.

If you still have truble, edit info(snpdbl) in the code to be 99, which will give more fulsome logs!

[johndickjr]

I did get the two "Remote" items back in NP, but only one has repopulated channel 1000 (listed as receiving below). It may be because I have not run "Get Remote" on the other (listed as source below) yet.
Bet you can tell by the logs that the source Tivo is mostly a kids show Tivo :-)

Set info(snpdbl) and info(dbl) both to 99

port.3105.log file contents from requesting Tivo
11:34:17:PM - "192,168,0,3:3105" ready for connections
11:36:38:PM - Dumpstate called at Fri Mar 19 04:36:38 UTC 2004
11:36:38:PM - Ident: 2
11:36:44:PM - Dumpstate called at Fri Mar 19 04:36:44 UTC 2004
11:36:44:PM - Ident: 7
11:36:48:PM - Dumpstate called at Fri Mar 19 04:36:48 UTC 2004
11:36:48:PM - Ident: 8
11:36:50:PM - Dumpstate called at Fri Mar 19 04:36:50 UTC 2004
11:36:50:PM - Ident: 119
11:36:51:PM - Dumpstate called at Fri Mar 19 04:36:51 UTC 2004
11:36:51:PM - Ident: 31
11:36:53:PM - Dumpstate called at Fri Mar 19 04:36:53 UTC 2004
11:36:53:PM - Ident: 7
11:36:53:PM - Running get_mwstate
11:36:53:PM - running local get_mwstate
11:36:54:PM - Doing the event loop
11:36:54:PM - sending dumpstate event
11:36:54:PM - waiting
11:36:55:PM - checking if file exists
11:36:57:PM - opening file
11:36:57:PM - Reading file
11:36:57:PM - Statefile: context {
pTitleTextCtrlM {
pTextM {Now Playing List}
}
id {7}
pTitleListCtrlM {
iTop {0}
iCurrent {2}
nVisible {8}
nItemMax {48}
fPage {true}
fMoreIconM {true}
nItem {48}
0 {
string {Refresh Remote Now Playing items}
}
1 {
string {Delete Remote Now Playing items}
}
2 {
string {Ed, Edd 'n Eddy}
}
3 {
string {Yu-Gi-Oh!}
}
4 {
string {Yu-Gi-Oh!}
}
5 {
string {Yu-Gi-Oh!}
}
6 {
string {The Cosby Show}
}
7 {
string {Codename: Kids Next Door}
}
8 {
string {Ed, Edd 'n Eddy}
}
9 {
string {Yu-Gi-Oh!}
}
10 {
string {Yu-Gi-Oh!}
}
11 {
string {Ed, Edd 'n Eddy}
}
12 {
st
11:36:57:PM - After regsub: context {
pTitleTextCtrlM {
pTextM {Now Playing List}
}
id {7}
pTitleListCtrlM {
iTop {0}
iCurrent {2}
nVisible {8}
nItemMax {48}
fPage {true}
}}
11:36:57:PM - Local ID of file to get: 103825
11:36:57:PM - Got command: start mfs_ftp transfer for {Ed, Edd 'n Eddy} (id 1038
25)
11:36:57:PM - Running snp_open_socket
11:36:57:PM - abortcheck: "ping_pong"
11:36:57:PM - Opened socket as sock33
11:36:57:PM - Running snp_readfromsocket
11:36:57:PM - nbytes = -1, Returning: {220 Mfs_Ftp ver 1.2.9p - {sock19} from "1
92.168.0.3:1041"}
11:36:57:PM - sent USER TIVO
11:36:58:PM - Running snp_readfromsocket
11:36:58:PM - nbytes = -1, Returning:
11:37:02:PM - update_rec_fsids: forced 0
11:37:03:PM - no update necesary

port.3105.log file contents from source Tivo

11:36:56:PM - 220 Mfs_Ftp ver 1.2.9p - {sock19} from "192.168.0.3:1041"
11:37:16:PM - serverip "192.168.0.2"
11:37:16:PM - readlinefromsocket: "sock19"
11:37:16:PM - echo to verify: "USER TIVO"
11:37:16:PM - parseline:
"USER TIVO"
11:37:16:PM - USER: "TIVO"
11:37:16:PM - 331 User name okay, need password.

I'm so close I can almost taste it.

[sanderton]

The problem seems to be the 20 second delay on the source machine between it being sent "USER TIVO" and its reacting and replying to it. Meantime the target machine timed out waiting for the response, which would normally be instantaneous.

Do you see such a delay when you connect to that machine with a PC FTP client?

[johndickjr]

Do you see such a delay when you connect to that machine with a PC FTP client?

Yes, I actually had to increase the timeout in SmartFTP. I have searched the mfs_ftp forum for slow response, cannot login, timeout and cannot find anything to help.

Also, running TOP on both boxes shows that they are not processor or memory bound ....

Mem: 41304K used, 2476K free, 0K shrd, 164K buff, 26284K cached
Load average: 0.13, 0.33, 0.40 (State: S=sleeping R=running, W=waiting)

PID USER STATUS RSS PPID %CPU %MEM COMMAND
289 0 R 788 239 4.3 1.7 top
47 0 S 1352 1 2.2 3.0 dssappAV
76 0 S 1808 75 1.8 4.1 mfsd
170 0 S 5240 127 1.5 11.9 myworld

Thank you for all of you help,
John

[sanderton]

Yes, I actually had to increase the timeout in SmartFTP. I have searched the mfs_ftp forum for slow response, cannot login, timeout and cannot find anything to help.

Also, running TOP on both boxes shows that they are not processor or memory bound ....

Mem: 41304K used, 2476K free, 0K shrd, 164K buff, 26284K cached
Load average: 0.13, 0.33, 0.40 (State: S=sleeping R=running, W=waiting)

PID USER STATUS RSS PPID %CPU %MEM COMMAND
289 0 R 788 239 4.3 1.7 top
47 0 S 1352 1 2.2 3.0 dssappAV
76 0 S 1808 75 1.8 4.1 mfsd
170 0 S 5240 127 1.5 11.9 myworld

Thank you for all of you help,
John

I have no idea what might cause that; but it's a problem with at the core mfs_ftp end, not the patch.

I guess you could try changing the pause in the code waiting for a reply:


after 500
set readvalue [snp_readfromsocket $remmfsftp]
if {[string range $readvalue 1 3] == "331"} {
puts $remmfsftp "PASS thistivo"
flush $remmfsftp
outd $info(snpdbl) "sent PASS thistivo"
} else {
return -1
}


the 500 is 500 miliseconds, try upping it to 20000.

But you've be better off finding and fixing the cause of the problem!

[rreyes310]

does this hack work on the dsr7000?

totally n00b question, i know... read through the thread, didnt find anything, did a search in the thread, no results.

thanks.
-r

[sanderton]

does this hack work on the dsr7000?

totally n00b question, i know... read through the thread, didnt find anything, did a search in the thread, no results.

thanks.
-r

The requirements are in the first post. If you can get a TiVo to TiVo transfer going with mfs_ftp using a PC, and you are using software <4, then it should work.

[lgkahn]

I am running the lastest mfs_ftp and your p2.tcl script and have the ip addresses correct here are some commands I ran on the tivo trying to show you that everything is correct and that it is running but connections are not working.. no crashes but the remote list is not coming up in now playing any ideas.. thanks for all your help...

ie...
dtivo 3.1.1b on one box
3.1.1c on the other...



tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$ cd /var/logs
bash: cd: /var/logs: No such file or directory
tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$ cd /var/log
tivo:/var/log$
tivo:/var/log$ cat mfs_ftp.log
03:33:40:AM - sourcing settings
03:33:40:AM - Running SNP patch 1.0b8 (Q)
tivo:/var/log$
tivo:/var/log$
tivo:/var/log$ cd /var/mfs_ftp
tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$ grep -i 216 p2.tcl
set remotetivo "216.177.20.118"
set thistivo "216,177,20,126"
tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$ grep -i 5013 p2.tcl
set listenport 5013
set remotexml [snp_open_socket $remotetivo 5013 10000]
tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$ telnet 216.177.20.118 5013
telnet: Unable to connect to remote host (216.177.20.118): Connection refused
tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$ ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:0.0.0.0 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:100 dropped:2 overruns:0 carrier:0 coll:0

eth0 Link encap:Ethernet HWaddr 00:10:60:25:3D:6A
inet addr:216.177.20.126 Bcast:216.177.20.127 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1384 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:123936 dropped:1044 overruns:0 carrier:0 coll:0

tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$ telnet 216.177.20.118



Entering character mode
Escape character is '^]'.

tivo:/var/tmp$
tivo:/var/tmp$
tivo:/var/tmp$
tivo:/var/tmp$
tivo:/var/tmp$ exit
logout
Connection closed by foreign host.
tivo:/var/mfs_ftp$

[lgkahn]

Got it running with the Q version had to replace as you summized
versioncheck

with
version_check

in line 852 of the p2.tcl file

thanks

[lgkahn]

more info I can get the list now but I cannot play a recording.. I get this error in the mfs_ftp log....

from looking at the code it looks like there is no longer a firstbit variable in mfs_ftp and I check it also does not apper to be first_bit either..

sigh....


/var/log/mfs_ftp.log/
05:16:24:AM - sourcing settings
05:16:24:AM - Running SNP patch 1.0b8 (Q)
12:16:25:AM - sourcing p2
12:16:28:AM - updating cached recording info
...........................................

...........................................

catch close lastsock val "can't read "info(lastsock)": no such element in array"
bgerror invoked with error

" can't read "firstbit": no such variable "

re-initializing mfs_ftp

close the current ftp connection and simply open another

"core dump" :p

info(version): 1.2.9Q
info(tswv): 3.1.1c-01-2-151
info(dbl): 0
info(ithrottle): 2
info(insert_priority): 10
info(multithreaded): 0
info(save_until): suggestion
info(name_detail): 5
info(bjuggle): 0
info(active): 0
info(ac_interval): 1800
info(gateway_ip): 127.0.0.1
info(gateway_port): 3105


catch close lastsock val "can't read "info(lastsock)": no such element in array"
bgerror invoked with error

" can't read "firstbit": no such variable "

re-initializing mfs_ftp

close the current ftp connection and simply open another

"core dump" :p

info(version): 1.2.9Q
info(tswv): 3.1.1c-01-2-151
info(dbl): 0
info(ithrottle): 2
info(insert_priority): 10
info(multithreaded): 0
info(save_until): suggestion
info(name_detail): 5
info(bjuggle): 0
info(active): 0
info(ac_interval): 1800
info(gateway_ip): 127.0.0.1
info(gateway_port): 3105


catch close lastsock val "can't read "info(lastsock)": no such element in array"
12:22:04:AM - bgerro_bail quiting mfs_ftp.tcl and forking a new one
12:22:04:AM - 200 shutting down the server NOW from "phoenix_mfs_ftp"
05:22:09:AM - sourcing settings
05:22:10:AM - Running SNP patch 1.0b8 (Q)
12:22:10:AM - sourcing p2
12:22:21:AM - updating cached recording info
...........................................

...........................................

catch close lastsock val "can't read "info(lastsock)": no such element in array"
bgerror invoked with error

" can't read "firstbit": no such variable "

re-initializing mfs_ftp

close the current ftp connection and simply open another

"core dump" :p

info(version): 1.2.9Q
info(tswv): 3.1.1c-01-2-151
info(dbl): 0
info(ithrottle): 2
info(insert_priority): 10
info(multithreaded): 0
info(save_until): suggestion
info(name_detail): 5
info(bjuggle): 0
info(active): 0
info(ac_interval): 1800
info(gateway_ip): 127.0.0.1
info(gateway_port): 3105


catch close lastsock val "can't read "info(lastsock)": no such element in array"
12:24:11:AM - bgerro_bail quiting mfs_ftp.tcl and forking a new one
12:24:11:AM - 200 shutting down the server NOW from "phoenix_mfs_ftp"
05:24:14:AM - sourcing settings
05:24:14:AM - Running SNP patch 1.0b8 (Q)
12:24:15:AM - sourcing p2
12:24:20:AM - updating cached recording info
...........................................

[Meklos]

The delay is caused by the Tivo trying to do a name lookup on the IP address of the remote end.

I remember someone posting a fix for it, but I can't find the post right offhand...

[sanderton]

more info I can get the list now but I cannot play a recording.. I get this error in the mfs_ftp log....

from looking at the code it looks like there is no longer a firstbit variable in mfs_ftp and I check it also does not apper to be first_bit either..
...

"firstbit" is an internal variable of the patch. Sounds like the dumpsate isn't doing its stuff.

Could you edit p2.tcl to change the value of info(snpdbl) to 99, and also change info(dbl) to 99 in settings.tcl. Try to run some stuff and then upload the port3105.log file from .../mfs_ftp and the mwstate file from /tmp

Thanks!

[lgkahn]

now I cannot even get the remote playing list I did a find pipped to greap and there is not log file like you described being generated on the system..
here are the first few lines of my p2.tcl file and mfs_ftpis running fine on both systems as I can connect to it.. and your info line is in the log in so the extension is running.. ie..

set snpversion "1.0b8 (Q)"

# Initalise variables & stuff

proc snp_init { } {

global remotetivo calendaroffset info leftarrow thistivo tivo select listenport dummystation dummychan delete refresh last31
set info(snpdbl) 99
outd $info(snpdbl) "Initialising SNP variables"

set remotetivo "216.177.20.126"
# change to the IP of the remote TiVo

set thistivo "216,177,20,118"
# change to the IP of this TiVo WITH COMMAS NOT FULL STOPS

ie

C:\>ftp
ftp> open tivo2 3105
Connected to tivo2.
220 Mfs_Ftp ver 1.2.9Q - {sock23} from "216.177.20.125:1452"
User (tivo2:(none)):
331 User name okay, need password.
Password:
230 Running in TiVo Mode.
ftp> dir
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
dr--r--r-- 1 0 0 1024 Jan 01 1972 tmf
dr--r--r-- 1 0 0 1024 Jan 01 1972 ty
dr--r--r-- 1 0 0 1024 Jan 01 1972 ty+
dr--r--r-- 1 0 0 1024 Jan 01 1972 xml
dr--r--r-- 1 0 0 1024 Jan 01 1972 txt
dr--r--r-- 1 0 0 1024 Jan 01 1972 bat
dr--r--r-- 1 0 0 1024 Jan 01 1972 asx
-r--r--r-- 1 0 0 0 May 31 19:00 phoenix.txt
-r--r--r-- 1 0 0 0 May 31 19:00 shutdown.txt
226 Transfer complete.
ftp: 542 bytes received in 0.05Seconds 10.84Kbytes/sec.
ftp>

C:\>ping tivo2

Pinging tivo2 [216.177.20.118] with 32 bytes of data:

Reply from 216.177.20.118: bytes=32 time<10ms TTL=255
Reply from 216.177.20.118: bytes=32 time<10ms TTL=255
Reply from 216.177.20.118: bytes=32 time<10ms TTL=255
Reply from 216.177.20.118: bytes=32 time<10ms TTL=255


an mwstate file...

do you have a link to download a good version of theP mfs ftp and the s2 binaries thanks....

[sanderton]

Look in the folder which mfs_ftp.tcl sits; the log file is in there.

That mwstate is fine.

[Milton]

Look in the folder which mfs_ftp.tcl sits; the log file is in there.

That mwstate is fine.

in Q it logs to /var/log/mfs_ftp.log


I'm also trying to get the up between to s2dvr's

mfs_ftp ver p
I can fxp with smart ftp and get 500k s

modified p1.tcl
# after 500
after 21000
set readvalue [snp_readfromsocket $remmfsftp]

that fixd the timeout error and both machine receive and remove the NP list
the file transfer part fails it will start and put a bracketed entry into NP {show}{time} kinda thing...


any help would be great :) thanks

[sanderton]

Thanks.

I can see the problem.

I need to sit down and have a look at the code in Q to see what's caused it.

[lgkahn]

are you talking about my problem or someone elses.. because there definately is no log like you specify in the mfs_ftp directly there is a mfs_ftp.log file if /var/logs as the other person alluded tooo.,...

[sanderton]

are you talking about my problem or someone elses.. because there definately is no log like you specify in the mfs_ftp directly there is a mfs_ftp.log file if /var/logs as the other person alluded tooo.,...

Riley must have moved it with Q - it used to be in ../mfs_ftp honest!.

I was referring to the last post.

Can you upload yours - my guess is its the same problem.

[lgkahn]

I already disabled it on both machines because it gets in the way of the 30 second skip and info sort hacks so If I get it working I will have to disable those.. but I will turn it back on both boxes this weekend and give another go at it and get you the log files...

thanks for your help .. if you have a new version of p2.tcl by then let me know.. I guess the other pserson also did the version_Check change to get going.... it looks to me like Q may be using a local version of the mwstate could that have something to do with it???


I also recall seeing errors in the log about command not found....

[lgkahn]

here is another log..
what gives it looks like it is not going out the the remote machine

only the requesting mfs_ftp has anyting in the log and it is going through its own recordsings saying it already has them.. ok...

that is why it is not inserting any but I double checked the ips in the pc.tcl and they are correct not reversed...


ie...


set remotetivo "216.177.20.126"
# change to the IP of the remote TiVo

set thistivo "216,177,20,118"
# change to the IP of this TiVo WITH COMMAS NOT FULL STOPS

set remotepos normal
# normal = remote items in normal place
# top = remote items at top of NP
# bottom = remote items at bottom of NP

set dummychan 1000
# if your setup really has a channel 1000, change this

# Filters: to reduce the number of remote items to a managable level
set info(skipchan) "REMOTE_TIVO CBEEB"
# Callsigns of channels which will not be displayed on local TiVo separated by
spaces
--More--

tivo:/var/mfs_ftp$ ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:0.0.0.0 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0

eth0 Link encap:Ethernet HWaddr 00:10:60:25:0B:86
inet addr:216.177.20.118 Bcast:216.177.20.127 Mask:255.255.255.240
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3125 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:316798 dropped:2714 overruns:0 carrier:0 coll:0

tivo:/var/mfs_ftp$
tivo:/var/mfs_ftp$