Any thoughts about running WMC in Win7 VM under Win10?

An evolving, supported alternative to Rovi
Forum rules
★ Download the latest EPG123 here: http://epg123.garyan2.net <> Setup guide here: http://epg123.garyan2.net/downloads/epg123_Guide.pdf
Space

Posts: 1580
Joined: Sun Jun 02, 2013 9:44 pm
Location:

HTPC Specs: Show details

Re: Any thoughts about running WMC in Win7 VM under Win10?

#21

Post by Space » Tue May 21, 2019 1:11 am

Some of the conclusions you have come to are incorrect.

The way that PlayReady was designed is so that you can change a limited number of components in your system without breaking DRM, but if you change too many, it will break. So, changing out a hard drive will probably not break it, but changing out several hard drives, or changing a hard drive multiple times over a longer period may break it.

Also, your conclusion derived from making a DRM recording on Tuesday and restoring the image from Monday is not correct. If you record a DRM show on Tuesday, it stores the license for that show in a file on the filesystem. If you restore an image (that was made prior to the recording) after that, the license file will be overwritten. This is why you will be unable to play back that show. If you save a copy of the license file, restore the Monday disk image and then overwrite the license file with the one you saved (which contains the license for the show recorded on Tuesday), you will be able to play back the Tuesday recording fine.

In general, a unique identifier is created for a system based on two different main things, one is data stored on the hard disk when you installed windows (software), the other is the hardware components you have in your system when you initialize PlayReady (hardware). As long as you back-up your windows install as an image, it should retain all the needed components used to create/verify the system identifier with regards to the software aspect. The second aspect is the hardware, and that needs to be the same or have minor changes in order to not break DRM. What hardware can be changed and how often you can change it is purposely vague as to make it harder to clone a system (hardware and software) to be able to play back a recording on a system other than the one it was recorded on.

Here is a thread regarding some tests that were done to see if you could backup and restore the license file on an older disk image:

viewtopic.php?f=68&t=4635

DSperber

Posts: 234
Joined: Thu Jan 16, 2014 1:35 am
Location: Marina Del Rey, CA

HTPC Specs: Show details

#22

Post by DSperber » Tue May 21, 2019 5:36 pm

Space wrote:
Tue May 21, 2019 1:11 am
Some of the conclusions you have come to are incorrect.

The way that PlayReady was designed is so that you can change a limited number of components in your system without breaking DRM, but if you change too many, it will break. So, changing out a hard drive will probably not break it, but changing out several hard drives, or changing a hard drive multiple times over a longer period may break it.
I had always assumed MS realized there were some things users would likely "upgrade" under normal circumstances on the same machine, so that their discovered difference shouldn't be considered a tipoff that it was actually another machine. This would probably include disk drives and their sizes, partition location for \Recorded TV, graphics card, memory, etc., whereas CPU and motherboard were more revealing of the "identity" of the machine. This is speculation, of course, based on what I've been able to get away with in the past regarding hardware upgrades.

I remember reading that adding memory (which is what I wanted to do once, upgrading from 8GB to 24GB by adding another 16GB) had been predected to be "allowed" by others based on their own experience. But for me it broke DRM, and I had to remove the additional memory in order to restore the ability to play previous copy-protected content. So obviously memory is NOT one of the parameters freely allowed to be changed without impacting DRM, as it was the only thing ever changed from the originally installed Win7 system on this machine and yet adding memory broke DRM.

So I guess it's kind of unpredictable. Adding memory affected my DRM, but seemingly not others' DRM.

Also, your conclusion derived from making a DRM recording on Tuesday and restoring the image from Monday is not correct. If you record a DRM show on Tuesday, it stores the license for that show in a file on the filesystem. If you restore an image (that was made prior to the recording) after that, the license file will be overwritten. This is why you will be unable to play back that show. If you save a copy of the license file, restore the Monday disk image and then overwrite the license file with the one you saved (which contains the license for the show recorded on Tuesday), you will be able to play back the Tuesday recording fine.

In general, a unique identifier is created for a system based on two different main things, one is data stored on the hard disk when you installed windows (software), the other is the hardware components you have in your system when you initialize PlayReady (hardware). As long as you back-up your windows install as an image, it should retain all the needed components used to create/verify the system identifier with regards to the software aspect. The second aspect is the hardware, and that needs to be the same or have minor changes in order to not break DRM. What hardware can be changed and how often you can change it is purposely vague as to make it harder to clone a system (hardware and software) to be able to play back a recording on a system other than the one it was recorded on.

Here is a thread regarding some tests that were done to see if you could backup and restore the license file on an older disk image:

viewtopic.php?f=68&t=4635
Thanks for this insight. Actually, I believe I had read about the significance of C:\ProgramData\Microsoft\Playready\mspr.hds many many years ago but had forgotten all about it. That's why I had in my mind conceptualized the explanation for why the newer copy-protected recordings wouldn't play after restoring an older image as being due to a "forward-moving time-sensitive DRM key" for each recording based on a sophisticated and clever algorithm that somehow understood the "life age" of the recording Windows. In fact it was actually a lesser sophisticated technique, namely just placing the DRM keys in C:\ProgramData\Microsoft\Playready\mspr.hds.

So if you take the trouble to back up C:\ProgramData\Microsoft\Playready\mspr.hds regularly along with the regular "system image" backups you take and that you might one day need to restore, and then also restore your latest backup of C:\ProgramData\Microsoft\Playready\mspr.hds (in safe mode, to guarantee that it can be written), that should accomplish all goals with minimum potentially negative effect. You will be getting your operating Windows recovered, and you will also recover the ability to play all copy-protected recordings made up to the date/time of your restored backup of mspr.hds.

I haven't had the actual need to restore a backup "system image" for years. But I can assure you I will not forget this newly clarified information (thanks to the discussion in that forum thread from 2013 you pointed to) should I need to do it in the future. As it turns out my normal Macrium Reflect "system image" backups on my production Win7 HTPC are taken every night at 1:30AM (presumably after most/all of my previous day's recordings are complete). I now take a daily such backup precisely to minimize my loss of ability to play copy-protected content in such a disaster recovery situation where a "system image" restore is required.

But my regular nightly backup regime also includes NovaBACKUP "data" backups at 2AM, of all changed/created folders/files... of course including C:\ProgramData. So naturally mspr.hdr would also get backed up each night, and it would be simple to remember to also restore the latest version I have should I ever need to restore an older "system image" backup for disaster recovery. This would minimize (or eliminate) the loss of ability to play copy-protected recordings made subsequent to the date/time of the restored "system image".

Many thanks again for waking me up on this very important subject. Great info to know.

I can actually experiment with this in my new Win7 VM + Ceton ETH environment where I also have Macrium Reflect running, taking "system image" backups of the Win7 VM system C-partition just as if it were running on a real dedicated physical machine.

jachin99

Posts: 1181
Joined: Wed Feb 24, 2016 3:36 pm
Location:

HTPC Specs: Show details

#23

Post by jachin99 » Tue May 21, 2019 6:06 pm

I don't have the hardware to really answer it but my big question is, what if you created two images on a VM that you can backup and restore from, each having their own WMC instance. Instance one would be a video player machine that gets regular use for TV, movies, etc. Machine 2 would also be setup with WMC, and playready. You would then hardlink the playlready key from instance one to instance 2, and clone each for redundancy. If your images could survive a hard drive transplant with playready infrastructure in tact then wouldn't you theoretically have a setup where you never lose your playready keys or recordings? You could hardlink all of the playready keys on your PC to that one machine, and keep image backups and it would never die. I haven't done so yet but I need to read through that thread. Just a curiosity more than anything else but I know I'm not the only one wondering about something like this.

jachin99

Posts: 1181
Joined: Wed Feb 24, 2016 3:36 pm
Location:

HTPC Specs: Show details

#24

Post by jachin99 » Tue May 21, 2019 6:06 pm

For backups, maybe a forensic image would retain everything needed for playready https://www.andreafortuna.org/2017/12/2 ... -workflow/

cwinfield

Posts: 560
Joined: Tue Feb 12, 2013 1:14 am
Location: Monroe, NC

HTPC Specs: Show details

#25

Post by cwinfield » Sun Jun 02, 2019 3:29 am

cwinfield wrote:
Mon May 20, 2019 12:51 am
jachin99 wrote:
Sun May 19, 2019 11:31 pm
When your 100 percent sure about your setup you should try making a copy protected recording, then cloning the VM to see if the copy protection key survives the cloning process. I know someone else has mentioned trying this, and there are a few of us around the forums looking for a success story.
I can try this sometime, have a VM on hyper V that I can setup a VM on an older computer with win 10. If it wasn't the end of the weekend and I didn't need to look into coding a new TPMS sensor for my BMW then I would do it.
I tried to see about trying my VM on another PC but couldn't do hyper v on old q6600 PC as it does not have support for hypervisor. Tried again on surface but it is home version so no hyper v again. Somebody else will need to attempt it.

DSperber

Posts: 234
Joined: Thu Jan 16, 2014 1:35 am
Location: Marina Del Rey, CA

HTPC Specs: Show details

#26

Post by DSperber » Fri Jun 14, 2019 8:37 pm

jachin99 wrote:
Tue May 21, 2019 6:06 pm
I don't have the hardware to really answer it but my big question is, what if you created two images on a VM that you can backup and restore from, each having their own WMC instance. Instance one would be a video player machine that gets regular use for TV, movies, etc. Machine 2 would also be setup with WMC, and playready. You would then hardlink the playlready key from instance one to instance 2, and clone each for redundancy. If your images could survive a hard drive transplant with playready infrastructure in tact then wouldn't you theoretically have a setup where you never lose your playready keys or recordings? You could hardlink all of the playready keys on your PC to that one machine, and keep image backups and it would never die. I haven't done so yet but I need to read through that thread. Just a curiosity more than anything else but I know I'm not the only one wondering about something like this.
I have now completed my VM experiments with this question.

And the answer is YES, the hardware/Windows indicators to PlayReady that the second "cloned" Win7 VM is actually the very same hardware/Windows as made the copy-protected WTV recording in the first place... this turns out to be true. I made a WTV recording using WMC in my working Win7 VM. Then I copied the VM (and hard disk) definition folders into a second, gave it a new name, and launched it. This second VM is completely separate from the first VM in terms of having two completely separate set of associated VMWare definition folders, but actually they're identical inside.

And I was able to play that copy-protected WTV recording with WMC in the second VM, which had been made by WMC running in the first VM. That's all the proof we need.

Along with the knowledge that proper manipulation and copying of MSPR.HDS will retain the needed PlayReady keys for copy-protected recordings so that you can actually preserve playback ability for copy-protected content across Windows system image restores (on the same hardware machine, of course), it also turns out that "cloned" (i.e. COPY'd) VM's are apparently seen as "the same physical hardware machine and installed Windows". So multiple VM's (at least on the same machine) also have the ability to play copy-protected recordings made by any of them, as long as you manipulate the MSPR.HDS in each VM correctly. The multiple VM's are definitely seen as the same machine and same Windows, to PlayReady.


One final postscript that I had to fight with today (but again, emerged victorious). You can read the whole story on this other thread of mine on the VMWare Workstation Player forum.

Turns out WMC will not record on network drives. Even if there is a "mapped network drive letter", it really isn't "local". Turns out "recorder storage" MUST BE TRULY LOCAL. And that meant I couldn't use my intended host drive F (assigned virtual F by "map network drive" in the Win7 VM) as "recorder storage". Only virtual C was showing up as "recorder storage", since it was the only "local" drive in the Win7 VM.

But I wanted to use host F (which is about 4TB free) to be "recorder storage" for WMC in the Win7 VM. How to do that, if there's no genuine way to map local host drives to the Win7 VM in VMWare (and there isn't)?

The solution is to ADD a "second virtual hard disk", of whatever size (I chose 500GB for this "proof of concept"). The appropriate files defining that second virtual disk are initially placed on host C, thus requiring that host C be very large in order to support this 500GB second drive for the VM. But these disk definition files can actually be copied ANYWHERE ELSE, and then settings changed to point to this other location instead of the host C location. So I copied them over to F and pointed to them there. And I assigned a drive letter of Z (using DISKMGMT) wo that I could also have my real host F available as virtual F (from mapped network drive), as well as the "recorder storage" located on physical host F but lettered as Z to keep it unique.

This got me what I'd wanted all along, namely the large "recorder storage" physically located on my large host drive F, and appearihg as a "local drive" in Win7 VM so that it is eligible for use as "recorder storage". And all the other host drives are "mapped network drives" inside the Win7 VM, assigned with the same letters as are actually in effect for the host Win10 where they truly are local drives.

Case closed. Still 100% successful, and recordings CAN NOW BE MADE ON F. And these recordings can be played back by WMC in ANY of the "cloned" Win7 VM's. And MSPR.HDS lets copy-protected content be playable forever, even if you have to restore an older system image.

Remarkable.

Space

Posts: 1580
Joined: Sun Jun 02, 2013 9:44 pm
Location:

HTPC Specs: Show details

#27

Post by Space » Sat Jun 15, 2019 11:22 am

Just to be clear...

You are running a VMWare VM on Windows 10. In the VM you have Windows 7 and WMC and you are able to record and playback recordings that have DRM.

That's pretty cool and may be a solution for all those that are struggling with WMC on Windows 10 (especially if you need to record/play DRM recordings).

What are you trying to accomplish/prove by having it run in two separate VMs? I can understand if those two VMs were on separate physical machines (that would mean you circumvented the DRM), but on the same physical machine, I am not sure what it gets you.

jachin99

Posts: 1181
Joined: Wed Feb 24, 2016 3:36 pm
Location:

HTPC Specs: Show details

#28

Post by jachin99 » Sat Jun 15, 2019 4:31 pm

I think that's awesome!! The idea I was getting at was that multiple machines could share the same play ready infrastructure so that you could have one playready key be shared among multiple PCs throughout the house. If any of them die you could just spin up a new one. It looks like it works at least if the VMs are created properly. I wonder if there is a way to recreate an existing windows instance inside a VM I.E. take a machine with DRM recordings that might be on its last leg and clone it to a VM so you could keep your recordinga. Either way as a proof of concept I would say it works

cwinfield

Posts: 560
Joined: Tue Feb 12, 2013 1:14 am
Location: Monroe, NC

HTPC Specs: Show details

#29

Post by cwinfield » Sat Jun 15, 2019 4:38 pm

jachin99 wrote:
Sat Jun 15, 2019 4:31 pm
I wonder if there is a way to recreate an existing windows instance inside a VM I.E. take a machine with DRM recordings that might be on its last leg and clone it to a VM so you could keep your recordinga. Either way as a proof of concept I would say it works
I think clarification is needed on whether the cloned VM was in fact a completely different machine. The way to test what your saying about transplanting a physical machine into a virtual seems highly unlikely. One could try to restore a windows backup or F8 recovery a VM install and try to load a backup which very well might work but not sure if the drivers would sort themselves out or even boot for that matter.

A search for physical to virtual machine revealed this https://www.veeam.com/blog/how-to-conve ... k2vhd.html

DSperber

Posts: 234
Joined: Thu Jan 16, 2014 1:35 am
Location: Marina Del Rey, CA

HTPC Specs: Show details

#30

Post by DSperber » Sat Jun 15, 2019 5:37 pm

Space wrote:
Sat Jun 15, 2019 11:22 am
Just to be clear...

You are running a VMWare VM on Windows 10. In the VM you have Windows 7 and WMC and you are able to record and playback recordings that have DRM.

That's pretty cool and may be a solution for all those that are struggling with WMC on Windows 10 (especially if you need to record/play DRM recordings).
Absolutely. I'm not actually using this in a "production" environment (for that I have a real dedicated Win7 HTPC), but this whole project was a research experiment for proof-of-concept. Although I'd never actually used VM before I was very interested to learn about it, given the upcoming end-of-life for MS support to Win7 in January and the notion of continuing to run and use Win7 in its final state for things I do today.

