If you have the 5k freeze followed by sync problem this tool may help...

[Jeff D]

I've created a simple (and yet, still crappy) tool to fix the problem where the replayTV has recorded bad mpeg. The source of the problem is the replay had screwed up the audio PTS values, they acutally jump back in time 2 seconds. This causes the replayTV to freeze the video and from there on out the audio is 2 seconds behind the video.

If you have the problem this tool can help you play the file correctly. I know a few of you have just deleted the problem shows. =(

You'll need to use DVArchive to extract the stream then use this tool to fix the problem file. You can then serve the file back to the replayTV using DVArchive and the show should play correctly.

I've tested with 4 files, only one was a show I recorded. The other three shows have come from other AVS members (thanks).

Let me know if you have any problems. Please don't try to use this on a drive that doesn't have enough space for a complete copy of the show you are trying to fix (I left a bit of error checking out....)

[dmk11]

would this "mess up" an mpeg that doesn't have the problem?

[Jeff D]

No this shouldn't mess up a mpeg. It won't do anything to the source file. And if it doesn't detect the audio timestamp back-in-time problem the source and destination files should match bit for bit.

[AJStone]

Jeff, thanks for the tool to fix the sync problem. This is the first time that I recall my 5040 ever showing this behavior. Looks like it happen 26:30 into an hour long show recorded in standard quality.

[Jeff D]

AJ, did you try the tool? Did you get the sync back?
I've only had 3-5 files to try this on, so my testing was limited. =?

[AJStone]

Yeah it worked. Thanks again for the tool, though I will be recording the show again so that I can keep it on my 5040 for sharing. This has been a problem that you have mentioned many times and I'm glad that there is a solution. Here is the results from your tool, looks like it added 1K to the file size.

C:\Temp>streamfix sp1082775597.mpg 1082775597.mpg
Running...............................
found error at 00:26:31
........................................

04/24/2004 07:49 AM 890,401,792 sp1082775597.mpg
04/24/2004 08:04 AM 890,401,830 1082775597.mpg

[LaserDick]

Thanks, Jeff. This has only happened to me a couple times, and I just discarded the mpegs. I'll keep this with my Replay Tools for future reference.

You guys are great for all the fantastic third party support.

[Jeff D]

Originally posted by AJStone
Yeah it worked. Thanks again for the tool, though I will be recording the show again so that I can keep it on my 5040 for sharing. This has been a problem that you have mentioned many times and I'm glad that there is a solution. Here is the results from your tool, looks like it added 1K to the file size.

C:\Temp>streamfix sp1082775597.mpg 1082775597.mpg
Running...............................
found error at 00:26:31
........................................

04/24/2004 07:49 AM 890,401,792 sp1082775597.mpg
04/24/2004 08:04 AM 890,401,830 1082775597.mpg

AJ you sure you got those numbers right? I didn't think it should grow the file at all.... but your 1K is actually 38 bytes, right? A far cry from 1K, but the size change has me puzzled.... the only thing that I do is patch the 32bit PTS values. Looks like I may have an issue in the code. Thanks for pointing it out.

[AJStone]

Jeff, you are right it's not 1K much smaller. I got the numbers right from a command prompt (mark and paste) so yes the numbers are correct. However when I watched the show it in fact fixed the problem at 00:26:31, then went out of sync later in the show. I thought that it was fixed until that last 8 or 10 minutes. I'll try running it through again and see if it fixes the last part.

[Jeff D]

AJ, so you understand the "behind the curtian" stuff...

The following is an example of the error


{PTS[32:0]} : [{33}] : 0x001d2cd6c
{PTS[32:0]} : [{33}] : 0x001d2d5dc
{PTS[32:0]} : [{33}] : 0x001d2de4c
{PTS[32:0]} : [{33}] : 0x001d[color=red]2[/color]e6bc
{PTS[32:0]} : [{33}] : 0x001d[color=red]0[/color]262c
{PTS[32:0]} : [{33}] : 0x001d08a9c
{PTS[32:0]} : [{33}] : 0x001d0930c


When the error is encountered we know an "average" offset between two PTS (now, this isn't correct, but since our source is f'ed up we have to guess.) So the current PTS of 0x001d0262c is then used to get a delta to the next PTS 0x001d08a9c. (I assume these future offsets are correct) The problem PTS then gets corrected by taking the previous "good" PTS and applying the average offset. This new value is now the key for all future values that are calcuated by taking the following deltas and applying them to this base over time.

So... it's entirely possible that I'm not doing something right. Or... that there could be a second error in the file.

My guess is at the 8-10 minutes remaining you saw a slight drift that grew to a noticable level and not the freeze followed by the 2 second audio ahead of video, right?

I'd be really interested in seeing what's going on, but I'm sure file isn't still available for IVS? The file size growing has me concerned...

[AJStone]

Yes Jeff, the show is still available for IVS. If you'd like I can send it to you.

After running it again I noticed that the file size decreased another 8 bytes.

04/24/2004 08:04 AM 890,401,830 sp1082775597.mpg
04/28/2004 07:11 AM 890,401,822 1082775597.mpg

[Jeff D]

AJ, here's address... 00004-54832-50086
I just hope that box is acutally connected and powered up. I've got too many boxes and checking a few things out for others so boxes move often. =(

If you have any problems contacting the replay let me know. Thanks.

[AJStone]

Originally posted by Jeff D
AJ, here's address... 00004-54832-50086
................................................
If you have any problems contacting the replay let me know. Thanks.

Tried several times to add that address to my address book, not workin'.
I'll give it a try again a little later this evening.

AJ

[AJStone]

Jeff, still can't connect to that RTVID. I've tested my unit against the IVS server and it works fine. Have you had a chance to look at that unit?

[Jeff D]

AJ, sure, I had been letting it go hoping it was the IVS server. Let me check things out...

Been fixed (whatever it was...)

00004-54832-50086 back online, if the IVS server is down you'll have issues, but it's currenly accessible from the WAN.

[AJStone]

Sending the show now. Called "The Shield: Safe Audio Sync Problem". My unit's name is "Edge of Forever".

[Jeff D]

Cool, I've accepted it, and it looks like a std level, that should go quick. I'll update when it's complete.

[AJStone]

Should be transfering now....

[Jeff D]

AJ, I got it and I'll try to look at it sunday. I see the freeze and sync change. But that's about the shortest freeze I've ever seen about 1/2 second or so normally I see a 2-3 second freeze. I'll be interested in checking out your PTS time change.

[AJStone]

I wondering if the Maxtor 200GB w/8Meg cache in the unit has anything to do with the shorter freeze. It is pretty loaded up, maybe like 90-95% full at the time too.

[BulkHedd]

I am going to try this tool tonight. This problem happened to me once a few months ago, but it happened to me TWICE tonight (during 2 different shows). I hope this isn't a sign of things to come.

Hey, Jeff, I think I sent you one of the shows you tested this on.

Do you know WHY it happens. Each time it's happened to me, I think, when I was watching the show as it was being recorded.

[BulkHedd]

Ok, I tried it and something strange happened. It detected the error and corrected it, but when I was playing back the fixed file from my PC, near the end of the show it happened again. It happened during a commercial break, but I can't see a freeze spot. Just that the video is, again, behind the audio.

Since this was streaming form my PC, could the Replay have caused the problem? Or is it more likely that the Streamfix program might have done this?

[Jeff D]

BulkHedd, the second problem is most likely something I did wrong. AJ saw the same thing. I've got AJStone's file to look at, but a hard drive failure has directed my attention away. I'll look at it soon. If it's not a big problem can you hold on to the problem show for a few days?

[BulkHedd]

Yes, Jeff, I can hang onto it. I will keep the original file on my Replay.

[Mike Cornwell]

Jeff-

Just thought I'd post my results using your tool.

Recorded Alias' finale last night, and about 35 minutes into it, had the video stutter, and the audio became 2 or so seconds out of sync. By the way, this is the 3rd show in the past month or so that's done this :-(

Turned on DVA, downloaded your tool and started the Alias xfer before I went to bed. This morning, I ran your tool against the file, and it found and fixed the original problem, but about 15 minutes later in the show, the video became terribly artifacted, and the Replay I was watching it on became unresponsive, so I had to do a soft reboot. After the Replay came up, I tried viewing the video again, and ran into the same problem.

I don't know for sure that your tool caused the corruption in the file, I haven't fast forwarded to the point on the original recording, but will check when I get home.

I deleted the file in DVA, and I'm xfering it again from the Replay to DVA and will try your tool again (thanks to PC Anywhere)

BTW, Alias was recorded at high quality. In the mean time, I've requested the episode on Poopli, so if anyone wants to fill it...

-Mike

[Jeff D]

Mike, thanks for the info.

I just got my dev PC back to a basic working state, I still need to install all dev tools... It seems that something strange is happening after the fix, three reports of similar problems.

I'm curious if there's something wrong with the way I'm accessing data in the large files... but I can play with that.

I'll try to get to in in the next few days.

[Mike Cornwell]

Thanks for your effforts. I'm sure I'll get a copy of Alias from someone soon, but it'd sure be nice to have this in my bag of tools for future problems.

[Jeff D]

AJ, I think I got it fixed. Strange thing is there are two other PTS deltas that are way outside the normal time difference, twice as long as it should be. (I'm still working through to be sure tha there isn't more going on here) One is at 29:13 a difference of 4320 ticks the average is 2160 ticks. It happens again at 58:51.

If I hard limit the delta to the max legal value I've seen everything plays fine. All the way through.


BulkHedd and Mike, if you have your bad files I'd like to see it, AVS number 00004-54832-50086.

[Mike Cornwell]

Sorry, just deleted mine after Alias was sent to me. :-(

[Jeff D]

Version 1.0.1 has been uploaded, this should produce much better results.

AJ if you still have you shield source give it a shot, it worked well for me. :)

If anyone else has a problem file please give the app a try, if it doesn't fix it let me know.

[ejpbowie]

had this happen to me twice, I'll be ready to try this tool out next time it happens during a show.

[corgi1]

Thanks for the file, Jeff. I just used streamfix on an episode of Amazing Race that was out of sync and it worked great!

Jerry

[jgmace]

Jeff D. Can you give me a quick overview of how to use the tool. Last nights episode of 24 went out of sync about 1/2 way through. I downloaded the streamfix file.

[l8er]

Originally posted by jgmace
Can you give me a quick overview of how to use the tool. Directions are in the readme.txt file with the zip in the first post of this thread.

[Jeff D]

jgmace, yeah if you have any questions after looking at the replay feel free to ask.

I hope it can help you.

[MukPuppi]

Jeff,

This sounds VERY similar to a problem I've been having. One of the things I use my Replay for is to convert VHS tapes to DVD (VCR -> Video Signal Booster -> Replay -> WinReplayTV -> Womble 3.14 -> DVD Lab). Unfortunately the Replay does something VERY strange to the recording file if the VCR no-signal "blue screen" is ever shown - it GUARANTEES the audio will have a sync problem, and BADLY confuses MPEG2VCR about where clips on the clipboard start/end. So badly, I have to save the project, REBOOT the PC and open MPEG2VCR again. Then I have to carefully work with the MPEG file to ensure it doesn't play across that blue screen segment of the tape while editing. I also seem to get more broken frames, losing audio sync randomly on older tapes. I have some tapes from 1986 that look fantastic but have audio difficulties.

I ran your script against it a file with the problem and it reported no problems, but that may be due to my audio problem being under one second in length (usually under one second), and from the discussion your script seems to aim for a known 2-second bug. I was assuming in my case that the Replay was doing something "efficient" with the video stream (since there was no frame-delta for a blue screen) and that was hosing the audio. I also assumed MPEG2VCR made some assumption about time offsets and stream sync that the Replay didn't conform to under this case. :-(

I guess I'm just trying to understand how the Replay hoses the timestamps. I've gotten sufficiently frustrated with the problem that I'm now considering either a new MPEG tool (M2Edit gets good marks, but is pretty expensive and I don't know if it will fix the problem) or an out-board dedicated encoder (like the Plextor PX-TV402U) but I LOVE the quality of the Medium recording setting of the Replay. 160 Min on a DVD5 that looks GOOD...

[l8er]

A time base corrector (TBC) would solve your blue screen problem.

[Jeff D]

MukPuppi, your problem isn't the same (although it could happen, odds are pretty low on that) What I believe the problem is relates to the clock crystal that drives everything on the replay. There's two crystals I know of... the 48Khz crystal (audio) and the 27Mhz (drives the mpeg/video clock) (I'm a little hazy if there really are two crystals or just one, I'm pretty sure I've seen both so I'm sticking with 2 off the top of my head). A "glitch" in the 48Khz crystal output then throws a wrench into the audio processing causing the audio system clock time stamps to be off, WAY off.

It seems when the replay plays back it doesn't expect this time of derivation and just hangs the video and then plays on with both streams out of sync. It appears the replay doesn't have very robust error detection on the processing of the audio and video streams. I'd think you'd always want to check your time stamp against old time stamp when encoding just to be sure there weren't issues. I'd be SHOCKED to discover the problem was some software error when switching between variable sizes... whoops slipped into supergeek mode there.

Anyway when the replay loses video signal the audio and video are both interrupted and the encoder will stop as soon as the video sync is lost. Maybe an additional audio packet gets recorded, but that wouldn't be much more than a fraction of a fraction of a second and not detectable by you (maybe I could detect it, but you need years of working with this to notice such a small drift. Enough of these would add up so there is that...
)