Page 42 of 84 FirstFirst ... 32404142434452 ... LastLast
Results 616 to 630 of 1257

Thread: TyTool 10r4 - Extraction/Frame Accurate Editing/DVD output/Closed Captioning...

  1. #616
    Join Date
    Dec 2004
    Posts
    831

    Slow transfers

    Quote Originally Posted by presidentsdad View Post
    I haven't used it in a few weeks and tried to start tserver (located in /var/hack) and it wasn't there.
    If /var gets full, the TiVo will clear it out, evaporating some of your hacks. The alternative is to place the hack in some place other than /var or /proc. Doing so requires you to remount the root partiton, which can be risky if one is not careful. Also, any hack which requires writing be done to the hard disk cannot be placed in a read-only partition, which the root must be made after the hacks are installed. On the other hand, tserver does not require writing to disk, so it can reside somewhere other than /var, if you choose.

    Quote Originally Posted by presidentsdad View Post
    I'm getting a .01MB/sec through put. It's taking about 12 hours for a 30 minute show.
    Check your MTU on your PC. Did you recently install a VPN solution, by any chance? Try transferring in single socket mode. Does it make a difference? Is it possible there is a duplex mismatch between one (or both!) of the two hosts and the device to which it is attached? If your switch or hub is half duplex and the host full duplex (or vice-versa in the case of the switch), then large file trransfers will slow to a crawl. Very small transfers will be fairly normal, but any large stream will bring the link to its knees. I have seen this a number of times in our client's networks, and we once had one in our network. Large FTP sessions would crawl at a few dozen kilobits / second. when the mismatch was fixed, the FTP sessions can run in excess of 75Mbps between UNIX workstations.
    Having trouble with TyTool? Try TyTool Documentation
    Need to hack an S3 / THD? Try S3 Hacking Script

  2. #617
    Join Date
    Dec 2004
    Posts
    831

    Slow transfers

    Quote Originally Posted by SithLord View Post
    Try making sure the TIVO isn't doing anything, like recording something, for example.
    There is of course a performace hit for recording, and especially if the TiVo is recording two video streams, but even then the slow down shouldn't be anywhere nearly as bad as reported by the OP.

    Quote Originally Posted by SithLord View Post
    I'm not saying this is the cause of the slowness, but oftentimes I get slower speeds when the TIVO is busy doing something else--not always, but often enough.
    Ordinarily the unit is always recording, and still it will usually manage better than 2MBps. Placing the unit in standby will increase the transfer rate, but anything below 1MBps is not due to the unit being busy, unless something extraordinary is taking place. Remeber, instantaneously all transfers occur at line rate. The overall reduction in transfer rate is due to pauses in the stream while the unit handles whatever, but real-time processes cannot be taking up anything like half of the processor time, or else they themselves would begin to suffer, and you would see problems in the video output. Looking at my Series I TiVo's processor stats, I see it is rarely less than 90% idle, and never less than 80% idle with no transfer going on. After starting a transfer at 2.6MBps, that number drops to between 10 and 15%. This is normal, because tserver is a low priority thread but it always has processing to do. If the real-time and high priority processes were to eat up half the processor time, the transfer rate would drop to about 1.5MBps. 'Much more than that, and you would start to see artifacts in the video.

    Quote Originally Posted by SithLord View Post
    When I put it in standby after tuning to the music channels, it often "fixes" things.
    Hoiw "broke" were they prior to getting "fixed"?
    Having trouble with TyTool? Try TyTool Documentation
    Need to hack an S3 / THD? Try S3 Hacking Script

  3. #618
    Join Date
    Dec 2004
    Posts
    831

    Slow transfers

    Quote Originally Posted by krx View Post
    I've noticed that if a transfer is slowed down for any reason (other processes running on the PC, or network traffic) then the transfer rate never seems to recover much from its minimum, even when the interfering process goes away, and that this carries over from one file transfer to the next..
    I have never seen this. In fact, I have seen quite the opposite. Occasionally something will cause a momentary slowdown in the transfer rate, but it rises again in a few moments.

    Quote Originally Posted by krx View Post
    This is just speculation, but it could be that something is causing a momentary but severe slowdown at the end of processing your first file, and the second file is being affected by this.
    At the networking layers, this should not be possible. The TCP protocol dynamically adjusts its transfer rate to meet the capabilities of the lower network layers. If the network is congested, TCP will ease back on its transfers. If the network is wide open, TCP will ease forward. Your home network should not be congested, really, unless you have a very unusual home network.

    Above the networking layers, there should not be any "memory" of previous activity, and other than CPU utilization and (in this case) disk performance, nothing above the TCP layer controls transfer rates.

    Quote Originally Posted by krx View Post
    My guess is that a burst of intensive activity on the TiVo would have a similar effect, but this is more difficult to test.
    First of all, as I mentioned, a momentary congestion of resources on either machine should not result in slow responses after the congestion is cleared. Secondly, it isn't difficult at all to monitor the TiVo's performance. Just load top on the TiVo and run top at the bash prompt. I have it up right now.
    Having trouble with TyTool? Try TyTool Documentation
    Need to hack an S3 / THD? Try S3 Hacking Script

  4. #619
    Join Date
    Dec 2004
    Posts
    831
    Quote Originally Posted by Growler View Post
    I just can't see (understand) in this how it is getting the TSERVER file in to the var/hack directory on my tivo. I was expecting something like a copy command or something from where it is stored on my PC.
    [/B]
    From those directions you never will. You have to FTP tserver over to the directory you created. For this you will have had to put ftpd on the TiVo at the same time you hacked it to allow telnet. You will also have had to tell the TiVo to run ftpd in either rc.sysinit or rc.sysinit.author, or else run ftpd manually from your telnet session before attempting the FTP. Be sure to transfer in binary mode.
    Having trouble with TyTool? Try TyTool Documentation
    Need to hack an S3 / THD? Try S3 Hacking Script

  5. #620
    Join Date
    Nov 2004
    Location
    Gurnee, IL
    Posts
    2,384
    Quote Originally Posted by lrhorer View Post
    Ordinarily the unit is always recording, and still it will usually manage better than 2MBps.
    With stock drivers? I've never seen that speed unless I tune the tuners to non-existent (or music) channels. And you certainly won't see that on an S2.5.
    anything below 1MBps is not due to the unit being busy, unless something extraordinary is taking place. Remeber, instantaneously all transfers occur at line rate. The overall reduction in transfer rate is due to pauses in the stream while the unit handles whatever, but real-time processes cannot be taking up anything like half of the processor time, or else they themselves would begin to suffer,
    Not sure where to begin here. Stock drivers, as I said, are USB1.1. And clearly buffering/recording makes a huge difference or else tuning them to non-existent channels wouldn't make a difference.
    --
    Christopher D. Heer
    Quote Originally Posted by Oscar Wilde
    Perhaps, after all, America never has been discovered. I myself would say that it had merely been detected.

  6. #621
    Join Date
    Nov 2004
    Location
    Gurnee, IL
    Posts
    2,384
    Quote Originally Posted by lrhorer View Post
    At the networking layers, this should not be possible. The TCP protocol dynamically adjusts its transfer rate to meet the capabilities of the lower network layers. If the network is congested, TCP will ease back on its transfers. If the network is wide open, TCP will ease forward. Your home network should not be congested, really, unless you have a very unusual home network.
    Not exactly.

    TCP doesn't know if the network is congested per se. All it knows is whether it's getting ACKs. TCP will ramp up its window size (to a point) -- in other words, it will send packets without waiting for an ack on the previous packet. But if it stops getting acks (or they time out) the window will shrink back down.

    TCP doesn't adjust anything to meet capabilities of the various lower-level networks, other than setting MTU to the lowest MTU in the path using path-mtu-discovery in order to avoid fragmentation.

    But I agree that I wouldn't expect to see transfers slow down and stay that slow based on a network issue in a home network unless wireless is involved.
    Above the networking layers, there should not be any "memory" of previous activity, and other than CPU utilization and (in this case) disk performance, nothing above the TCP layer controls transfer rates.
    Perhaps not, but there's nothing stopping the higher layers from throttling things.
    --
    Christopher D. Heer
    Quote Originally Posted by Oscar Wilde
    Perhaps, after all, America never has been discovered. I myself would say that it had merely been detected.

  7. #622
    Join Date
    Sep 2004
    Posts
    240
    I was searching here, and using other methods to answer the following question, but was unable to locate an answer:


    Is there a command line to generate a keyfile ?

  8. #623
    Join Date
    Aug 2005
    Location
    Hendersonville, TN (just outside of Nashville)
    Posts
    44

    Talking

    Quote Originally Posted by lrhorer View Post
    From those directions you never will. You have to FTP tserver over to the directory you created. For this you will have had to put ftpd on the TiVo at the same time you hacked it to allow telnet. You will also have had to tell the TiVo to run ftpd in either rc.sysinit or rc.sysinit.author, or else run ftpd manually from your telnet session before attempting the FTP. Be sure to transfer in binary mode.

    Thanks for the tip. It did not look right. I went to the link on the bottom of your reply http://fletchergeek.com/TyTool/Getting_Started.html

    And now it's working- THANKS.

    I am using a wired usb 2.0 ethernet adapter. Do you know a rule of thumb to verify transfer rates are in the ballpark?

    Thanks for your help, lrhorer!

  9. #624
    Join Date
    Aug 2005
    Location
    Hendersonville, TN (just outside of Nashville)
    Posts
    44

    Jerky Choppy Playback

    I was thrilled with the first extraction for the HR10-250. It was a standard definition movie off SciFi. I had Tytool set to create an .mpg. The transfer seemed pretty quick. I went to play it on Windows Media player, but playback was choppy or jerky.

    Reading posts some people feel this is due to PC horsepower, but I don't see how that's my issue. I play games online and have a fairly up-to-date computer.

    3.0 GHz
    3 GB ram
    ATI Radeon X850 XT PE

    Is it possible I should have set Tytool to create a different file type?

  10. #625
    Join Date
    Nov 2004
    Location
    Gurnee, IL
    Posts
    2,384
    Generating a different file type wouldn't have changed anything.

    The main issue is that Windows Media Player is crap. A sub-issue is that all SD (and most HD) stuff is interlaced, but your PC has a progressive display. The default method of deinterlacing is, well, awful.

    You have a couple of options:
    • Re-encode the video after running it through a decomb or ivtc process, assuming it was originally sourced from film
    • Re-encode the video and deinterlace (deinterlacing never looks very good and you lose half of the temporal information)
    • Install Media Player Classic and ffdshow and use ffdshow's on-the-fly deinterlacing filters
    I'd do the third if I were you, but understand that interlaced material is only going to look "right" on a system designed to play interlaced material.
    --
    Christopher D. Heer
    Quote Originally Posted by Oscar Wilde
    Perhaps, after all, America never has been discovered. I myself would say that it had merely been detected.

  11. #626
    Join Date
    Dec 2004
    Posts
    831

    Slow Network

    Quote Originally Posted by cheer View Post
    With stock drivers? I've never seen that speed unless I tune the tuners to non-existent (or music) channels. And you certainly won't see that on an S2.5.Not sure where to begin here. Stock drivers, as I said, are USB1.1.
    I have a Series I and it is not a DTiVo, so tuning it (or rather, the cable box) to any particular channel has no effect. I'm using a CacheCard, so the term "stock drivers" isn't really relevant. I don't know from firsthand experience what SA Series II or DTiVo Series I or II users normally get, but I do know I have seen other users post speeds in excess of mine, which regularly sit between 2.2 and 2.7 MBps.

    Quote Originally Posted by cheer View Post
    And clearly buffering/recording makes a huge difference or else tuning them to non-existent channels wouldn't make a difference.
    There's "a difference", as in "measurable", and "a huge difference" as in "a factor of 10 or 100". I don't know what the typical loading on a Series II or a DTiVo is, but it should not in any case be anything like 90% when recording, even on 2 channels and watching a recorded movie, or else, as I say, one would begin to run into performance issues. Of course, the hard drive could be a diferent issue, and writing two 6mbps streams and reading a third could be taxing the drive controller a bit, but even it cannot be overrunning its buffers or it, too would cause performance issues. None of these issues, however, should drop the transfer rate to .01MBps, which was my point. Dropping it 50%, sure. 'By 99.6%, no.
    Having trouble with TyTool? Try TyTool Documentation
    Need to hack an S3 / THD? Try S3 Hacking Script

  12. #627
    Join Date
    Dec 2004
    Posts
    831

    Slow Network

    Quote Originally Posted by cheer View Post
    Not exactly.

    TCP doesn't know if the network is congested per se. All it knows is whether it's getting ACKs. TCP will ramp up its window size (to a point) -- in other words, it will send packets without waiting for an ack on the previous packet. But if it stops getting acks (or they time out) the window will shrink back down.
    That is correct. It also effectively results in the same thing. Because it's window size is reduced, it is only sending, say, 5KB bursts rather than 32KB bursts but still waiting a significant amount of time for the ack. Remember, too, it only transmits to the end of the window, which means if it only receives the ack for the first packet, it only sends a single packet in return - assuming the packets are all MTU in length, of course. The main point is, however, a 32K window is transmitted in only a bit over 2.6ms across a 100M pipe, at which point the TCP transmitter will wait, perhaps for several milliseconds, for the Rx host to send its acks. A smaller window, means the burst is consequently smaller, while the ack time is constant (otherwise TCP will increase its window size until it reaches the maximum allowed by the Rx buffers), so the average data rate is lower.

    Quote Originally Posted by cheer View Post
    TCP doesn't adjust anything to meet capabilities of the various lower-level networks, other than setting MTU to the lowest MTU in the path using path-mtu-discovery in order to avoid fragmentation.
    'Directly based upon network parameters? No. Indirectly, it does, however. The net effect of lowering the window size is a lighter overall usage of network resources, especially when averaged over a large number of simultaneous TCP connections.

    Quote Originally Posted by cheer View Post
    Perhaps not, but there's nothing stopping the higher layers from throttling things.
    'Not in general, but I seriously doubt tserver uses anything above the TCP layer as far as networking is concerned. If the network is eliminated (which it is definitely not in this case - I strongly suspect a duplex mismatch), then it has to be a hardware or software issue on one of the hosts.
    Having trouble with TyTool? Try TyTool Documentation
    Need to hack an S3 / THD? Try S3 Hacking Script

  13. #628
    Join Date
    Dec 2004
    Posts
    831

    Slow Network

    Quote Originally Posted by Growler View Post
    Thanks for the tip. It did not look right. I went to the link on the bottom of your reply http://fletchergeek.com/TyTool/Getting_Started.html

    And now it's working- THANKS.
    I'm glad the docs were of help. I need to update them for release 10, but I am just swamped right now.

    Quote Originally Posted by Growler View Post
    I am using a wired usb 2.0 ethernet adapter. Do you know a rule of thumb to verify transfer rates are in the ballpark?
    I'm using aCacheCard on a Series I, so I'm not the best benchmark, but I typically get between 2.2 and 2.8 MBps, or about 15 - 22 Mbps. Since I usually start a large batch and then go to the office or to sleep, it really doesn't matter much to me, however.

    Quote Originally Posted by Growler View Post
    Thanks for your help, lrhorer!
    Da nada.
    Having trouble with TyTool? Try TyTool Documentation
    Need to hack an S3 / THD? Try S3 Hacking Script

  14. #629
    Join Date
    Nov 2004
    Location
    Gurnee, IL
    Posts
    2,384
    Quote Originally Posted by lrhorer View Post
    I have a Series I and it is not a DTiVo, so tuning it (or rather, the cable box) to any particular channel has no effect. I'm using a CacheCard, so the term "stock drivers" isn't really relevant. I don't know from firsthand experience what SA Series II or DTiVo Series I or II users normally get, but I do know I have seen other users post speeds in excess of mine, which regularly sit between 2.2 and 2.7 MBps.
    Jmasterman, who originally started this conversation, is using a DTivo w/6.2 and USB->Ethernet. So "stock drivers" means USB 1.1, and slower performance than you've seen.
    There's "a difference", as in "measurable", and "a huge difference" as in "a factor of 10 or 100".
    A semantics game, I guess. On my S2 DTivo w/Jamie's backported drivers and a kernel with netfilter disabled, I normally get between 1.8 and 2.5 megabytes/sec. Tune both tuners to non-existent channels and I crank over 4 megabytes/sec. So you tell me.
    --
    Christopher D. Heer
    Quote Originally Posted by Oscar Wilde
    Perhaps, after all, America never has been discovered. I myself would say that it had merely been detected.

  15. #630
    Join Date
    Aug 2005
    Location
    Hendersonville, TN (just outside of Nashville)
    Posts
    44
    Quote Originally Posted by Growler View Post
    I was thrilled with the first extraction for the HR10-250. It was a standard definition movie off SciFi. I had Tytool set to create an .mpg. The transfer seemed pretty quick. I went to play it on Windows Media player, but playback was choppy or jerky.
    Quote Originally Posted by cheer View Post
    Generating a different file type wouldn't have changed anything.

    The main issue is that Windows Media Player is crap. A sub-issue is that all SD (and most HD) stuff is interlaced, but your PC has a progressive display. The default method of deinterlacing is, well, awful.

    You have a couple of options:
    • Re-encode the video after running it through a decomb or ivtc process, assuming it was originally sourced from film
    • Re-encode the video and deinterlace (deinterlacing never looks very good and you lose half of the temporal information)
    • Install Media Player Classic and ffdshow and use ffdshow's on-the-fly deinterlacing filters
    I'd do the third if I were you, but understand that interlaced material is only going to look "right" on a system designed to play interlaced material.
    Thanks for the info. I understand (I think).

    My goal is to take a file from the HD D*Tivo and create a file (with minimal quality loss) that can be edited within my video editing program.

    I have played with the GOP editor, but it just seems like I could do more with my Sony Vegas software. This is where I would like to do my edits and then use my authoring program to put it on dvd.

    I took the mpg from tytool that had choppy playback. I put it in Vegas, edited it, and made a new mpg. It worked fine, except a noticed loss in picture clarity.

    Is the issue that there is virtually no quality loss when working within TyTool?
    Last edited by Growler; 08-22-2006 at 05:14 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •