ATSC 3.0 audio upgrade - DSperber

[DSperber]

If you run "ipconfig" from a cmd prompt does it show a single Ethernet interface in Win10?

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>

Regarding the Roku, I have now installed the HDHR client app on my Roku Ultra 2020 (4800) which is that latest and greatest version available.

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.

[nickk]

Roku - you need to set your preferred language by going into Roku Settings > Audio > Audio preferred language

Edit - looks like Roku is not obeying the preferred language. We will file a bug with Roku.

Edit 2 - looks like Roku is only detecting the first audio track. This looks to be an issue with the Roku player.

[DSperber]

Roku - you need to set your preferred language by going into Roku Settings > Audio > Audio preferred language

Edit - looks like Roku is not obeying the preferred language. We will file a bug with Roku.

Edit 2 - looks like Roku is only detecting the first audio track. This looks to be an issue with the Roku player.

Thank you. But by "Roku player" are you referring to the "Roku Media Player" which is from Roku, not from Silicon Dust? Does that mean there is near-ZERO chance of this ever actually getting fixed?

But the truth is that the Roku app doesn't contain either an SAP button on its GUI, nor does it have a way to select/change audio track through its audio settings. It has other Accessibility settings relating to audio, closed captioning, etc., but the crucial one that would have allowed selecting one or the other imbedded audio track is simply not present.

Now this may be a derivative of the defect you've observed in Edit2 which is that it is always detecting only the first audio track so that there wasn't ever really a need to "change to the other track". If there only was one as far as it was concerned why would it ever need to "change to the other" if it didn't exist?

So, in defining the problem to the SD or Roku group responsible for the Player (assuming there is still such a group willing to respond to bug reports), the issue is really more extensive than simply fixing it to pick the correct audio track based on Audio preferred language. Really, there should also be either (a) SAP button to support this manual selection/toggle, and/or (b) Audio settings improvement to support this function to select the desired audio track pusing a text-based settings method similar to what is already in there for other items.


Anyway, whenever there is an updated Roku app version (either beta or officially released) I would be glad to beta-test it for you to confirm that it works as intended.

thank you again.

(Any more thoughts on how we can get to the bottom of what's happening with the LG app not connecting with the DVR on second and subsequent launch? Is there a mandatory reason why multicast was used for the LG app and no other? You said all the other apps use broadcast, and they work 100% perfectly in connecting with the DVR. Why can't the LG app do the same? Seems like that would just FIX the problem, and we could forget about further chasing of the multicast issue entirely. Is this even possible?)

[nickk]

Thank you. But by "Roku player" are you referring to the "Roku Media Player" which is from Roku, not from Silicon Dust? Does that mean there is near-ZERO chance of this ever actually getting fixed?
Problem seen in both the Roku Media Player channel and the Roku Media Player component the HDHomeRun app uses.

So, in defining the problem to the SD or Roku group responsible for the Player (assuming there is still such a group willing to respond to bug reports), the issue is really more extensive than simply fixing it to pick the correct audio track based on Audio preferred language. Really, there should also be either (a) SAP button to support this manual selection/toggle, and/or (b) Audio settings improvement to support this function to select the desired audio track pusing a text-based settings method similar to what is already in there for other items.

First the Roku Player needs to support multiple audio tracks for a DLNA style MPEG-TS stream.

Next we need to get some clarification as to how the user should change tracks. From the Roku documentation - "It is recommend that channels use the audio track selection logic provided by the Roku OS instead of implementing their own."

(Any more thoughts on how we can get to the bottom of what's happening with the LG app not connecting with the DVR on second and subsequent launch? Is there a mandatory reason why multicast was used for the LG app and no other? You said all the other apps use broadcast, and they work 100% perfectly in connecting with the DVR. Why can't the LG app do the same? Seems like that would just FIX the problem, and we could forget about further chasing of the multicast issue entirely. Is this even possible?)

LG does not allow apps to send broadcast packets. We are working on enabling an alternative detection approach for DIY record engines.

[DSperber]

So where do we stand? Is anything currently in-progress, as far as the several problem issues which are absolutely still outstanding right now?

===================================

