Community Open Call 🎤 Nov 10

Issue with audiofiles with mobile and desktop clients

Community Support
#1

Description

Mobile app : When someone sends an audio file, you can listen but the time is stuck at 00:00 and it is impossible to move forward/backward in the file.

Desktop app (MacOS) : When someone sends an audio file, you can listen but it is impossible to move forward/backward in the file.

It works correctly using web version.

Server Setup Information

  • Version of Rocket.Chat Server: 3.7.4
  • Operating System: linux 64 bits (dietpi on RPi4)
  • Deployment Method: snap
  • Number of Running Instances: 1
  • DB Replicaset Oplog:
  • NodeJS Version:
  • MongoDB Version:
  • Proxy: Caddy reverse proxy but not the snap-embedded one.
  • Firewalls involved:

Any additional Information

#2

Hello,

Do anyone have that issue? Well, I guess so but maybe I am the only one very annoyed by that.
Do you know if people in charge of the dev of mobile apps are present on the forum?

Greg

#3

Hi all,
Just to let you know in case someone meets the same issue.
I have upgraded to 3.12 (Edge branch) and still has the issue. But it works on the open RC server, so it must come from my install.
So issue can be caused by :

  • Filesystem used for the storage (RPI is on USB)
  • Snap install not having rights to read files “properly”

As I do not have much possibilities with a RPI, I am not sure I can fix it :confused:

#4

Still have that issue.
I guess it is a mobile app issue with the filesystem storage option.

image
image731×183 28 KB

Counter stuck at 00:00
Slider does not work
File does not fully play
No name displayed

#5

Is this the issue you mentioned in that another thread? Gotta go back and read that one but it’d be great if you can confirm my suspicion here :wink:

#6

Yes it is, I already created one a few months ago

#7

Hmm, thanks for confirming :smile:

I’ll put this in my queue right now. I have some stuff to do and other meetings in the coming hours, so won’t be able to take a look atm but rest assured it’s now in our crosshairs.

If you find any more information in the meantime, please update the thread accordingly.

Thank you for your patience, we now have this new community team (me, Muni Narayan, Yash Agrawal, John Crisp) just for you guys!! It’ll take some time for everyone to catch up, but we’ll get there. Just a teensy bit more time !! :partying_face:

Talk to you soon! Bye bye

1 Like
#8

Thanks!
For info it is working on the open Rocket.Chat server, I just made a test on the sandbox :

image
image750×178 29.4 KB

#9

Hello guys,
Any news on that issue?
Apart from it, the display of audio files is also not great as we cannot see the filename.

#10

Hi,

After trying the dev version (64 bits 3.18.0 snap install) it is working. (Thanks Debdut!)
I have not touched any of the default conf and I noticed the real difference is in the storage which is in GridFS by default in the dev.

So now I am almost sure this issue is with the “Filesystem” option when storage is on USB.
I could just change the option on my main server BUT I have read somewhere that the GridFS option is not a good idea on ‘weak’ hardware.
What do you suggest?

Cheers,
Greg

#11

Another test to confirm the Filesystem function is guilty, I tried on the 3.18.0 dev version and cannot get the same issue.
That would mean something has been fixed between 3.13.2 and 3.18.0, and I would be very happy if this is confirmed. I cannot wait to get the 3.18.0 on the edge branch of official RC snap :slight_smile:

#12

Awesome discoverry @Monsieur_KoZo ! Thanks for exploring this nasty anomaly with us.

With ffmpeg and mp4s I get this problem all the time if the mp4 file does not have the “length” chunk right at the beginning. I wonder if this is not similar in nature - somehow length of file cannot be determined under some situation.

1 Like