WMC in Win7 is a wonderful product as we all know, but lives in a complex setup of hardware and software. So I was curious to see if it could actually run in a Win7 VM and provide the same end-user experience out there watching TV at extenders. And of course I have Ceton ETH tuner and tuning adapter for Spectrum SDV-delivered cable-provided cablecard-enabled content (almost all marked copy-protected), as well as a Hauppauge WinTV QuadHD OTA/ATSC tuner for roof antenna broadcast TV. So the Win7 VM implementation and related WMC extender experience would have to provide the same support, somehow. And I use EPG123 for my Guide, so that would hopefully have to work as well.

In other words the project was to see what VM was and how to use it, and then to see how Win7 VM worked inside of VM implemented on a Wn10 machine, and what if any were the limitations or issues or problems or successes, given my WMC goals. It's been quite a learning experience, but with some assistance from experienced users on the VMWare forum I've been able to address and resolve every setup problem and issue I ran into regarding some aspect of what WMC and extenders required to run properly, and how that could be facilitated through Win7 VM.

Nightly scheduled task running of EPG123 within Win7 VM workis identically as it does in a real physical Win7 machine. Access to all 192.168.1.* LAN network components is 100% the same within Win7 VM as it is in a real physical Win7/Win10 machine on the LAN. It truly is amazing. After initially creating the Win7 VM in VMWare, the rest of the process was just like I would do if I bought a brand new hardware machine and wanted to install Win7 on it and then "flesh it out" with all of my own installed software products and Win7 customizations. It was 99.99% identical doing all of this in Win7 VM as in a real physical Win7 machine. The few differences really pertained to hardware like nVidia graphics cards and their drivers not being available inside the Win7 VM although they are in the physical Win10 machine and installed in Win10. And the original Ceton PCIe internal tuner card I was using, again installed in Win10 (using Ceton Win8 drivers) but not passed through to Win7 VM. This necessitated my lucky finding of a used Ceton ETH network tuner, which then made this whole project actually possible to succeed. Without the Ceton ETH tuner it could not have worked.

And I feel it's been a 100% success story. The only minor conceptual difference in the Win7 VM WMC world stems from how OTA recordings using the Hauppauge tuner have to be made and viewed. VMWare doesn't pass through the PCIe tuner card and its drivers (installed in native Win10) to Win7 VM, so there's no way for Win7 VM WMC to see the Hauppauge tuner. My workaround here was to run NextPVR in native Win10 (which uses my Schedules Direct channel lineups from the same subscriptions I already had for EPG123), which supports the Hauppauge card in native Win10. The TS recordings from NextPVR (stored in a host drive folder that is visible to Win7 VM) are then viewed through the WMC extender running in Win7 VM, but as "videos" rather than as "recorded TV". Aside from that, these copy-freely TS files are still the identical MPEG-2 HDTV recordings previously made by WMC, and play and display normally through the extenders just as "videos".

What are you trying to accomplish/prove by having it run in two separate VMs? I can understand if those two VMs were on separate physical machines (that would mean you circumvented the DRM), but on the same physical machine, I am not sure what it gets you.
Actually, I wasn't really trying to accomplish anything with this experiment. I mostly wanted to learn how to "clone a VM" into a "duplicate", so that I could say retain a "master copy of a Win7 VM, fully installed configured and fitted out" and then any time I wanted to try something new just "clone it temporarily into a new test lab version" and use the clone to do the experimenting. Were there any consequences or limitations of this notion? Would it work? What was involved in the process? etc., etc. It was really mostly a VM learning experience.

