Help & troubleshooting for channels on your Roku device, including adding/removing channels, logging in to, authenticating, or activating a channel, channel-specific playback issues, assistance contacting channel publishers to report issues, and adjusting channel-specific settings.
I've seen other posts that indicate Roku media player has loud buzzing and/or clicking/cracking noise on some videos and I've seen the suggestion on bitrate etc., but this is definitely a bug, not an issue with the video file and I have many dozens of video file with this problem while others play fine. Here's why I KNOW this is a bug. I have a lot of DVD's and personal videos that I have digitized and have put them on my DLNA server. They all played fined until I started adding more and more.
So I started playing around with one of the files to see if I can fix the problem Let's say for example I had a video file called Test.m4v. A few months ago it was playing fine. Now when it starts with a loud buzzing/clicking noise. If I let it play I can barely here the audio under that loud noise. First I suspected my DLNA server, which I had built on a Raspberry PI so I switched to the commercially built one by Western Digital, which has been working fine for years, but the OS disk is going bad. That one has the same issue.
Next I suspected the file may be corrupt so I used the Samba network connection to the my PI server and played that exact file on my Windows machine via VLC. The file plays fine with perfect sound.
I then used a program to shrink the file size, which would also rebuild the video/audio at different bit rates. The new file plays fine on PC, but not on Roku Media player when being streamed from either one of my DLNA servers.
Next I played the same exact file with the buzzing noise on my GE Smart TV and the file plays perfectly.
This last step convinced me that the bug is indeed with Roku Media player, which BTW I have the latest as I un-installed and re-installed it (version 5.5 build 9). Also keep in mind we have three different Rokus, including a Roku stick and a Roku Ultra 4K HD and they all do the same. The last step I performed was to convert the file to MP4 format and reduced the size. The file plays fine on PC. I uploaded it to my DLNA server and the new file, let's say Test.mp4 plays horribly with the loud buzzing/cracking noise. However, now the old file which had problem (Test.m4v) plays without any issues whatsoever. Checking the info on the two file through the Roku Media player I can see the old file has a date of 2011 and the new one has today's date.
Re: Roku Media player has a bug and I can prove it
Good analysis. Let me add a few observations as I've been looking at this (and awaiting some solution) for several weeks. I can't comment on .m4v's, but I have tried a number of test files as .mp4's and .mkv's.
- I have 2 streaming sticks. One is connected to a tv that can decode DD and DTS. The other is connected to an old tv that can only deal with pcm. One stick is current with OS 10 build 4208. The other is still on OS 9.4 because I've blocked it from the internet. Both have RMP 5.5 build 9. - all .mp4's and .mkv's are built containing .h264 video. Most are AC3 (Dolby Digital 5.1) audio. Some are AAC (Dolby Surround) audio. - all files played fine under OS 9.4 and continue to do so on the un-updated stick. As the old tv requires a pcm input, the stick is obviously transcoding both DD and DS to PCM without issue. - under default stick configuration, the stick with OS 10 no longer properly plays (pops/clicks) files with DD encoding. DS encoded files play fine. It is no longer properly transcoding DD (AC3) audio. - on the TV capable of receiving a DD/DTS signal, I have had some amount of luck changing the AUDIO/HDMI selection to "DD, DTS". Under this setting, DD encoded files that result in pops/clicks under "AUTO", also play fine. This change does not improve the playback on the TV that requires PCM. This leads me to believe that something is different under OS 10 in how Roku reads the HDMI handshake and acts on what it determines the playback device is capable of.
Based on the above, I've laid the problem on the OS 10 rollout and not on RMP as the RMP version is unchanged between the two sticks, but that may be a false observation and I'd welcome additional tests/observations. Also, others have reported occasional audio dropouts. I have no test cases on this as I have not experienced it.
The Roku documentation is not really clear what amount of transcoding various Roku models are *supposed* to be capable of. I can only base my observations on what my Roku model did before under 9.4 vs. what it does/does not do under OS 10. I'd welcome the documentation being more clear.
As to RMP, there are at least a couple of issues I've been able to define:
- Audio track selection differs between .mp4 and .mkv. For .mkv files, if the file contains both a DD and a DS audio track, RMP selects the track identified in the file as "default", so a file *can* be built with a default DS track and an additional DD track that will play without pops/clicks. For .mp4 files, if the file contains both a DD and a DS audio track, RMP selects the DD track, regardless of the order of the tracks and regardless of which is defined as "default", so it is *not* possible to build a file that will play without pops/clicks. - RMP doesn't enable manual audio track selection for either file. That option is grayed, which is problematic if you happen to have a file with, say, a base audio track and an alternate like a commentary. Others have said that track selection is enabled if both tracks are DS, but I have not tested this.
I've had a support ticket open for more than a month on this, but have heard nothing on it so far. I loaded build 4208 on the one stick yesterday. That latest build did *not* address the issue. I hope we'll get an update at some point on this, given the number of comments it's generated.
@RokuDanny-R , it would be helpful to see a separate community category for playback of local content. The issues dealing with local content are somewhat different than those dealing with streaming playback.