Problems processing .ty files after killhdinitrd

[NoCalME]

I just completed applying the killhdinitrd process to my SD-DVR80 running 3.1.1e obtained from my brother's SD-DVR80. I have FTP, extraction, and encryption disabled and everything appears to be working fine. However, I'm having problems processing .ty files to .mpg to their full length.

The .ty file extracts okay with mfs_ftp and the file size is reported correctly. But when I use Vsplit-mac-3.03b2 or TyTool to convert to .mpg, they only process up to roughly 510 mb. I've tried files <1 GB, >1 GB, DD 5.1, Pro Logic--all with the same results. The only exception are smaller test programs I record that are less than 510 mb, which seem to process okay.

As I watch the tydemux output from the Terminal window, the .ty file processing is progressing at its normal speed with the .......... 100 ............ 200 ........... 300, and so on. But when the processing reaches the ~510 mb point, the processing speeds up rapidly until it gets to the end. When I try to use ffmpegX, it gives me a warning message that "Chunk 4609 is out of alignment with 16 bytes". When I use TyTool on the PC, I select VOB-Mux File and receive the following when the processing is complete:
DiffTime = 228.939011 (228939) = = 3.815650 Minutes

I've attached outputs from Vsplit and ffmpegX sessions for reference.

So my hacking progression has been:
*************************************************************
Sleepers hacked TiVo running my original 3.1.1c software --> everything worked okay, no audio sync problems, files processed completely

Sleepers-to-killhdinitrd, still with my original 3.1.1c software --> everthing worked okay for a while, then the partial processing problem outlined above began

killhdinitrd running my brother's 3.1.1e image --> first file extracted had problem outlined above
*************************************************************

I assumed I must have screwed something up while applying killhdinitrd, so I figured eliminating the usage of Sleepers and going strictly killhdinitrd would solve the problem--not. :mad:

The strange thing is I hacked my brother's SD-DVR80 over Christmas using only the Sleeper CD(I know better now) and he's experiencing the same issue. The first 5 or so movies he extracted, everything worked perfectly. But then audio sync problems started to occur. About a 1/4 of the movies he extracted after the 5th one had audio sync problems. The audio sync problem continued to progress until after a Clear & Delete Everything resulted in the same exact problem I stated above.

Any idea what the heck could be the problem? Does it make any sense if the problem is hardware related? Could there be a problem with the 3.1.1e software from my brother's TiVo? I have went over all my steps 2 and 3 times and it seems like I'm doing everything correct. All of the programs play fine on the Tivo without any audio sync whatsoever. :confused:

[eastwind]

Since I don't see how you extracted the shows, this is a guess. You extracted the shows with mfs_ftp and have an old version of the mfs_* binary (export or stream--I forget) that plugs some priority message into the stream at the 512 mb mark (when it jumps to another part). If this sounds right you can fix the short processing problem by updating the mfs_* binaries or by using TyTool to do the extracting (since you're processing with it anyway). BTW, typrocess is a tool from a different studio (are you using that also?).

ew

[NoCalME]

I had been extracting using mfs_ftp, but I'm positive I have the latest S2 binaries; downloaded from the links in the mfs_ftp sticky thread today.

I decided to load up my virgin 3.1.1c image and hack it instead of using my brother's 3.1.1e thinking it might be the culprit. After completing killhdinitrd and loading up the hacks, I recorded a new program and extracted with mfs_ftp. The extracted .ty file processes in full using vsplit-mac-3.03b2 on my iMac, but the audio sync is horrible after making any sort of cut.

Since I hadn't extracted any .ty files yet with TyTool, I went ahead and followed eastwind's advice. The file does process in full using TyTool, but I get this final output at the end after doing a VOB-MUX: "DiffTime = 322.043015 (322043) = = 5.367384 Minutes" . . .which would seem to indicate there are some major problems with this .ty file. I tried recording another program and got the same results.