But then I wanted to see if the cloned Win7 VM really was "identical" to the starting Win7 VM in all regards. The duplication process is really nothing more that COPY/PASTE for a "document folder" containing lots of stuff into a second folder, and then doing a File -> OPEN of that "primary document" (really a single VMX file in the folder, that defines the Win7 VM) from the second folder. It's really that simple. So I don't have to "build from scratch" a whole new second Win7 VM. I can truly just copy the master folder into a newly named second folder, and then just open the VMX file in the second folder and establish a new name for this duplicate Win7 VM (so that it appears uniquely in the list of "library" VM's available for me to select from the VMWare interface), and that's it. So, for example, if I had one "test copy-protected recording" in \Recorded TV of the master Win7 VM, could I use it in the cloned Win7 VM as I do "regression testing" to be sure that what I might be trying out does not break anything unexpected? And this sees to all work as I would hope, as both Win7 VM environments are really the same virtual machine, hardware and software.

Also, knowing as we do the strict DRM rules of WMC and copy-protected content and not being allowed to play copy-protected content on new machines, or new Win7 re-installs, I was curious to know if this also applied to Win7 VM and duplicates of that Win7 VM. Doesn't seem to, as they all truly appear to be the same Win7 hardware and same installed Win7 to PlayReady.

Now what I haven't yet experimented with at all is just how transportable the Win7 VM definition is, from one physical machine to a second physical machine. At the moment I only have one physical Win10 machine with "Intel virtualization" enabled and VMWare installed to even allow me to try all of this. I somehow can't see that the Win7 VM defined through this particular physical machine can be transportable to a second physical machine, because the Win7 VM guest itself is really seeing hardware on the host machine, as provided from VMWare to the VM. So that Win7 VM REQUIRES that hardware, same as it would on a real physical machine on which you installed Win7. Moving it to another physical [host] machine would mean that Win7 VM would likely no longer be provided with all the same hardware it was generated with drivers for, making it impossible to simply use it as-is.

On the other hand, if the second physical machine is actually the same hardware as the first physical machine, perhaps this would indeed work. Don't know, and actually it's not important for me to learn, since I don't actually have that need at the moment.

My need really was to decide if (a) I could and should move forward and convert my "production HTPC" environment to be a Win10 machine for everything else, while also running WMC in a frozen-in-time at end-of-life Win7 VM on that same machine if possible, or (b) should I segregate things and continue to run my real physical Win7 HTPC machine at the same frozen-in-time end-of-life state while also having a separate Win10 machine for everything else. I'm specifically doing this experimenting on a Skylake chipset ASUS Z170-Deluxe machine, which uses an i7-6700 CPU, all of which is still compatible for use with Win7. So this is the machine I'd stay with, although I could also convert my production Win7 HTPC which is a Lenovo M910t (also Skylake and also i7-6700 CPU) to do exactly what I've now accomplished on the ASUS machine.

I don't think I could do this on a newer generation physical machine that itself does not support Win7, since I don't believe it would be possible to install Win7 in a VM on such a machine... but then I don't truly know. On the other hand, if Win7 VM is supposed to be usable as a guest OS, no matter what the physical machine Win10 and VMWare is running on, how is that possible unless it's actually possible to do just that? And if Win7 can actually be installed in a Win7 VM on a Win10 host machine that is newer than Skylake, would it actually be possible to still have WMC run in this Win7 VM... on a physical host machine that itself would NOT be usable for Win7 for real? Now THAT would be something! At the moment I don't have such a newer desktop machine to try it with, but it would be very very interesting to see if it were possible. That way you could upgrade to modern hardware and Win10, and still run an "old Win7 VM" which would by itself not normally be usable on this modern hardware... and still run WMC on this modern hardware. What kind of CPU and hardware does VMWare present to Win7 VM, for installation of drivers etc. when you "install Win7" in that Win7 VM? Is it no newer than Skylake? How could it be, if Win7 isn't usable on hardware newer than Skylake? Good questions. I will perhaps try this if I ever do buy a new generation desktop..

And what I've learned from this project is that (a) is actually a very viable choice, with no apparent negatives or loss of functionality. It all works. Note that none of this invalidates what we already know about DRM and copy-protected content being playable only on the same machine and using the same installed Win7 that did the original recording. But practically speaking, it seems true that all cloned duplicates of one parent master Win7 VM are conceptually and truly that same machine with the same installed Win7 to WMC running in any of these Win7 VM clones, from the perspective of PlayReady. So copy-protected content made by WMC in one Win7 VM is eligible to be played successfully by WMC in another usable duplicate Win7 VM, as long as you pass along the necessary MSPR.HDS from the recording Win7 VM to the playback Win7 VM.

Space

Posts: 1580
Joined: Sun Jun 02, 2013 9:44 pm
Location:

HTPC Specs: Show details

#31

Post by Space » Sat Jun 15, 2019 6:24 pm

Nice! I just want to reiterate some things...
It appears that you can run Windows 7 in a VM on a Windows 10 machine and have WMC running on that Windows 7 instance and be able to record and playback DRM recordings.

However, there is a limitation that may be a showstopper for some, and that is that you are unable to play back the recordings on the machine itself, you need to use an extender to play back the recordings (I am unsure if this is all recordings or just ones with DRM). I believe this is due to being unable to establish a proper HDCP handshake with an HDMI device from within the VM.

Also, it is highly unlikely that you would be able to take the Win7/WMC VM instance from one physical machine and copy it to a second machine and have all your DRM recordings continue to be playable on that second machine.

jachin99

Posts: 1181
Joined: Wed Feb 24, 2016 3:36 pm
Location:

HTPC Specs: Show details

#32

Post by jachin99 » Sat Jun 15, 2019 8:08 pm

I just want to clarify that I have used a win 7 VM on a win 10 machine on 7th gen Intel hardware. So that shouldn't be an issue. I know forensic copies of operating systems have to be used in court and that's why I suspect one might be able to make an exact copy of a working machine. Now examining registry entries, files, etc on a copy and actually using that copy are two completely different things. I might look to see if there is a tool to make an exact forensic copy in an iso or some other compatible format

DSperber

Posts: 234
Joined: Thu Jan 16, 2014 1:35 am
Location: Marina Del Rey, CA

HTPC Specs: Show details

#33

Post by DSperber » Sat Jun 15, 2019 11:17 pm

Just a bit of further clarification regarding viewing live programs as well as recordings with WMC in Win7 VM.

Because the graphics adapter in Device Manager of Win7 VM isn't a genuine HDCP-compliant device (i.e. it isn't the actual nVidia adapter), but rather is a virtual graphics adapter provided by VMWare, this results in being unable to play copy-protected content on the display screen of the HTPC within the Win7 VM window. This is true for both live viewing as well as playing recordings and while annoying is nevertheless consistent.

