High data usage and long wait time while playing Opus files from SMB share

Support
1

Issue description:

Symfonium uses an unusual amount of data while taking a long time to start playing 128k Opus files on a Samba share.

After tapping on a single 5 MB Opus file (With no external cover jpg/png files), I have to wait 10-15 seconds for playback to start, while the data usage on the app’s info page keeps climbing up at around 4 MB/sec. Android eventually reports 42 MB of foreground data used after playback starts. (The high data usage only starts after I tap on a file; the app doesn’t use any data while idle.)

When I tap the same (currently playing) file again, another 20 MB of data is used and it still takes 10 secs for playback to start again. So the file is not being cached (Which is expected, but it just makes the high delay + data usage a bit more confusing).

For comparison, VLC starts playing instantly, and only uses ~6 MB after letting it buffer the entire file.

I’ve tried toggling:

  • Wifi only image downloads
  • Scrape additional artist metadata
  • Transcoding engine
  • Prefer internal decoder

Battery optimizations were also turned off instantly after installing the app.

Logs:

Upload description: zazizu

Additional information:

 
Symfonium version: 12.3.5a
Samba version: 4.17.12-Debian
Files encoded with opusenc from opus-tools 0.2-34-g98f3ddc
 

Reproduction steps:

 

  • Install app
  • Add SMB share
  • Wait for metadata and album art to get cached
  • Close app
  • Switch to mobile data
  • Reopen app
  • Tap on a track
     

Media provider:

Samba

Screenshots:

     

2

You can enable playback cache to actually cache media :slight_smile:

Current version have an issue with the transcoding engine settings, even disabled it does test and in your case it takes 12 seconds via ffprobe, no idea why it’s so slow, but you can join the beta so that disabling the engine will skip that part.

For the data usage you have a sync running so this takes data.

3

Thanks for the quick response ^^
Tried joining the beta but it was full, I will try later.
Also for the data usage, I since tried deleting app data and setting it up again, then waiting (on wifi) for all the metadata and album art to fully appear, which didn’t take too long since there’s only 20 tracks. Then turned off “Wifi only” and turned on “Disable library auto sync”, then relaunched app on mobile data. When I navigate through every menu and section, it uses barely any data (50 KB total), it only shoots up after I start playing a track. When I press the manual Sync button from the filter menu it syncs instantly and uses very little data as well.

4

Issue still present in latest beta release (I used the 1-day trial extension), total 60 MB foreground data used to play three 3-5 MB opus files (with the same long wait time) - tried toggling the same set of settings as well. I can reupload logs if needed (Or give access to the SMB share) before my trial ends.

5

Well yes I need logs :slight_smile: With transcoding disabled.

6

Upload desc “zazizu-2” - both transcoding and internal decoder were disabled, 2 files played

7

Upload some opus files to https://upload.symfonium.app and tell me when done.

There’s no reads outside of ExoPlayer, your files are probably strangely encoded making ExoPlayer do some extra reading to detect what kind of files they are.

8

3 files uploaded (desc “zazizu-opus”), all 140k bitrate with no metadata (--bitrate 140 --discard-comments --discard-pictures) encoded with standard opusenc (opus-tools 0.2 / libopus 1.5.2) from debian ^^

They all play fine via VLC for android (7mb foreground data reported for 6mb opus file, playback starts in ~3 secs) but exhibit same symptoms when played via Symfonium on the same share/folder.

9

Don’t compare oranges and apples :wink:

So this is effectively due to ExoPlayer handling, it opens and close the connection multiple times in that case to read different part before starting playback.

Since the SMB buffers are relatively large for performance reasons over LAN, this causes large reads leading to the extra data loaded you see and delays.

I’ll reduce the buffers a lot for that use case, after some tests even for hires DSD there’s nearly no performance impact on Wifi.

But your SMB server / network is insanely slow if those 3 reads triggers so much delays.

10

Thanks for the analysis, I was more worried about the data usage and not the speed, so it would be nice to have the option for smaller buffers as you mentioned. For the VLC comparisons i do realize both apps are quite different, i was just trying to understand if something was fundamentally wrong with the Samba server or my network setup, so I tried another app and thought it would be ok to mention it worked there ^

Would really appreciate if you could reply/update this thread when there’s a new beta version/setting about this issue so that i can try and report back :grinning_face_with_smiling_eyes: