Page 9 of 84 FirstFirst ... 78910111959 ... LastLast
Results 121 to 135 of 1257

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

  1. #121
    Join Date
    Feb 2004
    Posts
    298
    Goes to show the additional amount of resources SD versus HD requires.

    But I still have not been able to create a DVD viewable on any of my players. I'm working on that. But yes, new editing hardware is required.
    5 Series 2 DTivos: upgraded to 120GB, 6.2, SuperPatched, tserver, mfs_ftp, tivowebplus, endpadplus, bufferhack, MRV, HMO
    1 HR10-250: upgraded to 400GB, tserver, mfs_ftp, tivowebplus, endpadplus, bufferhack
    2 R15s: Just playing
    2 R10's PROMs in house but not installed yet (sitting on the bench)
    JAVAHMO Server 2.4/EtiVo Server 1.0.1924.2

  2. #122
    Join Date
    Dec 2005
    Posts
    1
    Keep getting this error and does not make MPEG What am I doing wrong any suggestions
    Failed to get the first 10 initial chunks

  3. #123
    Join Date
    Nov 2004
    Location
    Gurnee, IL
    Posts
    2,384
    Asked and answered, many many times. Please learn to search.

    Your videos are encrypted.
    --
    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.

  4. #124
    Join Date
    Sep 2003
    Posts
    122

    Short key file

    Thanks so much for this great app....I downloaded several episodes of The Dog Whisperer and processed key files for them. The key file for one of them is short - about 4 meg from a 800 meg .ty file. It produced no errors and all the other key files are fine - about 39-40meg. I re-downloaded the file and tried again with the same results. Any idea what would cause this? Here is the .txt file. Using 10 rel 4 on Win XP Pro

    Detected Tivo Type: HDTivo
    Detected Audio Stream Type: MPEG Layer II
    Final standardAudioSize = 592
    Final standardFrameLength = 576
    Final standardAudioDiff = 2160 or 00:00:00.024
    First Video PTS: 00:02:56.811
    ......... 100......... 200......... 300......... 400......... 500

    ......... 600..

    DiffTime = 5.108000 (5108) == 0.085133 Minutes

    total = 81264640 (77 MB)



    Done with 'C:\DTivo\The Dog Whisperer-Caper and Julius.ty'...
    HR10-250 250m,3.1.5f,eth,ftpd,tivowebplus,fakecall,endpadplus

  5. #125
    Join Date
    Sep 2005
    Posts
    5
    A few more notes on the error I got below... it happened using the old Muxing command... the New Format Mux does not fail with GOPEdited files, but the resulting mpeg has no audio (muxing files with Dolby 5.1 sound). The "Fill AC3 holes" checkbox had no effect.

    I tried 9r18HD and the standard and the New Format muxes work as expected with edited files. I guess I'll stick with 9r18HD, but I am curious why 10r4 has these issues.

    Quote Originally Posted by josejrp
    I always get the following error in TyTool when multiplexing various edited movies with GOPEditor from HBO-HD (the only extractions I've tried):

    "15600.........15700.........15800.........15900.........16000
    .........16100......ERROR: Out of memory getting a new MuxNode buffer!"

    My edit was just a GOP start cut to FAE end cut in the beggining to trim the stuff before the movie.

    If I don't edit the movies, the multiplexing via TyTool works correctly. I searched for this error, but only found a suggestion to trim the .ty file for a few frames using TyFileSplit before running it through GOPEditor, which I did with the same result. My PC has 1GB of RAM, and I've tried increasing the virtual memory to 2GBs to no avail. Any suggestions?

  6. #126
    Join Date
    Oct 2001
    Posts
    242

    Unhappy

    Quote Originally Posted by tiivohoe
    Thanks so much for this great app....I downloaded several episodes of The Dog Whisperer and processed key files for them. The key file for one of them is short - about 4 meg from a 800 meg .ty file. It produced no errors and all the other key files are fine - about 39-40meg. I re-downloaded the file and tried again with the same results. Any idea what would cause this? Here is the .txt file. Using 10 rel 4 on Win XP Pro

    Detected Tivo Type: HDTivo
    Detected Audio Stream Type: MPEG Layer II
    Final standardAudioSize = 592
    Final standardFrameLength = 576
    Final standardAudioDiff = 2160 or 00:00:00.024
    First Video PTS: 00:02:56.811
    ......... 100......... 200......... 300......... 400......... 500

    ......... 600..

    DiffTime = 5.108000 (5108) == 0.085133 Minutes

    total = 81264640 (77 MB)



    Done with 'C:\DTivo\The Dog Whisperer-Caper and Julius.ty'...
    Tiivohoe,

    got the same problem. not sure about it and woyuld like to send JD some snippets if he wants.

  7. #127
    Join Date
    Jan 2006
    Posts
    12
    Quote Originally Posted by Jamie
    The call to set the priority is still there. I've verified that it works on an S2, but I don't have an S1 to test with.

    To verify the scheduling priority, find the tserver PID with ps or top, then run "getpri PID", where PID is the tserver PID. It should show "fifo 1". getpri is in AlphaWolf's all-in-one package, so many of you will already have it.

    The tserver code sets the policy to "FIFO" and the priority to 1. This is lower than the realtime tivo processes, though it is still a realtime priority and is higher than normal timesharing processes (shells, etc).

    The NowShowing list generation is fairly disk intensive and probably causes a lot of head seeking, since the data is scattered about in MFS. If the skipping only occurs when you're refreshing the show list, then I suppose that could be the cause. If the skipping occurs during stream transfers, then I don't think this is the issue.

    The low level steam export code has a rate throttle option to sleep a small time interval between "chunks" to reduce the load on the tivo. tserver doesn't currently use it, but it would be easy to add a command line option to tserver to allow it to be set. Here's the description from the mfs_uberexport usage string:
    Code:
           -r <ms>         Rate control (throttle)
                                   -'ve  : no delay (default)
                                   0     : sched_yield() between chunks
                                   +'ve  : # of ms to delay between chunks
    I could add the same command line option to tserver, if the extra control on the "throttle" would help. Right now tserver runs at full throttle with no rate limiting.

    I'm wondering if the disk just doesn't have enough bandwith to support recording two HD live buffers, playing back, and streaming a HD stream to the network all at once. Somebody who can recall the typical HD stream bit rates can do the math and compare against typical disk specs.
    The tserver priority check did return "fifo 1". This issue happens when I'm transferring a stream to my PC and watching live tv (no recordings other than the live channel for pause live tv) so it doesn't seem like the situation is very taxing. As soon as I shutdown tytools/tserver, the problem goes away.

  8. #128
    Join Date
    Jun 2002
    Location
    Was Frozen North now Sunny South
    Posts
    351
    Quote Originally Posted by Wolffpack
    ...The playback of MPEG files is choppy simply because that PC can't keep up...
    Wolffpack what are you using to play-back your files? I could never get HD files to play-back smoothly on even my 3.0GHz P4 until I downloaded the Elecard codec pack and pointed it at Media Player Classic. This setup plays anything MPEG2 that I throw at it smoothly and with perfect lipsync (which is what I needed to find a solution for) including HD Transport streams (non-Tivo).
    Philips Standalone v3.01 w/2-80G drives and Tivonet.

  9. #129
    Join Date
    Aug 2004
    Posts
    4,075
    Quote Originally Posted by Goob The Noob
    The tserver priority check did return "fifo 1". This issue happens when I'm transferring a stream to my PC and watching live tv (no recordings other than the live channel for pause live tv) so it doesn't seem like the situation is very taxing. As soon as I shutdown tytools/tserver, the problem goes away.
    I've attached a test build of tserver that includes the -r option to throttle the upload rate. There are a couple of things you can try:
    • Try running tserver with the -n option. That turns off the "Lowest PriorityFix". The should cause the process to run at the normal timesharing priority (not realtime). You can verify this with getpri; it should show "ts 0". Counterintuitively, on a series2, the "Lowest PriorityFix" actually raises the priority to the lowest realtime priority. Time share priority levels are all below realtime.
    • Try running tserver with "-r 50". This adds a 50 millisecond delay between "chunks" (128MB). That works out to ~ 1/2 second per MB, or 7 minutes per GB. Your transfers will be slower, but the impact on the tivo software should be less. If it solves your problem, but transfers are too slow for you, trying reducing 50 to a smaller value.
    Please report back whether this helps. If it does, I'll make sure it's in the next public release of mfs-utils.

  10. #130
    Join Date
    Jan 2006
    Posts
    12
    Quote Originally Posted by Jamie
    I've attached a test build of tserver that includes the -r option to throttle the upload rate. There are a couple of things you can try:
    • Try running tserver with the -n option. That turns off the "Lowest PriorityFix". The should cause the process to run at the normal timesharing priority (not realtime). You can verify this with getpri; it should show "ts 0". Counterintuitively, on a series2, the "Lowest PriorityFix" actually raises the priority to the lowest realtime priority. Time share priority levels are all below realtime.
    • Try running tserver with "-r 50". This adds a 50 millisecond delay between "chunks" (128MB). That works out to ~ 1/2 second per MB, or 7 minutes per GB. Your transfers will be slower, but the impact on the tivo software should be less. If it solves your problem, but transfers are too slow for you, trying reducing 50 to a smaller value.
    Please report back whether this helps. If it does, I'll make sure it's in the next public release of mfs-utils.
    When I run this version of tserver, I get "Bus error". This is with and without the -n option.

  11. #131
    Join Date
    Sep 2002
    Posts
    110
    Quote Originally Posted by Goob The Noob
    When I run this version of tserver, I get "Bus error". This is with and without the -n option.
    Make sure that you transfered the file in binary mode. This can be done by typing in "bin" at the ftp prompt.

  12. #132
    Join Date
    Jan 2006
    Posts
    12
    Quote Originally Posted by Rowan
    Make sure that you transfered the file in binary mode. This can be done by typing in "bin" at the ftp prompt.
    I used WS_FTP and specified binary mode. I also tried the command line ftp and made sure I used binary mode. Same results : Bus error
    Last edited by Goob The Noob; 01-30-2006 at 05:30 PM.

  13. #133
    Join Date
    Aug 2004
    Posts
    4,075
    Quote Originally Posted by Goob The Noob
    When I run this version of tserver, I get "Bus error". This is with and without the -n option.
    Hum. It works for me on 7.2.1. I don't have a 3.1.5 system to test with.

    I switched cross compilers to gcc 3.3.4 recently. It's possible there is compatibility issue with that compiler and the shared libraries in 3.1.5x. I've recompiled here with gcc 3.0, the x-compiler I've always used in the past. Let me know if it behaves better.

    I sent you a PM. We can work through this privately rather than clutter the thread further. We'll summarize any final conclusions.

    {edit: looks like it wasn't a problem with the compiler at all, but a problem in uncompressing the .bz2 file -- beware of ALZip. It seems to have the same "Smart CR/LF conversion" problem that WinZip has.}
    Last edited by Jamie; 01-30-2006 at 09:50 PM.

  14. #134
    Join Date
    Jan 2002
    Posts
    4,809
    Quote Originally Posted by Wolffpack
    But I still have not been able to create a DVD viewable on any of my players. I'm working on that. But yes, new editing hardware is required.
    Without en mass re-encoding you are going to continue to have problems. An MPEG player, hardware or software and this includes DVD players, have buffers in them. Buffers for the video, for the audio, for the CC and so on.

    The resolution of an HD stream are SO MUCH LARGER than that of an SD stream. Couple that with the fact that current DVD players are solely an SD device you have no real hope. This of it as a truck versus a Yugo car. Both move "people" but I wouldn't try to move my house in the Yugo. What can I say, size matters.

    You are either going to have to re-encode the HD stream into an SD stream for DVD playback, get an HTPC that is beefy enough to handle it, get one of the new rather experimental HD ready DVD players, or ...

    This TyTool thread is really the right place to ask such question. You should look at HD specific threads here and other sites for discussions of DVD players that can play back HD material from a DVD directly.

    --jdiner

  15. #135
    Join Date
    Jan 2002
    Posts
    4,809
    Quote Originally Posted by tiivohoe
    Thanks so much for this great app....
    Your welcome.

    I downloaded several episodes of The Dog Whisperer and processed key files for them. The key file for one of them is short - about 4 meg from a 800 meg .ty file. It produced no errors and all the other key files are fine - about 39-40meg.
    Hummm. Thought I had fixed that. There was a check that seemed necessary for HD streams that wasn't in the end. So I had removed it. I will verify that it has been removed. If not it should work in 10r5.

    --jdiner

Posting Permissions

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