But for some reason, copy-freely content also cannot be viewed when it is "live", wrongly producing the same error message about HDCP as you get from viewing true copy-protected viewing where it would at least make sense. Clearly for viewing unprotected copy-freely content the HDCP error is occurring incorrectly, but that's what happens.

Bottom line here is that you can't view anything live.

In contrast, you actually CAN VIEW RECORDED COPY-FREELY CONTENT!! Of course this makes no sense, since it's the same unprotected data stream as was rejected for viewing it "live". Why should you now be allowed to play a recording of it without any complaint? Obviously a bug somewhere, or just the result of running inside Win7 VM. Nevertheless that's what happens. You CAN play recorded unprotected copy-freely programs on the screen, so at least this part is working correctly even if you can't watch that same program "live".

And as stated, no issues whatsoever viewing live or a recording of both copy-protected and copy-freely content when you do it through an extender.

Space

Posts: 1580
Joined: Sun Jun 02, 2013 9:44 pm
Location:

HTPC Specs: Show details

#34

Post by Space » Sun Jun 16, 2019 2:56 am

DSperber wrote:
Sat Jun 15, 2019 11:17 pm
...
Obviously a bug somewhere, or just the result of running inside Win7 VM.
...
What you described is the same on a non-VM WMC that does not have a valid HDCP handshake. You get the "copy protection" message when you try to watch live non-DRM programming. Although if I recall correctly, if you minimize and then maximize the WMC window it will work again until you change the channel. Might want to check if it is the same in a VM. No amount of minimizing/maximizing allows you to watch a DRM protected recording, however. The fact that minimizing/maximizing allows you to view live non-DRM programming does seem to indicate that it was a bug.

DSperber

Posts: 234
Joined: Thu Jan 16, 2014 1:35 am
Location: Marina Del Rey, CA

HTPC Specs: Show details

#35

