Sorry, I realize that this is going to be a slightly non-standard bug report, but most of the conversation has happened on the Emby forums. I’ll link to that thread in a reply because of the 2-post limit for new users.
Tolriq asked me to post here with the logs, so that’s why it’s brief here.
Long story short: Symfonium or Emby are not presenting the correct stream when requesting FLAC to be transcoded to MP3.
To be completely specific, the Emby app will correctly transcode FLAC to MP3, but Symfonium has issues doing as much, and often ends up NOT transcoding and just directplaying the FLAC. Not so great for, you know, streaming and data.
It’s clear from the top of the Emby transcode logs I’m attaching WHY Symfonium is having issues with playback, just what isn’t clear is why the two apps are getting 2 different URIs.
This is the stream the Emby app plays back (minus the extra data for clarity): personaldomainremoved.ca:8690/emby/Audio/1052308/main.m3u8 (
This is the stream Symfonium plays back, for the exact same track: personaldomainremoved.ca:8690/audio/1052308/stream.ogg
To clarify my device setup when attempting to play back both files.
Note20 Ultra 5G (SM-N986W). Android 13.
Most recent version of both the official Emby app and Symfonium.
Attempting to play the exact same track from both apps.
Emby app does not have any issues with playback or transcoding. It simply doesn’t have an audio resume feature like video playback does, and that sucks for podcasts and live shows. Symfonium does, and I had no issues paying for that feature alone.
Cellular data. I live quite close to my cell tower, so the chance of me swapping to another is essentially nil. Actual internet connection is not an issue.
This isn’t limited to a single track.
There are three behaviors that I’ve observed with Symfonium. First, it just transcodes and plays back. Default, expected behavior. This is obviously the ideal state, but it’s not the consistent state. Second, it attempts to play back, and when it can’t, it goes through it’s standard retries (that I can see on the Emby dashboard as well), and ultimately falls back to just directplay. Third, it does the same as the second, except instead of falling back to directplay, it instead tells me there’s an error with the file format and it can’t play back (this is specifically what pushed me to look specifically at the command-line string for ffmpeg, leading me to narrowing the issue down).
Symfonium does not ask for transcoding to mp3 but to opus because mp3 is just the worst possible codec for transcoding and audio quality. Second one is aac.
The goal is to understand why Emby bugs then report so they fix, and eventually to add a workaround.
Your issue is fixed and the data you provided does prove it … If you refuse to provide new logs to show whatever new issue you have then it’s not me that refuse to fix.
It’s just YOU THAT REFUSE TO GIVE THE NECESSARY INFORMATION FOR THE FIX.
So I take the log from the Symfonium session.
What does it say:
That Symfonium ask the file to be transcoded to Opus at 256KB
And the logs shows that guess what:
So to resume and transpose to real life you are calling the mecanic in your car running at 130Km/h and tell him that the car does not start …
From the information you gave it’s false so your issue is not that.
If you can’t understand simple facts, there’s not much I can do for you …
Like I said, I hope this argument and my 5 bucks make you feel better about yourself. Have a good life. I’m done. Someone else can slobber your cock, cause I’m over it.
Honestly amazing the inversion of things. A dev asking for details to be able to fix a potential issue, and a guy that keep assaulting the dev telling him that he refuse to fix the issue …
I also remember when the internet was invented, when people didn’t double down on being wrong. But that’s cool. You do you. The issue wasn’t fixed. It did exactly the same as before. If you’re incapable of dealing with that, great. I don’t really care any more. Like I said, you enjoy my little bit of money, and you can further enjoy feeling like you’re superior. I’ve given you what you need, you’re just being difficult because you don’t want to be wrong, and that’s fine. You do you.
I since the start accept that there can still be an issue in the application, the only fact is that the issue that you first posted is fixed. The issue was caused by Emby when transcoding to Vorbis, Symfonium now request Opus and your Emby logs shows that too.
I never said there was no possible other issue or anything, I just asked for the Symfonium logs that you refuse to provide …
I don’t care about winning or anything, I care about having an app that works, and if you have an issue then I need the logs to fix it. What part is hard to understand here.
You keep repeating I have an issue you refuse to fix, but do not provide anything necessary to be able to.
The only thing you provide is a proof that Emby did transcode. What do you expect me do to do?
You show me something proving that transcoding does work (at least in the case of the log you provide) but tells me to fix transcoding … Don’t you see the irony and absurdity here?
So to resume you are the only one here that can’t deal with a simple fact, your issue is something else. If you had provided the asked Symfonium logs since asked it would probably already be fixed. As when you did provide the necessary information for your first issue and it was fixed in less than an hour …
