Bug 331233

Summary:	Track change slow on CIFS-mounted folders because of MANY df calls
Product:	[Frameworks and Libraries] phonon-backend-vlc	Reporter:	Julian Kalinowski <julakali>
Component:	general	Assignee:	Harald Sitter <sitter>
Status:	RESOLVED UPSTREAM
Severity:	normal	CC:	bcooksley, fabo, jb, martin.sandsmark, matej, myriam
Priority:	NOR
Version First Reported In:	0.6.2
Target Milestone:	0.8
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Debug output while playing a track, then stopping playback

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.