Error on playback of MP3 file

Issue description:

When I want to play one specific song I get the error (in german): “Fehler beim Abspielen, Format vmtl. vom Abspielgerät nicht u…”. Navidrome can play this song without problems.

Logs show this error:

2023-11-12 13:28:16.369 Error/ExoPlayer: internalError [eventTime=47.28, mediaPos=0.00, window=0, period=0, loadError
  i4.x0: None of the available extractors (b, d, l, o, a, e, d, e, d, e) could read the stream.{contentIsMalformed=false, dataType=1}
      at wp.b.w(Unknown Source:189)
      at i4.g0.i(Unknown Source:127)
      at l4.l.run(Unknown Source:36)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
      at java.lang.Thread.run(Thread.java:1012)
]

Is this a Symfonium error or is this specific mp3 file corrupted? I already deleted the local cache for this file and redownloaded it. Error persists.

As always: thanks for your help Tolriq!

Logs:

debug.log (95,7 KB)

Additional information:

Symfonium Version 6.0.0 (1148)
Navidrome Version 0.49.3 (8b93962f)

The file is not standard for sure, I’ll need it to see if I can add support or workaround whatever issue.

So TL;DR; provide the file :slight_smile:

Hi Tolriq,

how can I provide you with the file? I’m assuming that I can’t and shouldn’t upload files with copyright in this forum, right? Will an encrypted 7z file suffice if I send you the password via PM?

You can send by mail but you can upload here and I can delete after, you can send the file directly in pm too.

Ok, here is the file: —

Thanks, so yes the file have all the possible TAGs of the universe in it :stuck_out_tongue:

I’ve added a temporary workaround and reported ExoPlayer to see if there’s a proper fix for your files.

What do you mean by “the file have all the possible TAGs of the universe in it”?

This is what I can see with Mp3tag 3.23. MediaMonkey shows the same.
image

If the error is caused by some hidden tags I’m fine with just removing them :slight_smile: But how?

There’s 2 ID3 tags at the start of the file and APE tags at the end.

That’s the 2 ID3 tags that causes issue. The second one have the image in it. What you see is the first one.

I don’t know how to cleanup the file, but next release will have a woarkaround.

Okay, thanks for your help! :slight_smile:

When I stumble upon files with weird tags (usually mp3s) I open them in mp3tag and either go:

Right click → Tag Cut, Right Click → Tag Paste (this removes the tags from the files and then reapplies them (and it only reapplies those that are properly detected by mp3tag, thus getting rid of problematic tags).

Or you can go:
Right click → Remove Tag. This deletes all tags from the files and then you can undo the action by pressing Crtl+Z or clicking “Edit → Undo”. In this case also only supported tags will be rewritten to the files.

If this step does not resolve the issue I’d suggest taking a look at Mp3Diags. Mp3Diags displays errors in mp3 files and can often also resolve the issues.
Be careful tho. Some of the actions it can perform are destructive by nature so back up your files before you attempt to fix them with it.

Good luck. :smiley:

1 Like

Hey @655321,
thanks for the tip! Unfortunately, it doesn’t work. The error still persists.

Apparently Mp3Tag does not remove the bad tags, because I have noticed that Navidrome shows me completely different information when I have deleted all tags with Mp3Tag (Right click → Remove Tag), but have not yet reinserted them (Edit → Undo).

But it’s interesting that Navidrome can read these “bad” tags.

It seems I have to wait for Tolriq’s workaround

The tags are bad in the sense that’s there’s multiple ones at the start and it’s not normally allowed, tools that just scan all for ID3 can see both and handle them.

But each ID3 tags are valid by themselves.

The issue is that ExoPlayer sniff the files to see what format it is, it does not assume the file extension is right. And the 2nd bad tag is not seen as tag so is not skipped and so the sniff does not go far enough to find the starting frames.

It’s reported to ExoPlayer too, not sure if they will address but my workaround should work for this files and similar ones.

Hi Tolriq,

the added workaround in release 6.1.0 works great! Thank you!