Bug 331233 - Track change slow on CIFS-mounted folders because of MANY df calls
Summary: Track change slow on CIFS-mounted folders because of MANY df calls
Status: RESOLVED UPSTREAM
Alias: None
Product: phonon-backend-vlc
Classification: Frameworks and Libraries
Component: general (other bugs)
Version First Reported In: 0.6.2
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: 0.8
Assignee: Harald Sitter
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-17 13:39 UTC by Julian Kalinowski
Modified: 2016-06-04 14:40 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments
Debug output while playing a track, then stopping playback (28.27 KB, text/x-log)
2014-02-20 08:26 UTC, Julian Kalinowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Kalinowski 2014-02-17 13:39:29 UTC
This is a problem i only recognized because I'm using greyhole storage pooling which uses a custom Samba dfree command, which is a little slower than usual.
The behaviour, however, is amarok-specific and doesn't depend on greyhole.

When double-clicking on a track in the playlist to play it, amarok is issuing many 'df' calls to the samba server. I count 52 for a simple track change.
While this doesn't show up as an issue locally or on normal samba shares, it makes amarok hang two seconds on every track change with a slow dfree implementation.

I don't get why amarok checks the free space 52 times when changing a track, so i think this is a bug.

Reproducible: Always

Steps to Reproduce:
1. Create a samba share with a custom dfree command (bash script: just log the call an return "0 0 1024" as dummy data)
2. Fill the playlist with music from that share
3. tail -f  the log file while switching tracks
Actual Results:  
52 Log entries / dfree calls per changed track

Expected Results:  
At MOST 1 log entry per changed track.
Comment 1 Myriam Schweingruber 2014-02-17 15:38:51 UTC
Is it really Amarok or is it Phonon? Could you please provide an output? Please also run amarok with the options -d --nofork and activate the Phonon debugging option as described here: http://techbase.kde.org/Development/Tutorials/Debugging/Phonon
Comment 2 Julian Kalinowski 2014-02-18 21:20:31 UTC
Your mentioning of phonon made me try another backend (used vlc by default), with the following result:
VLC: many dfree checks on track change
gstreamer: NO dfree call, never ever

So i got curious and tried VLC standalone - which generated the same huge amount of dfree calls when starting playback of an mp3 file.

I also generated the debug output you mentioned, but i guess it's not needed now.

Thanks for pointing in the right direction, i'll see if this can be posted as VLC bug.
In the meantime, i introduced some caching in the slow greyhole-dfree command, so the problem is gone anyway - at least for greyhole users that suffered.
Comment 3 Myriam Schweingruber 2014-02-20 08:19:17 UTC
Not as a vlc bug, but as a bug in the phonon-backend-vlc, which is also tracked here. I reopen this ticket and reassign it to the phonon-backend-vlc, then. Please attach the output.
Comment 4 Myriam Schweingruber 2014-02-20 08:19:53 UTC
Could you please also specify the exact version of the backend?
Comment 5 Julian Kalinowski 2014-02-20 08:26:48 UTC
Created attachment 85242 [details]
Debug output while playing a track, then stopping playback

I have phonon-vlc 0.6.2 and KDE 4.11.5 installed.
Comment 6 Myriam Schweingruber 2014-08-10 13:47:19 UTC
Thank you for the feedback.
Comment 7 Harald Sitter 2016-06-04 14:40:50 UTC
Please test with VLC 3 and report on the vlc bug tracker if this is still an issue. Ultimately this needs to be solved in vlc.