Clementine / Strawberry issue with wma files

Hi. I made a fresh install of Manjaro KDE Plasma about 1-2 months ago. I have tried to install and use Clementine and Strawberry audio players. In both of them, when I play a wma file, it plays until it’s close to the end then the player skips the last 4 or 5 seconds of the file and brings an error message written “Could not decode stream”. It happens in both, Clementine and Strawberry.
I checked my package manager and I have installed gst-libav, gst-plugins-bad, gst-plugins-bad-libs, gst-plugins-base, gst-plugins-base-libs, gst-plugins-good, gst-plugins-ugly, gstreamer, gstreamer0.10, gstreamer0.10-base, clutter-gst, lib32-gstreamer, lib-gst-plugins-base-libs, manjaro-gstreamer and phonon-qt5-gstreamer.
I googled a lot about it and found no solution, except that in old Ubuntu versions they recommended installing gstreamer-ffmpeg, what I can’t do now, because the only available version is from AUR and it aborts building before finishing on my system.
Can you help me solve this issue? Thanks.

Not the solution but have you tried the flatpak or snap versions? With clementine only the snap version would stream from my GDrive for some reason (probably contains missing dependencies)

I tried the flatpak version and it doesn’t even play wma files. When I try to play a wma it says your Gstreamer is missing a plugin. I just didn’t try the snap version because in my previous linux installations snaps took significant seconds of boot / startup, then I decided not to use them anymore. But I tried an appimage of Clementine, 1GB size, that I found somewhere online and it works. The only setback of appimage is that I can’t make it behave like single instance as it does when it’s installed on my system. If I have used Clementine appimage and it’s stopped and then I launch another file from file manager another instance of Clementine opens, instead of adding to the playlist. And, of course, I can’t keep the appimage up-to-date because it’s third party compiled.

Doesn’t strawberry supercede clementine? It’s the active development fork of the former.

What happens if you launch strawberry from the terminal, and let it “crash” on the WMA file? Any output messages?

What happens if you try to play the errant WMA files with ffplay? Does it crash around the same part of the track?

ffplay -i MySong.wma

You can use the mouse right-click to skip to different parts of the song, depending on where you click on the window. So clicking in the middle of the skips to the halfway mark. Clicking near the right side puts you near the end of the track.

tried just now with few WMA files i have, and yes there is some issue right at the very end of each track and it skips to the next track in the playlist. the following errors were dumped;


20:15:40.421 ERROR GstEnginePipeline:1144 ErrorMessageReceived ID: 1 Domain: 3980 Code: 7 Error: "Could not decode stream.
20:15:40.421 ERROR GstEnginePipeline:1145 ErrorMessageReceived ID: 1 Domain: 3980 Code: 7 Debug: “…/gstreamer/subprojects
/gst-plugins-base/gst-libs/gst/audio/gstaudiodecoder.c(1589): gst_audio_decoder_finish_frame_or_subframe (): /GstPlayBin:pipeline-1-
pipeline/GstURIDecodeBin:uridecodebin1/GstDecodeBin:decodebin3/avdec_wmav2:avdec_wmav2-2:\nReceived decoded subframe, but no pending
20:15:40.421 ERROR GstEnginePipeline:1144 ErrorMessageReceived ID: 1 Domain: 3980 Code: 7 Error: "Could not decode stream.
20:15:40.421 ERROR GstEnginePipeline:1145 ErrorMessageReceived ID: 1 Domain: 3980 Code: 7 Debug: “…/gstreamer/subprojects
/gst-plugins-base/gst-libs/gst/audio/gstaudiodecoder.c(1589): gst_audio_decoder_finish_frame_or_subframe (): /GstPlayBin:pipeline-1-
pipeline/GstURIDecodeBin:uridecodebin1/GstDecodeBin:decodebin3/avdec_wmav2:avdec_wmav2-2:\nReceived decoded subframe, but no pending
20:16:12.108 DEBUG GstEnginePipeline:677 2 event seek
20:16:12.109 DEBUG Player:738 Track seeked to 284000000000 ns - updating scrobble point
20:16:12.143 DEBUG GstEnginePipeline:677 2 event latency

you can report this at; Issues · strawberrymusicplayer/strawberry · GitHub

if you cant i’ll be happy report.

Does the same thing happen when using ffplay (pure FFmpeg) to decode the WMA files?

ffplay did play the WMA files in its entirety, but the seek time just kept going without ending well past the end of track. no errors were thrown.

That’s normal for ffplay.

So it sounds like this issue is very likely due to Gstreamer and Windows Media Audio.

In the meantime, @fernandoamartin, is there a reason you’re using WMA?

There are better formats, such as:

  • OPUS ← my favorite lossy audio codec
  • AAC
  • Vorbis
  • FLAC ← lossless
  • ALAC ← lossless

I’m grateful to all of you who have been suggesting solutions and testing them. I regret having ripped some cd’s in wma back in my Windows days. But now I don’t have access to all the discs from which extracted the wma files, something I did with the highest possible quality. I am not sure if I use wma as source flies to decode to another format I will get the same quality or if I can have more losses while decoding to another format. That’s the underlying issue.

The error occurs in both Strawberry and Clementine. But if you can report it to Strawberry team I’ll be grateful.

ffplay is able to play the whole track just like Elisa is. I just can’t use Elisa because I need some config option available only in Clementine and Strawberry.

I feel your pain. If only we had the foresight to know back then about what the future would hold in terms of options, open source, and storage capacities.

One thing you can try is to convert one of the files to FLAC (lossless), and compare how much larger it is to your WMA file. Sometimes FLAC can be 10X larger than an MP3 or AAC. :open_mouth: However, in your case, you mentioned you used a high quality setting when you originally ripped it in WMA.

ffmpeg -i "Name of Song.wma" -acodec flac "Name of Song.ogg"

Then compare the two sizes. You can try again with a higher compression level, but normally the FLAC defaults are the best tradeoff for speed and size.

ffmpeg -i "Name of Song.wma" -acodec flac -compression_level 9 "Name of Song.ogg"

I would leave it at the default, since even though a higher compression level reduces the size, it’s such a marginal amount that it’s not worth it. Up to you.

No matter which compression level you use, FLAC will always be lossless. The destination output FLAC audio file will have the exact same quality as the original.

However, if you don’t want large files, you can use OPUS as a lossy alternative. Set a high enough quality/bitrate, and you might not be able to tell the difference.

ffmpeg -i "Name of Song.wma" -acodec libopus -b:a 320k "Name of Song.ogg"

I use lossless for archival purposes (which means forever keeping the original audio intact, yet not as large as a raw, uncompressed audio file.)


FYI Strawberry don’t use the lib32-* packages and gstreamer0.10, gstreamer0.10-base (also get rid of that if you can)

gstreamer-ffmpeg is gst-libav on Arch and derivates

Shot in the dark: Does disabling the “moodbar” in Strawberry / Clementine make a difference?

If applicable, is it possible to upload one of the WMA files somewhere to download it as a test?

A Clementine user reported a similar issue in 2016
cross-fading results in truncating play · Issue #5340 · clementine-player/Clementine · GitHub

Try turning off both cross-fading and autoplay and check if audio files play normally
then turn on cross-fading and check if audio files play correctly without autoplay

this is more like it, bit embarrassed cant find where i enabled the cossfading in strawberry

I tried to get Strawberry and Clementine to crash using every different combination of crossfade for sample WMA files, but no matter what I try it never crashes. I even enabled all fade/crossfade options.

Tools → Settings → Backend → Fading

While we’re at it, which backend are you using?

Is it possible to link/upload a WMA file that consistently crashes? Nothing I’ve tested with will crash any application.

Slightly off-topic, but you might have better luck (and a better experience) with either Audacious (a tried-and-true music player) or Cantata (which is a clean and lightweight GUI for MPD).

Both are available in the repositories. Just make sure mpd is installed if you wish to use Cantata, since it’s only an optional dependency, as Cantata can be used without it (i.e, remote server control).

ok disabled crossfade and still properly crash, funny the previous error log i gave was with crossfade enabled, and forgot to mention that it continues crossfading into the next song while dumping the error.

@winnie i’ve uploaded 2 demos at; WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free

There’s something wrong with those particular WMA files, and likely whatever encoder you used did something fancy to the streams. The “display time stamps” (DTS) are not proper, and so it can throw off decoders and players.

I noticed it almost always consistently crashes when scrolling to near the end of the tracks.

Some options going forwards:

  • Re-encode them with OPUS (libopus, .ogg container) with a very high bitrate (320k), to preserve as much quality as possible. (Most people won’t be able to tell the difference even at much lower bitrates.)
  • Compress them as lossless FLAC audio (flac, .ogg container), but they will have overkill filesizes.
  • Use a different player, such as Audacious or Cantata. Nevermind. Errors with them as well.
  • Live with the fact that these WMA files will act quirky with Strawberry / Clementine most Linux music players.