uh oh, forgot details for case b, which also perfectly reproducible.

---8<---Case B--------
Steps to Reproduce:
For case b:
1- Open Amarok
2- Connect and mount your iPod, Amarok will auto-mount it.
3- Select an artist/album/track from your iPod collection, right click it, select delete tracks.


Actual Results:  
- Progress bar stuck at 0%
- Text "Removing tracks from device" appears and stays forever.
- Deleting is actually done
- Canceling after deleting finished has no adverse effects.

Expected Results:  
- Progress bar shall show actual operation completion percent and disappear when deleting finishes.
- Text "Removing tracks from device" shall appear when copying actually
starts and shall vanish when deleting completes.

---8<---Case B---------

I can confirm that I have this same bug. It happens in both cases as described.

Some information about my system:
***** Amarok 2.3.1 (-r2, Gentoo patches)
***** KDE 4.4.5

- Latest GIT copy of libgpod as of a few days ago.
- gcc (Gentoo 4.4.3-r2 p1.2) 4.4.3
- x86_64 Architecture, Gentoo Kernel 2.6.34-r1
- Sixth-generation iPod Classic (160 GB)

I can provide any other information/testing that is needed if I've left anything out.

Confirmed by comment #2

In my case, the progress bar is not updated whenever i copy something (a track / an album / an artist) on my ipod

Amarok 2.4-GIT, kubuntu 10.10 , iPod 2g nano – CASE A – When copying artist to iPod, progress bar does not display live status (bug still present). CASE B – When deleting artist from iPod, Amarok crashes (see bug 260275). (CASE C - When copying album to iPod, progress bar **does** show status properly.)

Thanks for testing, changing version.

Version:           2.4.0 (KDE 4.6.0) 
OS:                  Linux x64

I do confirm this behaviour. When copying music to my Creative Zen (MTP device) the transfer process seems not to be correctly finalized. This means that:

- Status bar is is not updated (i.e. it's stuck to 0% when one track is copied and to 80-90% when multiple tracks are copied)
- Amarok refuses to start a new transfer job since the previous one is marked as still in progress

In fact tracks are correctly transferred to the device. 
The problem seems to lie in how Amarok handles the finalization of the transfer job.

Same bug here with my Creative Zen (MTP device) on Fedora 14. Progress bar starts from 0% to 89% (0, 10,20...) then stops there until i unmount the device. I cannot start another transfer neither.

Are there some tests i can run to help finding the problem ?

Similar or same behaviour here. I'm using Amarok 2.4.0 under KDE 4.6.1 on an up-to-date Archlinux installation. When copying files to my Samsung YP-S3 (MTP-device) through Amarok the progress bar gets stuck somewhere around 90 % most of the time (had 90 %, 97 %, 99 %, when copying tracks it even stopped at 45 %). I copied Artists, Albums and Multiple Tracks.

Created attachment 60076 [details]
Debug log while copying one track to MTP device (Creative ZEN)

I attach the debug output while copying one single track to my Creative Zen
(MTP).

The track is transferred correctly and looking at the debug log the operation
seems to be finalized properly, but nevertheless the transfer bar is stuck to
0%.

Similar behavior when synching N multiple tracks: bar updated for N-1 tracks
and stuck after copying the Nth.

This bug really affects the (already poor) usability of amarok as a mp3 device
manager...I would suggest to raise its priority.

Same issue with my sister's Samsung YP-T10.

This problem seems to be a general flaw of Amarok's MTP file transfer implementation, since it shows up with different MTP devices. 

I suggest to update the bug's title to:
"Copy to collection progress bar is not updated when working with MTP devices"

Actually, this bug seems to be fixed in the current git sources, although it is still present in Amarok 2.4.0 (KDE 4.6.2).

I only have an iPod to test with, not an MTP device, but I would be /very/ surprised if this bug was in a device-specific portion of the code.

Anyone willing to grab the latest git sources and verify?

Just tried the latest GIT. The problem persists.

Amarok 2.4-git (May 24th), KDE 4.6.3
Arch Linux 64bit, libMTP 1.0.6, libGphoto2 2.4.10.1

Created attachment 60286 [details]
Increases debug output from StatusBar.

Can you apply the patch I just attached to your copy of the git tree, and give me the resulting debug log from when you try to copy a track/album/whatever?

I still cannot reproduce this bug in the current git sources; the progress update is handled by MediaDeviceHandler::slotFinalizeTrackCopy(), which is device-independent -- the same code gets used for MTP devices, iPods, and USB mass storage.

I am curious as to whether or not StatusBar::incrementProgress() is getting called in your case, since it seems to work as expected when I try it.

Created attachment 60320 [details]
Debug log while copying one and two tracks, after applying increased debug patch

Debug log in two cases:
1) Copying one single track: bar hangs at 0%
2) Copying two tracks: bar hangs at 50%

I can't see anything wrong in the log file.

I had a look at the source code and I may have found something wrong.

There is a MediaDeviceHandler::slotCopyTrackJobsDone() which finishes the progress bar and notifies amarok that the copy process is complete. 
It also seems never to be used anywhere in the code. There is no method calling it nor any signal connected to it.

Could this be the problem? 

MediaDeviceHandler::slotFinalizeTrackCopy() takes care of finalizing the copy of every single track, but the copy job itself never get finalized properly.

Adding a direct call to slotCopyTrackJobsDone() does the trick. The transfer job is properly finalized!

This is my quick and dirty experiment:

void MediaDeviceHandler::enqueueNextCopyThread()
{
    [...]
}
//Added part--------------
else
{
    debug() << "No more tracks to copy...done";
    slotCopyTrackJobsDone((ThreadWeaver::Job*) NULL);
}
//------------------------
}

I don't think this is the way this method it's meant to be used and I'm not sure MediaDeviceHandler::enqueueNextCopyThread() is the right place to start the process finalization, though.

Created attachment 61065 [details]
Patch that fixes the finalization of copy process to media devices

I'm attaching a patch that fixes the problem. 

The patch gets rid of the unused slot MediaDeviceHandler::slotCopyTrackJobsDone() and incorporates into MediaDeviceHandler::slotCopyTrackJobsDone() the proper steps for the copy process to be finalized correctly, in case no tracks are left to be transferred.

Tommaso, thank youfor the patch. Please submit it to http://reviewboard.kde.org. You might need to get an identity first at http://identity.kde.org

Git commit 7e48852a1763e4ac3a1089c5891b84515438e34b by Bart Cerneels.
Committed on 19/06/2011 at 08:26.
Pushed by shanachie into branch 'master'.

Fix finalization of track copy process.

... to media device collections.

Patch by Tommaso Falchi Delitala.

BUG:238912
REVIEW:101652

M  +2    -0    ChangeLog     
M  +9    -14   src/core-impl/collections/mediadevicecollection/handler/MediaDeviceHandler.cpp     
M  +0    -1    src/core-impl/collections/mediadevicecollection/handler/MediaDeviceHandler.h     

http://commits.kde.org/amarok/7e48852a1763e4ac3a1089c5891b84515438e34b

*** Bug 276536 has been marked as a duplicate of this bug. ***