Emby thinks it needs to transcode audio files, but then doesn't!

[ChrisJ60 8]

We have a large library of music files. They are all M4A (MP4) files, mostly encoded using Apple Lossless (ALAC) but with a few AAC files here and there too. We play these via a variety of delivery systems without issue. This includes Emby for iOS and Emby for tvOS, where they play just fine.

Our Emby users are all set to not allow any sort of transcoding (I like to avoid that due to the load on the server) so anytime we try to play something that can't be played we get an error and then I can decide how best to 'fix' it. With the Emby app for LG Smart TVs I see weird behaviour for our audio files. If I try to play a file, I get the 'no compatible stream error'. Strange... So I click the 'Got It' button but the error just returns. Rinse and repeat. The app is stuck in a loop. This seems like a bug...

If I escape out of this using the 'back' button on the TV remote, I can still navigate around Emby but any attempt to play *anything* (including video files) just results in a black screen. I have to turn the TV off and then on again to recover Emby playback functionality. This seems like a bug...

If I modify the Emby user to allow just *audio* transcoding then the music files play just fine, but the server does not appear to be doing any actual transcoding; there are no ffmpeg processes running and the EmbyServer itself is using around 0.2% CPU. It seems like it just thinks the files need to be transcoded but then when it actually plays them realises they do not. This too seems like a bug...

 

[rbjtech 4223]

On the last item - Have a look at the logs -

if you see ffmpeg-transcode-X - for each playback then it is doing a conversion of formats - for Video, this will usually take a lot of CPU/GPU, for audio, much less so.

if you see ffmpeg-remux-X then it is simply copying into a container that works as a stream on the end device.  M4A is not an MP4 container - so it likely emby is remuxing these ?

It is however interesting to note that of the restrictions per user - 'Allow audio playback that requires conversion without re-encoding' (ie remuxing) is not there .. for video it is.

 

Edited July 4, 2020 by rbjtech

[Luke 37026]

Please see how to report a media playback issue:

Thanks.

[ChrisJ60 8]

32 minutes ago, rbjtech said:

On the last item - Have a look at the logs -

if you see ffmpeg-transcode-X - for each playback then it is doing a conversion of formats - for Video, this will usually take a lot of CPU/GPU, for audio, much less so.

if you see ffmpeg-remux-X then it is simply copying into a container that works as a stream on the end device.  M4A is not an MP4 container - so it likely emby is remuxing these ?

It is however interesting to note that of the restrictions per user - 'Allow audio playback that requires conversion without re-encoding' (ie remuxing) is not there .. for video it is.

 

Thanks for the tip; I should have looked at the logs instead of just seeing if there were any ffmpeg processes running. Seems it has to transcode ALAC files for playback on LG TV but not AAC ones. I guess that is reasonable. At least the transcoding doesn't use hardly any CPU so I'm okay with that.

BTW, M4A is MP4; they are identical, just a different file extension. You can rename them either way and everything still works (or not). Same for M4V, M4b and a few others.

[ChrisJ60 8]

@Luke Problem resolved, it was in fact transcoding. As for the other bugs, since I can avoid them I'm not going to worry about them for now.

[Luke 37026]

On 7/4/2020 at 1:52 PM, ChrisJ60 said:

@Luke Problem resolved, it was in fact transcoding.

Right well, if something isn't compatible then it will transcode. This by itself is not a bug, it just depends on what you're playing and what the device supports.