Search the Community

I have two MKV files that I stream from a Windows emby server to a Raspberry Pi HTML5 client. One of them has perfectly fine audio, while the other has highly distorted audio (like if it was amplified 10 times, then compressed). The audio is distorted only on the Raspberry Pi client. If I read the same video on another client (Android app, or windows web client) the audio is perfect on both files. The Raspberry Pi client uses Chromium 65.0.3325.181 Built on Raspbian , running on Raspbian 9.8. Here are the specs of the file that does not distort the sound Here are the specs of the file that does distort the sound Server configuration : Version 4.1.0.26 (Windows) Dlna (1.0.12) Is there any well-known issues regarding MKV files with distorted audio on specific platforms ? I've seen several threads about this, but it was on Roku (https://emby.media/community/index.php?/topic/28067-audio-distorted-when-playing-1080p-mkvs/) and I'm using the HTML5 client.

Hello, Sorry to dig this one up from the grave, as another thread indicated this issue was solved, but I'm afraid the answer given doesn't address the underlying issue. Essentially, it seems that the Roku app defaults to the primary image when browsing unset (mixed content), but uses the proportions for a thumb image. Unfortunately, as this thread below indicates, I don't think this is simply a matter of unset (mixed content) view vs. content type view. https://emby.media/community/index.php?/topic/55693-thumbs-as-primary-photo/ This actually seems like a bug and here's why: When using the Emby app on my TCL Roku TV, when viewing a mixed content library, the application defaults to the thumb view and there's no way to change it. This isn't ideal, as I think most folks would prefer a choice like in other libraries, but let's put that aside for a moment. I think most folks that can swallow the fact that you cannot discern the content type and thus automatic metadata population is limited or nonexistent in this view. Frankly, the only time I would use the a mixed content view is if I was providing the metadata myself (i.e. Home Videos). If I want it to automatic metadata population from some online source, I'll set the content type as appropriate. In short, it's not an issue of knowing what type of content is there. The Roku app appears to be programmatically looking for image set as the primary image. I can live with that. The issue lies in the fact that when it uses the primary image, it then constrains it to the dimensions of the thumb image, distorting the final product. It just seems to be a simple mismatch. I can prove this simply by "fixing" a few items by setting the primary image to an image with the dimensions/proportions of a thumb, such as 1280px x 720px. Though an obvious band-aid, this indeed resolves the issue on the Roku. But now, that same image is FUBAR everywhere else because it get's stretched to the dimensions of a primary image in apps such as Emby Theater or LG WebOS, which are using the proper dimensions. The fact that the LG WebOS app works properly but the Roku app does not indicates to me that this is likely just a bug. Long term it's definitely desirable to have the option in the individual apps to choose the image style (primary vs. thumb vs. banner, etc.), as has been previously hashed. Until then, it would seem the straightforward fix is to just have the Roku app either use thumb image and use the correct dimensions/proportions for a thumb OR use the primary and use the proper dimensions/proportions for a primary image. Hope this makes sense, I can follow up with images to demonstrate the issue if necessary. Server: Version 3.3.1.0 Roku TV: TCL P605, Roku Version 3.0.74 Thanks! Bill