Robotic audio in Chromium browsers (Firefox, Kodi and Android work correctly)

[digitaltuner]

Did you mean play the uploaded video at around 9 minute mark in Firefox? If yes, then Firefox doesn't develop robotic audio. It only has a brief video breakup and a short audio chirp before recovering. Chromium browsers eventually develop persistent robotic audio. What I meant by robotic audio is heavily distorted audio. If needed, I can upload the screen capture of the playback with distorted audio.

Edit: Provide the link to the screen capture of the video with distorted audio anyway. https://1drv.ms/v/c/cf476e375d1f5006/IQA...Y?e=gQsEnk

[mvallevand]

No that is probably not the UI client test that I asked for but at least I understand (and still can't explain or duplicate your issue). I can duplicate different audio difference with Chrome and Firefox though.

A useful test might be to go to https://github.com/video-dev/hls.js and get a release zip and in there you will find hls.min.js Rename and update the older file that comes with NextPVR "C:\Program Files\NextPVR\wwwroot\js\hls.min.js"

Martin

[digitaltuner]

I have replaced the hls.min.js in the NextPVR folder with the downloaded hls.min.js from Github. I played the uploaded file and also watched live TV. Still have the robotic audio issue.

[mvallevand]

Thanks so there likely won't be a solution to this it seems related to your environment. The only other thing I can see is to edit player.html in the wwwroot folder and change the two new Hls() lines to

var hls = new Hls({debug: true});

Then watch the console logs for potential warnings and errors.

Martin

[digitaltuner]

I have replaced the two instances of var hls in the wwwroot folder. There seems to be no warnings or errors in the console logs (well, I know nothing about web interface development). I attached the console logs for your reference.

Edit: The console log was captured right after the robotic audio. Since I replaced the hls.min.js file and enabled the debug flag, the audio distortion happens more frequently.

[mvallevand]

You probably have to do a ctrl-f5 to see the new information,

Martin

[digitaltuner]

After pressing Ctrl-F5 and tested live TV for more than 2 hours, there was no robotic audio. I played the uploaded video again and no robotic audio neither. So I restart Edge and played the video again and bam, robotic audio happened again. It's interesting that the robotic audio didn't happen when we tried to debug them. For the console logs, there were dozens of warnings. I attached the console log for your reference.

[mvallevand]

I don't understand your test or the logs, when you sat you restarted Edge was the server side the same as what worked for 2 hours? That 20 minute log I see a few stalls but I am not sure what these are

hls.min.js:1 [warn] > [mp4-remuxer]: Injecting 7 audio frames @ 3495.357s due to 144 ms gap.

Martin

[digitaltuner]

No, didn't change any thing on the server side. After a no issue session of more than 2 hours of watching live TV and then the recorded video replay, I logged out. Closed Edge. Restart Edge. Login to NextPVR again and played the recorded video. Robotic audio happened. The log file is captured from the 2 hour session of watching live TV only. I haven't captured the log for the replay of the recorded video which has robotic audio issue after Edge restarted. If you need I can capture the console log of the recorded video again without pressing Ctrl-F5. However, I believe that there won't be any robotic audio if I press Ctrl-F5 and I have also uploaded the console log without pressing Ctrl-F5.

[mvallevand]

Ctrl-F5 only needs to be done once to replace the cached hls.min.js and player.html, it has nothing to do with debugging, that is always enabled now with the new Hls() setting

Thought we we looking at the robotic logs now I understand this was 9071.037 second. I wouldn't mind comparing it with the logs for a robotic session.

Martin