and in this event, I have to play the sound twice to hear it. This is usually an error I get if the sound files aren’t present in the resource. I assure you, they are.
Neither the code or the sound files themselves have been changed in months, so I’m just wondering if there’s an issue with the NUI functions after a recent update. Any insight would be appreciated.
The sounds haven’t changed, and they were working for a long time. I don’t think the codec is the problem, since starting today, sometimes the sounds work and sometimes they don’t.
I can concur that NUI based sounds have stopped working. Our server uses a few sounds for a couple scripts that use .mp3 files and they no longer work. Our loading screen uses NUI and an .mp4 video is no longer working. All of our NUI scripts that use custom sounds, etc. have stopped working.
ol i apology for bothering you, but could you say what should i use to convert files? i tried with plugin for media encoder, ogg vorbis version 0.5b6 2016 build but that doesnt seem to work
just thought I should pass on some info that I’ve discovered while trying to fix the NUI audio issue for the server i help with:
It appears to NOT be related to codecs. It appears that the version of the chromium DLL that is shipped with fivem is more picky about server headers, and is refusing to play audio offered by the http server built into fivem. We’ve offloaded the mp3, mp4, ogv, ogg audio+video files onto our community’s web server, and modified the scripts to load from the apache-based web server, and audio works again, pointing to an incompatibility between the http service from fivem itself.
It’s a client change, server artifacts aren’t related; but it’s somewhat dependent on a number of compatibility workarounds for common resources such as ‘gcphone’ and testing on some ‘weird’ PC setups.
that’s honestly a bit unexpected to me, that it’s being fixed on the client side rather than on the server-side, which generates the http server the files are hosted from. So it’s intercepting the calls from the server, injecting the mimetype header, before passing it on to the chromium component? I can see how that workflow would work to ensure that all game clients would be able to work without folks having to update their artifact, but it seems like it has a LOT of potential for edge cases like you mentioned…
15 years of web server administration may be biasing me, but I’d highly recommend considering updating the artifacts to also provide the mimetypes correctly to reduce complexity in the future
Resource files are downloaded locally on join (the ‘Downloading content…’ phase) and handled by a custom scheme handler. There’s no HTTP server involved here at all other than the CEF scheme handler-based HTTP semantics emulation.
Ahhh, I am enlightened. I didn’t realize that the client simulated a http server for displaying the resources. Thanks for taking the time to correct me