actually there was.
I've got a phillips at 1.3, I'll see if i can duplicate your problem
Streams were extracted to ext3 and using mplayer I can skip to the end which looks like the end of the films.
I think they were recorded when the software was at 1.5.x. There wasn't a format change from 1.x to 2.x was there?
actually there was.
I've got a phillips at 1.3, I'll see if i can duplicate your problem
---
Give a man a fish and he will eat for a day. Teach a man to fish and he will sit in a boat all day and drink beer
can i still use ftp to transfer programs and other files in addition to .ty stuff with this? i know it's a stupid question, but i had to ask.
use tivoftpd (running on port 21) to transfer regular files, same as allways
use mfs_ftp (on port 3105) to transfer recordings
---
Give a man a fish and he will eat for a day. Teach a man to fish and he will sit in a boat all day and drink beer
Just want to say thanks for such great program and keep improving it.
After using the 1.2.9B for quite a few months, suddently, it has been crashing my DTivo until I removed it from my startup. No idea what happened to it. Just upgraded to 1.2.9H and all is back to normal again.![]()
probably those wacky taken episodes. H should have that solved
---
Give a man a fish and he will eat for a day. Teach a man to fish and he will sit in a boat all day and drink beer
I'm not sure where I lost this function, but has anyone else noticed this... when I first setup MFS_FTP, the shutdown and phoenix "commands" would show up as folders and if you double clicked on them they would perform their function.
In the last 4 or 5 iterations of MFS_FTP, those commands now show up as txt files and when I double click on them nothing happens.
Thoughts or suggestions on how to get around this?
Thanks!
I'm getting intermittent transfer speeds switching around regularly (regular intermittencey ... nice).
if I extract a ty using tytool i typically get just under 500kBps for the duration of the transfer. I've got dumeter showing a graphical display of the transfer ... bit of a wibbly top of the graph but pretty much constant.
when i fire up an mfs_ftp tmf transfer with smartftp on my winxp pro (sp1) box i get a nice 600-700kBps extraction for a few seconds ... then the graph drops to 350kBps ... then down to 200kBps and quickly back up to 600Kbps ... and so on (looks like a load of churchs scrolling past my dumeter display !). net effect is my transfer runs at around 350kBps average ... but possibly more importantly usually dies after a minute or two. smartftp sits waiting, dumeter shows no traffic, then smartftp shows a message that the connection timed out and was closed by the server (tivo). I've tried switching passive off & on without any joy.
the full connection path is UK SA1 tivo with a turbonet to a D-Link 900+ wireless access point, D-Link 520+ PCI card in my PC ... i get consistant tytool speed, wonder what could be mocking my mfs_ftp stuff
did i forget ... thanks for a fantastic tool !!!
Duncan
I use SmartFTP to my HDVR2 running 1.2.9H, and double-clicking on the shutdown.txt shuts down the mfs_ftp server-side program (daemon?) as it should.Originally posted by SirTrini
In the last 4 or 5 iterations of MFS_FTP, those commands now show up as txt files and when I double click on them nothing happens.
I see a message in the "log" window, but my "connection" window doesn't visibly change. This is identical (IIRC) with the way it worked with the shutdown "folder".
When you say "nothing" happens, are you saying you're still able to download shows, etc.?
In regards to the shutdown and phoenix beeing a text file. Some FTP programs won't automatically do anything with the files like they will a folder. for example, in SmartFTP, I have to right-click the text file--say shutdown.txt, and click View. That will take care of it...
=-BAHitman
3 HDVR2 - 1x160G 4.01b
3 DSR7000 - 1x160G 4.01b
1 Tivo 60hr - 1x60G 7.1
TiVo - The best thing since Color TV!
I only have to double-left-click on "shutdown.txt" in SmartFTP to shut down MFS_FTP. Perhaps it is dependent on how you have the "double-left-click" configured in SmartFTP?for example, in SmartFTP, I have to right-click the text file--say shutdown.txt, and click View. That will take care of it...
I am currently transfering an NFL game from one DTivo to another DTivo via FXP (it will be some time before it is finished). The source unit is running 1.2.9G and the destination unit is running 1.2.9H. (I didn't feel like upgrading the source machine, and the destination machine is a new install). I received the following warning/error:
I've seen this error before but the transfer seemed to be ok. But I thought I would ask specifically, what does "TmkTclEvent::QEvent[2030]: Event Q reached max size, events have been lost" mean?Code:07:02:43:PM - 150 Opening BINARY mode data connection for "{{Chargers @ Broncos San Diego Chargers at Denver Broncos}{1970-01-01}{San Diego Chargers at Denver B roncos}{04.00 PM Sun Nov 16, 2003}{NFL}.tmf}" importing fsid 57084 of size 536870912 <174>Nov 20 00:07:34 TmkTclEvent::QEvent[2030]: Event Q reached max size, events have been lost 100% 512 meg 840k/sec inserted 512 meg at 840k/sec importing fsid 57088 of size 536870912 21% 112 meg 877k/sec
the tcl event loop can trigger procedures whenever a variable changes, new socket is opened, channel becomes readable/writeable, etc
the import & export procedures don't return control to the event loop durning transfers, events aren't processed & eventually you get "<174>Nov 20 00:07:34 TmkTclEvent::QEvent[2030]: Event Q reached max size, events have been lost" or some such
nothing to worry 'bout - only affects mfs_ftp which isn't multithreaded yet anyway
---
Give a man a fish and he will eat for a day. Teach a man to fish and he will sit in a boat all day and drink beer
Roger that! Muchas Gracias!
haven't seen this mentioned, so I though't I'd point it out.
mfs_ftp doesn't like dealing with programmes where a power outage or reboot has split a programme into two identically named files. If you try to copy both segments, you get the first one twice!
Renaming one in TiVoWeb and restarting (so the cache is bebuilt) solves.