Mercury 2 audio sync

[turbosat]

Anyone else notice a problem with the audio staying in sync on the Merc2? This has happened sev times lately, a quick channel change and back to channel I'm watching fixes it. As does a reboot. Running the latest firmware, everything else seems to work ok. Tonite, I was on same channel for about 3hrs and busy on computer, looked at the tv and there it was again, about 1-2 seconds off from the video. Channel up/channel down and its fixed! This bug bugs me.

 

[searay43]

Anyone else notice a problem with the audio staying in sync on the Merc2? This has happened sev times lately, a quick channel change and back to channel I'm watching fixes it. As does a reboot. Running the latest firmware, everything else seems to work ok. Tonite, I was on same channel for about 3hrs and busy on computer, looked at the tv and there it was again, about 1-2 seconds off from the video. Channel up/channel down and its fixed! This bug bugs me.

Mine does the same thing, it seems to happen more often if I switch channels alot. I have to reboot to fix it, I'm also running the latest firm ware. Thought I had a bad unit.

 

[SatelliteAV]

Very typical for consumer grade receivers and many commercial receivers to loose lip sync. Usually these receivers reference the PCT only during signal acquisition. Changing to another transponder or power cycling the receiver causes the receiver to reacquire the signal and sync the audio and video sources. Many a head end engineers can be found behind the racks power cycling receivers on a very regular basis.

This problem can be aggravated by reception, encoding, decoding issues and non-DVB compliant muxes. Usually the loss of sync is not noticed as most STB receivers do not stay on a fixed channel and regularly surf channels or are powered down.

We recently had our receiver manufacturing partner's engineering team at our facility developing a synchronization routine for the GEOSATpro DSR-R100 series rack mount receivers. We have implemented a firmware update to force PCT reference on non-compliant DVB signals to prevent lip sync loss and a selectable system maintenance mode which power cycles the receiver daily at 2am.

 

[turbosat]

Thanks Brian for the input. I was watching ( a channel normally scrambled but free for a few weeks now) on AMC4 LOL .......well its on lyngsat but I won't name it anyway.
Its the only rec out of about 4 that I use regularly that I've noticed that particular problem on.
I'll try putting my Icon on it tomorrow night for 3hours and see if it lip-locks!
But you're prob right, normally the only channel mine stays on that long, or longer, is NASA TV.

 

[B.J.]

Very typical for consumer grade receivers and many commercial receivers to loose lip sync. Usually these receivers reference the PCT only during signal acquisition. ........
.....
This problem can be aggravated by reception, encoding, decoding issues and non-DVB compliant muxes. ....

Interesting, about the signal acquisition thing.
And I agree about the "aggravated by reception" thing. I can see this happening all the time when I have poor signal, such as during a high wind situation, which blows tree limbs in front of my dish temporarily causing a signal glitch. THe sync will be fine, until I get a reception glitch, then when a glitch occurs, the sync will be off. So I really believe that 90% of the audio sync problems are caused by a poor sat signal, not that the Mercury is bad at audio sync.
Most of the things I actually watch on satellite, however, are things that I've recorded. I play them back, usually via my Roku HD1000. When the reception glitches occur, I also get the sync problem with the Roku as well. Sometimes it isn't just a sync problem, but complete loss of audio. With the Roku, however, what I usually do is hit the "back up 10 seconds" button (on MPLAY), and the audio is usually back in sync. So I guess that's an example of the Roku re-sampling the PCT whenever I hit the back up button like you describe.

I'm curious though, whether it would make a difference whether I recorded a program as a transport stream vs recording as a program stream. I think I usually record as a transport stream. I just seem to remember reading that there is a difference between the way the timing is done in PS vs TS, but I can't remember. Or maybe I just dreamed about reading that.

I never quite understood how the PCT thing worked. If I create a manual audio channel (using TSREADER), it generally asks me for the PID containing the PCT. If I make an audio channel from audio that's part of a video program, the PCT is usually part of the video stream, and I have to give that PID. I've wanted to make audio channels, and send them over my network, but it then requires sending the whole video stream along with the audio, even though it's only the audio that I want. But people tell me that you can't play audio without PCT info.
AND YET (and this is what confused me), it IS possible to play audio from a program that has encrypted video but unencrypted audio, even though the PCT is part of the encrypted video stream. Perhaps the encrypted video stream is made up of packets with unencrypted PCT info. Anyway, that's always confused me.

 

[Tron]

A friend of mine has a DVD player that loses sync if it is paused many times during a movie. For that reason, I believe the sync issue has more to do with the MPEG 2 stream than anything else...

 

[B.J.]

Speaking of sync problems caused by pausing too many times, perhaps the wierdest video problem I have EVER encountered was a few years ago, when I wanted to record the SuperBowl from a HD network feed, however the computer I had my Twinhan card on didn't have any disk space left. I had a laptop on my LAN, which had about 40 GB, but I was calculating that the SB would take at least 60 GB or more. So what I did, was stream the signal over my LAN, and I set up VLC on my laptop not to play the HD stream, but to record it to file.
Since I didn't have enough disk space, what I would do, is when there was a commercial or other delay, I'd hit pause on VLC, then start it up again when play resumed. The biggest pause was during halftime.
Anyway, the next day, when I went back to see how my recording worked, it seemed to work very well, all the way up to halftime. When the 2nd half started, the recording went completely beserk. You'd see about 10 or 15 seconds of a play, then it would sort of jump back in time, and you'd see that 10-15 seconds again, and again, and again.... eventually it would break out of that sequence, and you'd see a bit of the game, then it would jump back in time again, and you'd again see a 10-15 second sequence repeated over and over and over again. It was the wierdest thing I have ever seen. Only good thing was that I got to see one TD pass about 50 times.
I put the thing into VideoReDo, and was able to at least pull out the non-damaged parts of the game, but VRD also had all sorts of trouble with the recording.
Anyway, I was convinved that what had happened was that my long pause at halftime had somehow completely messed up the timing of the recording, possibly related to the PCR... perhaps it isn't a long term clock, but a clock that recycles or something, I have no idea, but it sure resulted in the most interesting recording I've ever made.

BTW, when PCT was mentioned above, my mind was interpreting that as PCR, but now I'm not sure.