On 7/1/25 11:41, Samuel Sieb wrote:
On 1/6/25 1:57 PM, Stephen Morris wrote:
On 30/12/24 21:02, Samuel Sieb wrote:
On 12/29/24 11:22 PM, Stephen Morris wrote:
It is the file that was sent to me in an email from Microsoft Teams as the voice mail after the missed phonecall. Under VLC it plays but produces no audio, so I was just trying "Videos" to see if it did
What do you mean it "plays"?
What does vlc say the codecs are?
What does the "file" command say the file is?
actually have audio in it that VLC couldn't play, which is when I got this issue. The person that made the phone call has told me there was actually no audio in the file, he didn't actually leave a message, he just put down his headphones and forgot to disconnect the phone call. But that not withstanding, I still shouldn't have got either of these errors, the decoder error nor the opengl error, but what is more significant is why does Totem behave differently under X11 to the way it behaves under Wayland?
I agree with Tim that the text/html error is suspicious.
When did you get the opengl error? Right when you opened the application or when you tried to play the file?
I recorded a new voice mail and sent the subsequent email to this email address.
The attachment is named "audio.mp3".
When I click on the attachment and from the context menu select the default player which is "Videos" the application gets an Opengl initialisation error (this is under Wayland) straight away.
Sounds like the application has an issue with your opengl configuration. I suggest you file an issue in bugzilla. You could also try running it from the command line to see if there is any more information.
If I repeat these step with KDE under X11 Totem plays the file correctly, so from my perspective the issue is Wayland, and having said this Wayland has never really worked properly with KDE ever since it was first introduced in Fedora. People on this mailing list originally advised me not to use Wayland with KDE as it didn't work, and it still exhibits issues with KDE.
I tried to play the file with VLC in KDE under X11 and with the audio option of "unset" the audio plays correctly albeit it is still low volume, so here again the issue appears to be Wayland. Having said this though if I set the audio option to "stereo" the audio plays but is echo e.
If I select "VLC" from the context menu the audio file plays but does not play properly, VLC sends the audio to the left speaker only with a very low volume. I have to increase the VLC audio to it max of 125% and turn the headphones volume up to its max of 150% to make the audio being played out the left speaker easily heard.
That's odd that vlc wouldn't automatically convert a mono stream to both sides.
If I go into VLC's Audio preferences and set the "Stereo audio output mode" to "Mono" or "Dolby Surround" (my headphones have the capability of simulating 7.1 surround sound) or "Stereo" instead of the default of unset, then the audio plays properly albeit the volume is still low, much lower than with "mpv Media Player".
Maybe mpv is doing some automatic gain adjustment?
It could be as it seems to play the same way in KDE under Wayland and X11.
VLC will only tell me the file codec data while the audio is playing or paused, if I wait until the audio has finished playing VLC doesn't show any information on what the Codec is. VLC is telling me the codec is "MPEG Audio layer 1/2(mpga), Type: Audio, Channels: Mono, Sample rate: 16000 Hz, Bits per sample: 32, Bitrate: 24 kb/s, and, because I'm
That's a strange format. 32 bits per sample??
You could also use "ffprobe" on the command line to get detailed info about the file and its data formats.
I ran ffprobe /usr/local/downloads/audio.mp3 from the command line and if I remove it configuration display I can't see any info on the number of bits per sample the vlc provides. This was running ffprobe in KDE under X11, I haven't tried it under Wayland yet to see if it is any different.
ffprobe /usr/local/downloads/audio.mp3
libavutil 59. 8.100 / 59. 8.100
libavcodec 61. 3.100 / 61. 3.100
libavformat 61. 1.100 / 61. 1.100
libavdevice 61. 1.100 / 61. 1.100
libavfilter 10. 1.100 / 10. 1.100
libswscale 8. 1.100 / 8. 1.100
libswresample 5. 1.100 / 5. 1.100
libpostproc 58. 1.100 / 58. 1.100
[mp3 @ 0x55b35e13a0c0] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from '/usr/local/downloads/audio.mp3':
Duration: 00:00:08.32, start: 0.000000, bitrate: 24 kb/s
Stream #0:0: Audio: mp3 (mp3float), 16000 Hz, mono, fltp, 24 kb/s
playing the file from the email attachment it tells me the file location is /tmp/pid-4265/audo-4.mp3 (this is not the name of the attachment, the attachment is audio.mp3). Just further checking on the location data VLC is showing, I shut VLC down and opened the attachment in VLC again, and VLC told me the location was /tmp/pid-4265/audio-5.mp3, so it looks like every time the file is "extracted" from the email to be played (Fedora, KDE or whatever is doing the extract) it is being named differently each time.
Every time it tries to save it, it finds that there is already a file there with the same name, so it adds a number to it in order to not overwrite the existing file. Each time you do it, the number increments.
I assume your email client is running as process number 4265.
I assumed that it was renaming the file to stop overwriting as well which I would have preferred it not to do, but given that the file is being written to /tmp, which I thought was memory and is effectively "emptied" at shutdown, I'm not that concerned about the "extraction" process not overwriting.
I didn't check what Thunderbird's pid was but I assumed as well that it was 4265.
regards,
Steve
Attachment:
OpenPGP_0x1EBE7C07B0F7242C.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
