Here is the output:
Code: Select all
C:\Users\Darryl Sperber>ipconfig Windows IP Configuration Ethernet adapter Ethernet 2: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Ethernet adapter Ethernet: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::e938:529d:67a3:8acf%21 IPv4 Address. . . . . . . . . . . : 192.168.1.26 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.1 Wireless LAN adapter Wi-Fi: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Wireless LAN adapter Local Area Connection* 1: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Wireless LAN adapter Local Area Connection* 2: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : Ethernet adapter VMware Network Adapter VMnet1: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::bc44:2cc4:6732:bd6a%13 IPv4 Address. . . . . . . . . . . : 192.168.181.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : Ethernet adapter VMware Network Adapter VMnet8: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::210d:391f:524a:19e4%18 IPv4 Address. . . . . . . . . . . : 192.168.126.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : Ethernet adapter Bluetooth Network Connection: Media State . . . . . . . . . . . : Media disconnected Connection-specific DNS Suffix . : C:\Users\Darryl Sperber>
Interestingly, it actually DOES produce sound! Clearly not cloud-assisted "faux 5.1" sound, but genuine locally produced decoding of the AC-4 audio found in the ATSC 3.0 channel data (either live or recorded). It is being sent out the Roku to my AVR as "5.1 Dolby (MAT)", so it's not going out as 5.1 PCM. But nor is it going out as ordinary 5.1 AC-3. This transcoding to 5.1 Dolby (MAT) must be getting done by the Roku services that your Roku client (dated May 2020) is using. So the AC-4 support must truly be in this latest Roku.
Now my AVR can handle 5.1 Dolby (MAT), so that's not a problem. What IS a problem is that just as you first had to make a tweak to the LG (GUI) app in order for it to actually correctly inspect the now populated language indicator (finally present thanks to the two firmware upgrades for the Flex 4K itself) I suspect the same fix is needed in the Roku client. Only after you actually fixed the LG app did I finally see English 5.1 automatically detected from both live TV and recordings.
Well, it appears the Roku app has this very same defect as the LG app originally did. No testing of the language flag apparently, and it is simply always selecting audio channel #1, which is Spanish Stereo. So it plays Spanish from the very latest recording I have for "Two And A Half Men" which currently does produce English from the LG app. And it is only putting out 2.0 content into the 5.1 Dolby (MAT) stream to my AVR, which may be because it is starting from the wrong audio channel #1 which is only 2.0 to begin with.
Furthermore, this old clunky Roku GUI doesn't provide any SAP button for me to move to Englsih 5.1 which the LG app did have. In addition, the Roku app doesn't contain in its audio settings dialog any way to manually switch to either #1 or #2, so there's no way to get out of 2.0 audio.
If it were possible to fix the Roku app as you did fix the LG app, to properly investigate that now present and correctly populated language flag coming from the DVR/tuner engine, and to thus properly select audio channel #2 with its English 5.1, perhaps I would truly see correclty populated 5.1 Dolby (MAT). My AVR says that what it is receiving is truly 5.1 Dolby (MAT) but only L/R carry any real data. I suspect that if the starting point was from audio channel #2 and its English 5.1, instead of from audio channel #1 and its Spanish/English Stereo, that the output 5.1 Dolby (MAT) would truly have the original AC-4 5.1 audio now available as 5.1 Dolby (MAT) with all channels correctly carrying audio.
Is it possible to make that small fix to the Roku client, identical to what you did for the LG app, to use the language indicator properly? Seems that running on the latest Roku Ultra 4800 that old May 2020 version of the Roku client is "almost good enough to use", if only it could pick the correct English 5.1 audio track. Even though the GUI is clunky, it actually DOES WORK FINE... and actually uses the now present AC-4 decoder in the Roku Ultra 4800 to prodce 5.1 Dolby (MAT) output to the AVR. If only it had all 5.1 channels of data!
Anyway, I gave you the IPCONFIG output you asked for up top here. Nothing unusual shows (certainly not the 192.168.200.1 network for Ceton which appears in Win7). The VMWare networks are because I do have VMWare Workstation Player installed in my Win10 system. Note that my machine also has a second NIC inside, but there is no ethernet cable to it. So just the one ethernet network in use. And there is no VMWare network in the Win7 system.
Two years ago when Win7 was set to disappear in January 2020 I embarked on a project to run WMC inside a Win7-VM running on a Win10 host. The project was a success, although I was unable to make use of the internal PCIe Ceton card because VMWare didn't handle the drivers. But I was instead able to make use of a Ceton ETH network tuner (just like the HDHR Flex 4K). And since VMWare was capable of making the external network visible to the guests running inside it's VM's, I was able to configure WMC running in Win7-VM to make use of the network Ceton tuners, rather than using the PCIe tuners which it couldn't see. Again, the project was a success.
Furthermore, I was also able to utilize the Hauppauge quad-HD OTA/ATSC tuners in that same WMC running inside Win7-VM. Turns out Hauppauge provides native Win10 drivers (in support of WinTV which can run in Win10). So I implemented NextPVR (superior to WinTV) running in Win10, to handle the Hauppauge tuners for OTA/ATSC channels. And NextPVR recordings are TS files, which WMC treats as "videos" and therefore can play them. So my OTA/ATSC DVR was in Win10 through NextPVR. And its TS recordings were placed in a folder that was visible to WMC running inside the Win7-VM where the Ceton ETH for cablecard channels were managed by WMC itself. So although TS "videos" aren't handled by WMC as slickly as it handles WTV recordings, at least I did succeed in building support for both OTA/ATSC and cable channels through the one WMC running inside Win7-VM supported by VMWare Workstation Player (free for personal use). That was the project.
In the end I decided just to keep running Win7 forever, thanks to EPG123. I'll probably make a similar decision in 2025 when Win10 goes EOL, but I want to keep my existing Win10 machines that cannot be upgraded to a Win11 that I have no need for.