Davor

I use VB 2.2.4 on XP I can concur with the following: The Adaptec ASPI drivers that I used were from ghost 8.3 generated startup floppy. Also: sometimes VB will only show the first line of the dos-commands, and will overwrite them continuously. This happens when I send the “crtl+ald+del” and the system reboots but doesn’t show the “bios bitmap”. Not to mention a bug which locks the crtl-key and makes it impossible to unlock. To unlock it, I need to enter the virtual machine, “right-crtl” out of it. Then it suddenly locks up again while VB works on the background. Imagine typing and crtl suddenly locks up!! This issue I had once and I had to reboot the system to fix it. My first virtual installation of XP also froze some 17 minutes prior to the estimated end. The second installation worked flawlessly. Cause? No idea. Support of vhd-files is ridiculous. If you make two snapshots, and discard the last, the VB just crashes!! Why make vhd’s loadable if their support isn’t stable?! Also, one time the virtual machine just wouldn’t load up. It happened when trying to start a second virtual machine, while the other was working on lower priority. The little msgbox saying that the virtual machine is starting stayed on 0% and didn’t go away. Virtualbox.exe process was taking 100% CPUtime. I couldn’t even kill the process; I had to reset my PC, something which I do once a year! All these issues I had in ONE day. Imagine how far I got with what I planned to do… I use Virtual PC already for some 2-3 years, and never had problems with it. Because of lack of USB support and VRDP, I thought to give VB a try. On various sites it is depicted as the best, or at least on of the best free open source virtualization alternatives. But most of the time I try to switch to some open source software I first get overthrown by the features and then disappointed by the buggieness.

Summary: When capturing from TV to dvr-ms-file via Win XP MCE, the header of the dvr-ms file signifies that the stream’s resolution is 720x480, while the real stream resolution is 720x576, MCE configured for PAL country and Hauppauge 150 MCE a PAL version. This can have complications for playback. For example, when playing back in WMP (directly or through avisynth) with ffdshow as MPEG2 decoder, the lowest part of the picture (I assume some 576-480 = 96 lines) is missing. When I consult the ffdshow info and/or avisynth’s info()-function it says the resolution is 720x480. When I switch back to my old nvidia decoder, the picture is displayed correctly in WMP and in file-preferences the correct 720x576 resolution is displayed. This led me to investigate the real resolution of the stream. After consulting various websites and making sure my Hauppauge MCE150 was configured correctly (i.e. to capture in PAL format), I went on to investigate the file itself. Gspot said it was an asf container, so I downloaded asfviewer (http://www.microsoft.com/windows/windowsmedia/forpros/format/ASFViewer.aspx) and opened the dvr-ms file. Under Header object “Stream Properties” one finds the following data: Stream Properties Object [1] (297 bytes) Property Value File Position 9005 ( 0x232D ) Object ID B7DC0791-A9B7-11CF-8EE6-00C00C205365 Object Size 297 ( 0x129 ) Stream Number 1 Version 1 Offset 0 Encrypted False Security ID 18873916 ( 0x11FFE3C ) Stream Type Specific Stream Type Video Media Window Width 720 Window Height 480 Flags 2 Bitmap Info Header biSize 208 Width 720 Height 480 Planes 1 Bits 0 Compression TEXT: DVR 0000: 44 56 52 20 DVR Image Size 0 X Pels / Meter 0 Y Pels / Meter 0 Colors Used 0 Colors Important 0 Extra Data Size 168 Extra Data 0000: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 0010: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 0020: 00 00 00 00 00 00 00 00-63 17 05 00 00 00 00 00 c 0030: 00 00 00 00 00 00 00 00-04 00 00 00 03 00 00 00 0040: 00 00 00 00 00 00 00 00-28 00 00 00 D0 02 00 00 ( 0050: E0 01 00 00 01 00 00 00-4D 50 45 47 00 00 00 00 MPEG 0060: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 0070: 00 00 00 00 00 00 00 00-02 00 00 00 02 00 00 00 0080: 00 00 00 00 00 00 00 00-D0 C4 C4 C4 49 00 2B 4E I +N 0090: 98 FB 95 37 F6 CE 51 6D-D1 C4 C4 C4 49 00 2B 4E 7 Qm I +N 00A0: 98 FB 95 37 F6 CE 51 6D 7 Qm This led me to try to change the headerdata (all instances of 480 to 576) and see whether this is causing the playback problems. After I changed the 3 values (those emphasized), the ffdshow codec stated displaying the dvr-ms file correctly (with lower part of the picture displayed and acknowledging it as a 720x576 stream) Further testing showed that changing only the binary data under “extra data”-property from “E0 01” to “40 02” was enough to make the dvr-ms file play correctly with ffdshow in WMP and MCE. So, the question is: am I the only one or is everyone having this issue AND IF SO, how can one force MCE to write down the header of dvr-ms-files correctly? Help would be appreciated.

Now... it happened again, but only after the second auto update. The first auto update, as written in my second post, went with no problems. Grrr!!! Really annoying

I solved it apparently by deleting the EPG folder in eHome map… The guide seems to be downloaded correctly this time, without crashing the PC. Still I find it very strange that an application can hang a system in such a way. Anyone has an explanation for this? Also, I see that in the deleted EPG folder, prior to crash, a .sdf file was created everytime (184320KB). The new .sdf file is about 24MB

This is really strange. This PC is some 3 years old MCE box and almost never crashed, until the last few days. I always leave it 24/24 7/7 running. But the last 3 days, I always find it unresponsive when I wake up. I have to restart it manually, and when it boots up, it’s like nothing ever happened... no error report, and event log shows nothing. The second time it crashed, it did make a notice in the log: Event ID: 19 Event Source: recording Event Type: Error Event Description: Media Center: The recording schedule has been corrupted and was automatically deleted on xx/xx/xxxx xx:xx:xx PM. You may need to reschedule your recordings. But I thought this was because of the crash. I also checked the hard drive because I thought it could be a bad cluster causing the hang. I also found in the logfile an event saying that it wil download the guide next day at 01:21:11h … so I made a performance counter and sent it to the server. Last data I got was at 2007-08-26 01:21:47.546, showing a bit CPU usage from ehSched, ehtray, explorer, svchost, system and 38% for ehRec. After that it’s hung completely. I can’t even ping the machine from the server. So the question is, has anyone any suggestions about why this could be happening so ‘suddenly’? I searched the internet, and found nothing. The last automatic update was a few days ago, and it seemed to work fine after that, so I don’t think it’s an update bug. The only solution I see for the future is to shut down the service, but that not an option for a long term.