Faster reproduction

[henriquebs12]

I'm currently using Google Drive as the file storage back-end (using Rclone) which is very fast for downloading files, but when playing songs (mp3), I have the impression that it has to download the whole song before playing it. Isn't there a way to reduce the amount of data required to play in order to have faster reproduction speeds?

When a song loads, it seems 80% of it is already downloaded, and if it was 10% that would be just fine. Is there any settings to change it? Or maybe preload metadata of other files of the folder when you play the first song.

[paulijar]

The modern web browsers (at least Chrome, Firefox, Edge) basically already handle this between the browser and your server: They first start downloading from the beginning of the file, and when they think they have enough data, they start playing. They also often pause the download before getting the whole file. When the playback then nears the end of the buffered content, the browsers automatically resume the download. If the file transfer has timed out in the mean time, the browsers make a new download request with a start offset set so that the same data is not loaded again.

But in your case, I believe that the problem now is that the same partial download strategy cannot be applied between your cloud and Google Drive. The browsers seem to work so, that they initially request to get the whole file, and then they just pause the download before getting all of it. When ownCloud or Nextcloud gets such a request, it probably first loads all the requested data from the file to a memory buffer, and then it starts serving it to the web client. This is fine if the transferring of the file to memory is rather fast operation, but not so much if the file actually resides on another server.

The Music app currently uses the WebDAV interface provided by the ownCloud/Nextcloud server to serve the file to the web client, and we don't have any control on the details of this. I'm not certain, if it would be possible to rework this part of the app so that we would forget the WebDAV and instead, stream the file directly to the client. Ideally, we could then read the file from the (remote) file system while serving it to the client, and stop the reading if the client pauses the download.

[henriquebs12]

Thank you for your time and work on this project. In fact I'm using it as my personal music storage and it was performing, as you said, just well, but files were local. It's not that Google Drive is slow, but the few seconds waiting for each song to start is kind of experience breaking.

I know Google Drive also plays partial songs, and it plays MP3's very fast if you do it directly in the Google Drive website. Maybe someday you could also retrieve those fragments instead of downloading it first.

[paulijar]

@henriquebs12 @bmschwa The newly released Music v1.2.1 changes the server-side implementation of the audio downloading. It would be interesting to know, if this had any effect on the performance on your configurations.

[paulijar]

The new Music v1.6.0 now starts buffering the next song in queue immediately after the currently playing song has been fully buffered. Together with the changes introduced in Music v1.2.1, this should improve the experience with external storages a lot.