Post by DSperber » Mon Jun 17, 2019 10:46 am

Well, I was unable to overcome the inability to live-view unprotected content by minimizing/maximizing the WMC window inside of Win7 VM. However I was able to view an unprotected WTV recording in the WMC window inside of Win7 VM (i.e. using "Recorded TV" interface, not "Videos" to play TS recordings from NextPVR made in native Win10).

But honestly, this really isn't a major issue for me as I have extender/HDTV everywhere I want to watch TV, including in my office where the HTPC is. And I''d just as soon watch live/recorded content on my 55" LG OLED TV rather than on my PC screen in a window where it takes up real estate from whatever else I might be working on. Unlike the real physical Win7 machine where two monitors are present (one of them being HDCP-compliant for full viewing capability, both live and recorded) the Win7 VM situation is just a single screen. I don't know if you can establish a dual-monitor setup in Win7 VM, but again I have no real reason to pursue it other than for theoretical knowledge.

Now what I DID discover tonight was that that the second hard disk (SATA) which I defined to be my virtual 500GB Z-drive (placed on my 6TB physical host F-drive) on which I then set WMC to use as "recorder storage", that virtual second disk is actually much like an external USB drive in its usability by multiple PC's simply by plugging in the USB cable to each PC when you need it. In other words, I can use the same single virtual VMDK set of files and point to them in the two Win7 VM's I set up (one being a clone of the other). In other words both Win7 VM's are actually seeing and using" the very same "virtual-external Z-disk". So I can create content on the Z-disk with one VM (e.g. do a WMC recording) and that content is visible when I run the other VM. I don't actually have to have two separate 500GB Z-drives, one for each VM. I can actually have just one, used by both VM's as their Z-drive.

Of course if that recording made by one VM is copy-protected I'd need to make sure MSPR.HDS from that recording Win7 VM is copied into the other Win7 VM if I wanted to play it in that other Win7 VM, but that's no problem. So it's really possible to have an unlimited number of "clone" Win7 VM's each being WMC-enabled, and each capable of recording and playing back copy-protected content that any of the set of "clone" Win7 VM's has produced... as long as you manage MSPR.HDS properly between them all, but that just stands to reason.


Next up for me to find out is whether VMWare always provides a Skylake VM to a Win7 that you create, even if you're running on newer physical hardware which would not otherwise be acceptable to install Win7 on. For sure my current Skylake physical machine I'm using for Win10 is seen as a Skylake machine with the true i7-6700 CPU inside Win7 VM (using CPUZ to confirm). But then there's no issue here, because Skylake and i7-6700 CPU is perfectly acceptable for Win7. Memory seen by Win7 VM is "virtual" and graphics is "virtual", not reflecting my true physical machine hardware, but that's not as critical as chipset and CPU.

The issue is could I buy a current-generation brand new machine, that because of its current-generation chipset and CPU would otherwise NOT be usable for Win7, and install Win10 on it and then install VMWare on it and then install Win7 VM on it, and have it still look like a Skylake machine... which seems like it would be required in order for me to be able to install and run WIn7 VM under VMWare on a new Win10 host machine? If the newer hardware were actually passed through to the VM I would think Win7 Windows Update would not work. And besides, how could Win7 be installed if there weren't proper Win7 drivers available for this newer hardware which is in fact the case?

So you'd think VMWare would need to simulate a Skylake machine and CPU and other Skylake-level hardware to Win7 VM running on a newer generation physical machine, to guarantee drivers could be found and that Win7 install completed. But I don't know this for sure, since I don't have that hardware to play with. I will ask the people on the VMWare forum, and/or Win10 Virtualization forum. If it's truly possible to still run Win7 VM (even if simulated Skylake) on newer hardware which only Win10 supports then this is fabulous, given what I've now established for WMC being usable under Win7 VM. This means there is "eternal lifetime" for WMC, even if real Win7 is "dead to MS". It can live on forever (in its final "legacy" form with no further Windows Updates from MS) using EPG123 in the virtual reality of Win7 VM guest on any modern up-to-date Win10 host machine.

Kind of like "San Junipero" on "Black Mirror".

Post Reply