-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to play large tracks via music player that work in files view #864
Comments
Thanks for the report. The embedded player within the Files app streams the songs through different URL (different REST API endpoint) compared to the Music app. Both use basically the same logic to actually play the song once it reaches the browser. Could you share a single file with this problem with me? You can find my email address from my github profile. |
For the record, we discussed this issue with @mpmartti over email and it turned out that this is related to the PHP setting music/lib/Http/FileResponse.php Line 106 in 3a8cb37
Now, in order for this to work, the setting When playing the files within the Files app, the Music app backend module referred above is not involved. Instead, the file is read using the WebDAV API provided by the cloud core. Apparently, this manages to serve the large files without extensive memory allocations. So probably it would be possible for the Music app backend too, somehow. (*) Technically, the server reads the file in 8K chunks and it only reads as much as the client has requested. But in practice, the browsers always request the whole file when playing from the start of the file, and they just pause the download when they think that they have got enough. |
Previously, we were returning audio files by first reading them to RAM as whole before sending them to the client. This could cause problems with large enough files (usually FLAC or WAV), as the `memory_limit` in php.ini could prevent such memory allocation. Now we, instead, copy the file data to the output stream lazily. This can be achieved by implementing the interface ICallbackResponse. The cloud core would also provide a ready-made implementation StreamResponse, but that wouldn't support the range requests. It's possible that the stream-like responses also improve the performance with external storages. However, this hasn't been tested and it may also depend on the implementation details of the storage plugin used. refs #864
Music v1.2.1 was just released, and it changes the audio file streaming so that the whole file is not read to the RAM of the server. Hence, the playing of large files now works with a much smaller |
I uploaded a dozen CDs in flac to my OwnCloud server, and noticed a few tracks aren't working in music player, but they work fine when played via Files-view. Most of the tracks work fine in music player. I tried uploading the album again in different name and the same problem occured again.
I tried uploading files in wav and that didn't work either. After indefinite time of loading the track, music player gives error message: "Error playing URL: /ownCloud/index.php/apps/music/api/file/5992/download". I couldn't find similar issue posted earlier. Any idea what might cause the problem? Other tracks work fine, so it might be some problem with the tracks, but then again tracks work fine with any other music player or even in ownCloud Files-view.
I do not consider this a very serious problem, I'm just curious what might cause this and how to fix it.
Web server: Ubuntu 20.04 on Raspberry Pi 4
Database: MariaDB
PHP version: PHP 7.4.9
OwnCloud version: 10.7.0.4 (fresh install from ownCloud, in use for a month)
Music version: 1.2.0
No errors in signing status.
Problem occured in Firefox 89.0 and Microsoft Edge 91.0.864.41 on Windows 10, Ubuntu 20.04 and android 10 and with all ownCloud users.
The text was updated successfully, but these errors were encountered: