fredx21:

This is weird. The findings so far make us think that the DLL has no time bomb inside and that microsoft's DLL has at least some H.264 code inside. That got me thinking and I was wondering whether the time bomb could be in Media Center itself. Media Center could refuse to use it's own DLL's guid past the expiration time.

Here's a suggestion: Try creating a new GUID in the registry that points to microsoft's DLL. Media Center could be fooled by an unknown GUID and start using microsoft's DLL.

Fred

32bit ultimate.

ac3filter has so far worked under all combinations but the ms dtv/dvd audio decoder one breaks with certain video codecs in the clsid entry.

So far it seems like it's either mpeg2 OR h.264 (with a slight stutter every 4 secs and slightly out of sync sound).

I have also been trying different combinations with the preferredmpeg2videodecoder entry under

hklm\software\microsoft\windows\currentversion\media center\service\video

At one point i thought it was working ok, but after a reboot only h264 was working.

It's interesting to note that with the beta dll file, the ms dtv/dvd codec is no longer working, but the ms mpeg2 codec can be substituted in order to get sd channels working.

I will have to stop soon and restore my acronis image from earlier so that all my recordings can take place as this is my main htpc.

I will have to install on another machine and tinker over the next few days (family permitting )

HolidayBoy,

Souonds like you're on to something. Have you tried CoreAVC to decode H.264. What CPU/memory spec do you have? Is this responsible for the stuttering you get with HD?

Keep up the good work.

Ben

Joni:

Could someone send me small sample (50Mb max) of HD wtv file? mf1575(at)gmail.com.

I'll swap the decoder over and do a quick recording of bbchd and send it.

SysRq:

asm495:

I'm about to go out for the day but have a look at this line: 0042EED0 7505 jnz L0042EEE4 I think if "75" is change to "74" then it will become a "jz". This may change the behaviour so that it will work after the normal switchoff date but not before. Don't have time to do it myself now but might be worth someone having a go at.

Already tried that, it didn't work. Also changed other jumps in that section, one at a time.
Thought that routine was the one checking the date, and maybe it is but no luck.
Could it be that the dll is signed so it's no use tamper with it?
Tried recalculate the checksum after my change, but didn't help either.

I have analysed the .dll and can see the only difference.

In the beta there is a call reference to 'time64'  this I think is the timebomb.

Hope this helps

David

To add to my previous post.  I have tried to remove references to 'time64' from the beta .dll but I don't know how to reassemble the .dll when finished.

Cheers

D

dmb1234:

To add to my previous post.  I have tried to remove references to 'time64' from the beta .dll but I don't know how to reassemble the .dll when finished.

Cheers

D

I don't think you just can remove the reference, it doesn't work like that.
There should be some sort of compare after that call, that could be changed to the opposite, i.e. jnz becomes jz, jl becomes jnl and so on.
That way the dll would work after the timebomb date but not before.
Can you please tell me where you think the timebomb is so I can try to change it?

Hi

I scrolled though both .dll's and found 'time64' it was only present in the beta file.

I then searched 'time64' and 3 results with this title were present in the .dll

I'm very new to decompiling so please forgive my basic description.

Hope this helps

D

I have been following you guys and all your hard work since the 31st timebomb and thoguth it was about time I showed my interest (I am sure there are many other slient watchers).

I spent an hour or so playing with the files and found out the following test that suggests that the .dll is timebombed (probably with the call the time64 that is only present in the beta):

1. Open a command prompt and cd to \Windows\System32\ (where the dll sits)
2. Run regsvr32 MSDTVVDEC.DLL

The Released TV Pack dll registers ("DLLRegisterServer in MSDTVVDEC.DLL succeeded"). The beta dll fails ("The module 'MSDTVVDEC.DLL' was loaded but the call to DLLRegisterServer failed with error code 0x80004005"). Next I set the OS date back to 30/08/08 and tried the beta dll again and it registered fine. Hope this helps.