Hej igen Pat. Nu er to en halv dag jo ikke 10minutter...
På mig virkede det som om at mange burde have problemet derfor undrede det mig at ingen svarede efter så lang tid...
Nå men, to buisness:
- Radeon 9600XT GFX-kort (modificeret til at køre med passiv køling, Zallman).
- PVR-500MCE tuner kort.
- Chill400W PSU.
- Kingston 2x512kb Ram. (husker ikke præcis hvilke, men god kvalitet med kølekapper (?).
- +3200 AMD Athlon Processor.
- ASUS K8N4-E Deluxe motherboard.
- Zallman 7700 CPU-køler.
- Hitachi Deskstar 250GB HD
Det er kun på optagelser foretaget af MCE. Det er kun ved afspilning i MCE, ikke ved afspilning, af samme fil, med WMP udefra XP interfacet. Det er kun ved overlappende optagelser hvor den sidst startende optagelse har den permanente fejl. Fejlen kan reproduceres og forekommer hver gang ved overlappende optagelse!
Jeg har tilladt mig at tage lidt udklip fra TGB da jeg ikke kan få dig til at gå ind på eksterne link. De forklarer problemet teknisk som jeg hverken kan forstå eller viderformidle uden direkte brug af citater. Here goes:
Peter Rosser: 2005.10.28 "We have indeed seen the problem you're looking at, and it's under investigation right now (by me, actually).
For those interested, the problem manifests (so far) only on Conexant-based PAL and DVB dual tuner setups, though I suspect it might repro on NTSC too (haven't seen that yet, knock on wood). It has to do with something called the PTS (presentation time stamp) reported for each MPEG2 stream delivered to MCE by the tuner driver getting out of whack. You will probably be able to reproduce it consistently doing something like this:
- Stop all recordings, exit the Media Center shell and stop the "Media Center Receiver" Windows service (net stop ehrecvr).
- Start the ehrecvr service again (net start ehrecvr)
- Start the Media Center shell.
- Tune to a channel and start a recording by pressing the Record button.
- Watch that channel for more than 30 minutes.
- Tune to another channel and press Record.
- Let it record for several minutes.
- Stop both recordings (not necessary for the repro, but it helps to see it
)
One or both of the recordings will probably repro the issue.
The only way to guarantee the problem will not repro seems to be if the tuners both start recording within 10 minutes or so of each other. Anytime you set both tuners to "not recording" status, there is a reset of the condition. Disabling one of the tuners will prevent the problem... but that's not a real solution.
A workaround with an already-bugged recording is to press Fast Forward on the remote and then Play right after. And that is painful, since the "freeze" will occur fairly often."
Her et nyere citat fra 2006.01.04:
Peter Rosser: "We do have a fix for this, but for legal reasons I'm not allowed to give it out to non-NDA people. I tried to see what needs to happen to get individuals on NDA, but since it requires GM-level approval and signature (that is, someone 4-5 levels higher than me) for each one, I was told it was not possible outside the normal beta and partner programs. I sincerely apologize for the delay; since there is a workaround (use one tuner, or rollback), and it wasn't security- or crash-related, the bug does not qualify for a "critical" hotfix, so it will go out with the next QFE release, scheduled for early CY06 Q1 (the date is not public yet).
I want to reiterate that the problem is actually caused by the driver, and not by MCE. The fix was to do some streaming analysis and detect when the tuner gave us bogus timestamps for caption samples, and reset them to a dynamic baseline. Presentation timestamps (PTS) are a time index set for every video, audio, and caption sample that specifies when, in relation to the content's "start time", the sample should be rendered to its output device. So if a PTS is set to 0:15.010, and the current time index is 0:11.140, it will be held in the buffer another 4 seconds or so, then sent on to be rendered. This is done because samples can be encoded out-of-order to improve efficiency (bi-directional encoding). The problem here is that the tuner driver interleaves (PTS) from one tuner and then the other onto the stream (which is BAD), which causes those samples that got a bogus PTS value way in the future to be held in the buffer until the PTS becomes "current". Since the buffer holds about 15-20 seconds of video, and is shared among video, audio and captions, it quickly fills with caption samples, and once full, all samples are dropped until the samples can be delivered from the buffer." Citat slut.
Jeg mener at mit problem er identisk med det der er beskrevet i tråden og af Peter Rosser. Men det er måske bare mig der ikke har teknisk indsigt nok i emnet om PTS til at lave et fix... 
Vh, Mikkel