(1) LG client app only succeeds in connecting with RECORD on (a) first launch after Windows boot, or (b) first launch after STOP/START of RECORD service. After that first successful connection, any further power-off/power-on and re-launch of the LG app results in NO DVR.

And then after a failure, a simple repeat of the STOP/START of RECORD service trick successfully resets and initializes whatever (inside of RECORD) that is the underlying cause of the problem. And now the next launch of the LG app once again connects perfectly.

You are unable to reproduce my failure using your setup, and I am unable to get any other results than what I describe above... using both C7 and C9 TVs on my home network, and using both Win7 and Win10 for RECORD. I use Netgear R7800 Nighthawk router with Netgear GS108 and GS105 unmanaged switches. I don't know what equipment you are using.

But the 100% technique for overcoming the failure (at least for the one very next launch of LG app) by STOP and START of the RECORD service seems to point indisputabley to a problem with RECORD. Obviously multicast did "work" for the first connection from LG client, with all initialized tables and variables inside of RECORD. But something then populated in those tables and variables as a result of the first connection, and therefore remaining RESIDUALLY when the second connection attempt arrives (assuming it is actually seen and heard by RECORD) must clearly be driving RECORD to follow a different logic path. And this is why the second and subsequent connection attempts fail, because of this residual data left over from that very first connection which was successful.

Simply STOP and START the RECORD service, which "clears out and reinitializes" all table entries and variables... like magic, just like a real Windows reboot... the next launch of LG app once again works perfectly!!

How can you not agree there is some kind of a problem inside of RECORD? Do you have any ability to diagnose what it sees, or is doing, or what logic path it is following? Do you not have a "verbose logging output" mode of operation, for debugging while it was in development??

This is really really important to fix because the LG TV actually has a built-in AC-4 decoder so that its GENUINE AC-4 audio transcoded into AC-3 audio and then sent to my AVR as AC-3 is wonderful to listen to. I only wish I didn't have to constantly STOP/START the RECORD service in order to facilitate that every time I walk into the room and power the TV on to watch something.

==========================================

(2) Newly discovered that the Roku Ultra 2020 (4800) contains built-in hardware AC-4 decoding support, that actually gets used by the "abandoned" May 2020 Roku HDHR client app to deliver sound!! It is actually AC-4 audio transcoded into Dolby (MAT) sent to my AVR (which can handle it). So just like with the LG app (and unlike all the other client apps that operate on devices without native AC-4 codecs so that you must use your cloud-assisted technique which is undesirable) the Roku app running on the 2020 Ultra CAN provide true support for AC-4 audio.

Unfortunately apparently the Roku Player that you use to get the sound handled is itself defective, and is not even aware that there are two audio tracks inside the MPEG-TS stream, in order to then be able to select whichever one is English 5.1... if it was ever even designed to use the language flag in order to choose correctly. But perhaps that is just the job of the HDHR app that invokes the player, to invoke it correctly... if such capability even exists.

Anyway, it's unfortunate that the hardware AC-4 decoding required is actually now inside the 2020 Ultra, although the supporting software does not correctly handle the two Spanish vs. English audio tracks that must be selected from correctly. And if the fix involves writing up a trouble ticket for Roku and expecting it to ever get fixed, well good luck to that.

Unfortunate. The Roku app circa 2020 seems clunky and dated in its GUI. But I could live with it, if only it would play the English 5.1 audio through its hardware AC-4 decoder it really could be usable as an alternative, since in myhouse I also have other Samsung TVs (not LG OLED) supported by Roku Ultra 2020. So if only the Roku app could play the correct AC-4 audio track I could actually use the HDHR Roku app for ATSC 3.0 channels on those Samsung TVs and get genuine proper 5.1 audio.

=======================================

(3) Thread posted in the "Support" forum titled: "Why is the HDHomeRun App so crappy on LG WebOS? - ndwilsey" which also complains about "I am unable to access any of the recorded material stored on my Synology NAS." Sounds awfully much like my own problem with my LG app being unable to connect to RECORD except once (per Windows boot, or per STOP/START of RECORD service) before failing forever after that.

Again, a multicast problem that could be exactly like I'm experiencing?