I'm beginning to think this is a hardware issue and there's a problem with my DirecTiVo. :( I have triple checked my hacking steps, re-did killhdinitrd 3 times, and still this problem persists. :confused:

Unless anyone has any other suggestions, I'm going to stop by Circuit City tomorrow and pick up another SD-DVR80, swap drives, and hope this fixes the problem.

[psxboy]

The file does process in full using TyTool, but I get this final output at the end after doing a VOB-MUX: "DiffTime = 322.043015 (322043) = = 5.367384 Minutes" . . .which would seem to indicate there are some major problems with this .ty file. I tried recording another program and got the same results.
Maybe you could explain why you think this is a problem? Tytool is merely telling you how long it took to VOB-MUX the file, not how long the final recording is. (Which is what I think you think it means.)

I'm beginning to think this is a hardware issue and there's a problem with my DirecTiVo. :( I have triple checked my hacking steps, re-did killhdinitrd 3 times, and still this problem persists. :confused:
It's not a hardware issue. And killhdinitrd has nothing to do with the problem you're having. If your ty files are bailing out at the ~512MB mark, it's the problem identified earlier by Eastwind. Try extracting as TMF instead of TY. Or, you can use tserver (part of TyTool) to extract the recordings - it isn't susceptable to that particular problem. Also, using TyTool to extract, edit, and mux has netted me perfect recordings with no audio sync issues every time in the past. You may want to try that route instead.

-psxboy

[eastwind]

The extracted .ty file processes in full using vsplit-mac-3.03b2 on my iMac, but the audio sync is horrible after making any sort of cut.

Since I hadn't extracted any .ty files yet with TyTool, I went ahead and followed eastwind's advice. The file does process in full using TyTool, but I get this final output at the end after doing a VOB-MUX: "DiffTime = 322.043015 (322043) = = 5.367384 Minutes" . . .which would seem to indicate there are some major problems with this .ty file.
The DiffTime message is for information only. Tells you how long TyTool took for the work. Did you play the file in PowerDVD or WinDVD to test it? Should be able to play with either of those or if you complete the process (Create IFO files/dirs) and burn it onto DVD and play it in a STB player. (Don't recommend using WMP to play the file as it's MPEG2 codec is suspect and might show audio sync problems.) Not sure what to play it with on a Mac...

ew

[Jamie]

I'm positive I have the latest S2 binaries; downloaded from the links in the mfs_ftp sticky thread today.Which s2 binaries are you using? The s2bins.tar linked from the mfs_ftp sticky thread are known to have the "Priority set string in stream" problem. The bcc compiled binaries Riley linked to here (http://www.dealdatabase.com/forum/showthread.php?p=169896#post169896) can still mix other error messages into the data stream.

IMHO, you'd be best off using the binaries here (http://www.dealdatabase.com/forum/showthread.php?t=39487). You probably *don't* want the mfs_ftp patch there, unless you want to live on the bleeding edge, but the binaries have been in use by many for several months now and are generally considered reliable, to my knowledge.

[NoCalME]

Tytool is merely telling you how long it took to VOB-MUX the file, not how long the final recording is.My bad. Thank you for correcting me. I actually thought the DiffTime meant the audio was out of sync by this amount, so I was way off.
It's not a hardware issue. And killhdinitrd has nothing to do with the problem you're having. If your ty files are bailing out at the ~512MB mark, it's the problem identified earlier by Eastwind. . . Or, you can use tserver (part of TyTool) to extract the recordings - it isn't susceptable to that particular problem. Also, using TyTool to extract, edit, and mux has netted me perfect recordings with no audio sync issues every time in the past. You may want to try that route instead.

I've tried extracting via TyTool instead of using mfs_ftp as Eastwind suggested. I used an all-TyTool process to extract and VOB-MUX and the results were the same as when I used mfs_ftp, then processed with TyTool or vsplit-mac-3.03b2. The file processed in its entirety, but the audio sync is way off.

When I was running 3.1.1e, the files would croak at ~512 mb. Thinking maybe there was a problem with the 3.1.1e image, I hacked my 3.1.1c image. With 3.1.1c hacked, the files now process completely, but audio sync is hosed. I used the same exact hack binaries and files to hack 3.1.1c & 3.1.1e. I agree that killhdinitrd has nothing to do with my problem. I only repeated the killhdinitrd process thinking I did something wrong.

Which s2 binaries are you using? The s2bins.tar linked from the mfs_ftp sticky thread are known to have the "Priority set string in stream" problem. The bcc compiled binaries Riley linked to here can still mix other error messages into the data stream.

IMHO, you'd be best off using the binaries here. You probably *don't* want the mfs_ftp patch there, unless you want to live on the bleeding edge, but the binaries have been in use by many for several months now and are generally considered reliable, to my knowledge.I am using the s2bins.tar binaries linked on the sticky thread, so I'll switch over to the ones you referenced. However, this still doesn't explain why I still see the audio sync problem when I use tserver to extract the files?

[NoCalME]

Replacing the s2bins.tar mfs_ftp binaries with the ones Jamie link solved the problem.:) Apparently the s2bins.tar binaries were affecting files extracted with TyTool's tserver as well. After replacing the s2bins.tar binaries and rebooting, all is good.

Thanks to all that responded.