Error playing media, ensure that your player support it (Jellyfin Backend)

Issue description:

I’m having issues with playback of tracks (FLAC) from one specific album. I’m using Jellyfin as my backend and for some reason I always get this error when trying to play any track from that specific album. This issue is only happening in Symfonium. I’ve tried other apps connected to my Jellyfin and it works fine there.

When I try to play a track from that album, I get the following error:

Error playing media, ensure that your player support it

And then it will go through all the tracks in that album quickly and return the same error. Until it says:

Too many errors stopping playback.

I’ve seen other posts about a similar issue but I haven’t been able to fix it with any of those fixes. Specially since in my case it’s Jellyfin backend and not Navidrome.

debug.log (46.6 KB)

2023-10-18 19:56:36.515 T:ExoPlayer
playerFailed [eventTime=209.46, mediaPos=0.00, window=0, period=0, errorCode=ERROR_CODE_PARSING_CONTAINER_MALFORMED
u3.l: Source error
at u3.j0.i(Unknown Source:16)
at u3.j0.handleMessage(Unknown Source:391)
at android.os.Handler.dispatchMessage(
at android.os.Looper.loopOnce(
at android.os.Looper.loop(
Caused by: j3.m0: First frame does not start with sync code.{contentIsMalformed=true, dataType=1}
at g4.b.g(Unknown Source:503)
at z3.b0.b(Unknown Source:202)
at Source:42)
at java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.util.concurrent.ThreadPoolExecutor$

Seems the file is not standard and unsuported by ExoPlayer.

Please send me one of those files to reproduce.

Sent you a message with the file.

Ok thanks I can reproduce will see if I can find the ExoPlayer issue.

1 Like

So this is not an ExoPlayer issue the files are indeed invalid.

Even ffmpeg complains:

[flac @ 0000021902e6e1c0] invalid sync code
[flac @ 0000021902e6e1c0] invalid frame header
[flac @ 0000021902e6e1c0] decode_frame() failed

There’s a large block of 0 that should not be there. This can eventually be recovered by reading until finding the proper data, but while this might be acceptable for a local player, for an app that stream data this could mean that the app would read the whole file trying to recover even on files that can’t be recovered.

I’m sorry but I do think the side effects of workaround your invalid files are way too risky for other users to be added in Symfonium.

Thank you for your quick reply.

This is interesting, you mentioned risk and now I’m wondering what that entails exactly since other apps are allowing this? Are those apps “risky”? Also, do you have any idea what causes a FLAC file to be invalid in this way?

The risk is to read a whole file for no reason. Using tons of network data when not wanted and preventing fast fail, many people still have limited plans.

Afaik there’s no security risk over what security issues on the OS have.

And no I have no idea what could have added all those 0 in the file, but they are just after the tags I suspect a bug in the tool that wrote the tags, probably a failure to write the image (there’s none in those).

Thanks for the clarification.

Now that you mention image tags, I actually think that might be what caused this. I remember manually adding the cover image to these files using mp3tag and then I realised they already had an image so the files ended up having 2 cover images. I actually tried fully removing the images but that didn’t fix it.

I wonder if I fully wipe the metadata and start over if it will fix things.

Well you can easily try :slight_smile:

For anyone that faces a similar issue in the future,
Clearing metadata was not enough to fix the issue. I was able to fix it by using FLAC frontend and re-encode the file.