=====================================

So, are any or all of these still "cooking"? Do you have a plan regarding resolving them?

Is there anything I can do to help? Any special debug versions of anything I can install in order to generate any forensic diagnostic output you'd like to look at?

There has to be an explanation for these problems, and that must be in software bugs somewhere. The challenge is to hunt them down and find them, and then to code a fix. I'm at your disposal.

[nickk]

LG - as noted in my previous post we are porting a fallback discovery method for DIY record engines to the LG platform. Good chance it will be done this week.

Roku - we can't work around Roku not supporting multiple audio tracks - Roku have to fix their player before audio track selection will work. Now it might be possible to have the HDHomeRun firmware mess with the track order but that has to be reviewed carefully.

[DSperber]

LG - as noted in my previous post we are porting a fallback discovery method for DIY record engines to the LG platform. Good chance it will be done this week.

Roku - we can't work around Roku not supporting multiple audio tracks - Roku have to fix their player before audio track selection will work. Now it might be possible to have the HDHomeRun firmware mess with the track order but that has to be reviewed carefully.

Excellent news on that first topic. That's really the one I care about the most since my two LG TVs are both connected to AVRs for external multi-channel sound. So just getting the LG to produce the transcoded AC-3 audio 100% live or recording no matter when or where, that would really be fabulous. I await anxiously something for me to try.

But at least for the time being I have the simple manual STOP/START of RECORD service trick that "works". So at least I don't have to reboot the PC every time in order to play a recording through the LG and get great sound from my AVR/speakers.

On the Roku, I understand you're at the mercy of their player's underlying problem. Or, a clever trick in the firmware, as you suggest. But in all honesty the Roku storyis really of much lesser significance to me. I only just encountered it because I had thought the HDHR Roku app was "unusable", but was told otherwise on AVS Forum. In fact I was told it was putting out PCM to an externally connected Yamaha AVR. I couldn't believe it, but gave it a try, and discovered that it actually WAS operational. Of course it was really putting out Dolby (MAT) and it looked like 5.1, but it only had two L/R channels of content populated. As I suggested previously, most likely it was because it had picked up the SAP Stereo audio channel #1 which was why it only pushed L/R into the 5.1 output.

But nevertheless, making the HDHR app work properly on ANY client device which actually does have built-in AC-4 hardware/firmware support should be pursued as a more desirable approach than using the cloud-assisted transcode of AC-4 to "faux 5.1" (which, honestly, does not sound great).


Please let me know whenever there is progress on either front, and if there's something you want me to try.

Many thanks.

[DSperber]

Why do these 5000-serious extraneous channels 5001, 5002, etc. keep appearing? More and more of them every few days. I X them out manually but more of them keep reappearing!



Furthermore, there is something not quite right with the GUI (in HDHomeRun Configuration GUI -> Channel lineup) insofar as wanting to "X" out an unwanted channel. The first time you click on the empty radio button on the left side of the channel row it changes to yellow. I think that may be "favorite"? And then the second time you click on the now yellow button it changes to a red X, indicating you don't want it to appear in your Guide. All well and good.

However the GUI seems broken, in that you can't just click as many times as you want on as many channels as you want, getting rid of say the just appeared 15 new 5000-series channels. Unfortunately only one click at a time "works" (i.e. changing the empty radio button to yellow, or changing the yellow radio button to red X). After than no clicks seem to register or have any effect. You must instead click on the HOME button to reset things, then click on "Channel Lineup" again, then scroll down to that area of channels you're working on, and perform just the one next click you wanted to do. That one and only one click registers, and then again the GUI becomes inoperative, and you have to "rinse and repeat" for 10 minutes, one click at a time, until they're all red-X like I want.

Anyway the real issue is where are these 5000-series channels coming from, and why to they self-generate spontaneously every few days, more and more of them? I continue to have to red-X them once I notice that they've appeared in the onscreen Guide. They are NOT real channels.

[DSperber]

Nick,

Again, what are those fictitious channels 5002 and above being seen and activated in my channel lineup by the Flex 4K?

I keep red-X'ing them, and more keep coming back.

[nickk]

Nick,

Again, what are those fictitious channels 5002 and above being seen and activated in my channel lineup by the Flex 4K?

I keep red-X'ing them, and more keep coming back.

Usually they are caused by very weak / out of range channels. Please turn on "send diagnostic information" by going to http://hdhomerun.local/system.html

Nick

[DSperber]

Please turn on "send diagnostic information" by going to http://hdhomerun.local/system.html

Nick

Done. I turned it on with HDHR Setup -> Advanced.

Device ID: 10A236FF

At this moment it goes up to 5021 as shown in my image above. So no extraneous channels for a few days now. But we shall wait and see.

[DSperber]

Nick,

I just installed the latest official release of Windows software/firmware (dated 20220126, not a beta). The firmware was upgraded and shows 20220126.

There is no changelog anywhere that I know of so it's not obvious to me what I should be looking for that may have changed or been fixed in this release from today. Is there something specific I should be looking for or confirming that is now working whereas previously it was broken or worked differently? A "release notes" published in a "sticky/pinned" forum post whenever a new beta or official release becomes available would be very helpful to users.

But for absolute sure I can report that there is no change in the behavior of the LG app, and its apparent continued use of the "failing" multicast approach for contacting the HDHR RECORD engine. In other words the LG UI app is still dated 20220113 and still only works on the first connection attempt after a Windows boot, or after a STOP/START of the RECORD service. So I'm guessing the DIY-method change being adapted for use by the LG app that you had mentioned last week is still not ready for prime time, or for my beta testing.

So no change in the LG app behavior. Any further status update on its progress, and possible ETA?

However I did just check the HDHR Configuration GUI channel lineup, and sure enough one new channel has now appeared: 5022. I don't know when it appeared but it's there now.



I had previously turned on the "send diagnostic information" switch, so whenever this new channel 5022 appeared if you look at your history of information from my PC hopefully there will be some mention of the appearance of this 5022.

[nickk]

So no change in the LG app behavior. Any further status update on its progress, and possible ETA?

UI release is expected later today. The release includes the secondary detection mechanism for DIY record engines on LG TVs.

Nick

[DSperber]

UI release is expected later today. The release includes the secondary detection mechanism for DIY record engines on LG TVs.

Nick

(1) As of early morning 1/28 there is still no change to the LG app. It is still 20220113c (UI). I've deleted it and re-added it, but no change. And that means it still does NOT find the DVR RECORD engine device. I'm still anxiously awaiting this to get fixed with the new UI release but so far it hasn't happened.

(2) I've also made a pass through my devices and versions of whatever is on them. Again, I've deleted and reinstalled so presumably it is the latest version of everything. But because this seems to all be under my manual control, rather than automatically just happening (unless I'm wrong), can you please confirm that each of the items below IS the correct latest and greatest version. You can just tell me if any of them is NOT, and i'll assume the rest ARE:

Win10 app: 20220124 (app), 20220113c (UI)

DVR HDHR Config GUI -> firmware 20220125
DVR HDHR Setup - 20220126

ATV4K: 20220124 (app), 20220124 (UI)

Shield Tube: 20220126 (app), 20220113c (UI)

LG: 20200923 (app), 20220113c (UI)

ROKU Ultra 2020 (4800) - with built-in AC-4 support that should be utilized locally to decode AC-4 - still 20200504 (you've previously explained that this needs f fix from Roku for the Roku Player in order to recognize audio tracks other than #1, and how the app can request the player to switch audio tracks to #2)

(3) You didn't respond about that new "nothing channel 5022" that I showed in my screenshot above had appeared just in the past day or two on my tuners. Since "send diagnostic data" was enabled when this happened, presumably you can see some trail or breadcrumbs corresponding to whenever this happened. I'm just trying to either fix whatever at my end might be causing this, or have you fix something in firmware/software to make it stop, or maybe just to explain what it is and that there is no way to prevent it from happening (which of course doesn't make any sense to either of us, I hope).

[nickk]

The UI update was not released yesterday due to an issue found in a unrelated feature. I will post when it is released.

5000+ channels - can you please do a 30s capture of ch545000000:
http://10A236FF.local:5004/auto/ch545000000?duration=30