After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 463916 - Allow automatic file rename when dragndrop from iPod to harddisk drive
Allow automatic file rename when dragndrop from iPod to harddisk drive
Status: RESOLVED WONTFIX
Product: banshee
Classification: Other
Component: Device - iPod
git master
Other All
: Normal enhancement
: 2.x
Assigned To: Banshee Maintainers
Banshee Maintainers
gnome[unmaintained]
Depends on: 535128 556165
Blocks:
 
 
Reported: 2007-08-06 08:25 UTC by Andrés G. Aragoneses (IRC: knocte)
Modified: 2020-03-17 08:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andrés G. Aragoneses (IRC: knocte) 2007-08-06 08:25:09 UTC
1. Connect an iPod with music.
2. Run Banshee.
3. Select some songs from the iPod.
4. Drag'n'drop them to the desktop.

Actual results:
The files copied remain with the same name as their cryptic original names from the device.

Expected results:
The files should be copied with a format pre-specified by the user (for example, {Artist} - {Title}.mp3).
Comment 1 Aaron Bockover 2007-08-06 20:29:15 UTC
This is not possible due to the way DnD works between GTK and Nautilus. The copy operation is not handled by Banshee. The only information we can pass in the DnD operation is the source location. There's no way, AFAIK, to specify a destination location, thus a rename is not possible.

The only thing I can suggest is to drag and drop the songs to the music library source inside Banshee, and then drag from the library to Nautilus. Banshee renames everything when doing internal copies since it can actually control the destination location.

Going to close as WONTFIX as I looked into this problem about two years ago and came to no satisfactory conclusion. If anyone knows any different, please feel free to reopen and post a solution.
Comment 2 Andrés G. Aragoneses (IRC: knocte) 2007-08-07 11:55:48 UTC
What about doing this when DnD:

1. Copy the file to Path.Combine(Path.GetTempPath(), Track.ToNewNameFromIdTags()).
2. Send the new path to Nautilus, for it to copy from it to the destination path (desktop for example).
3. Delete the file from the temp path.

Or better, if we use "mv" instead of "cp" in step 2, we could get rid of step 3, and thus, it would yield better performance (but I don't know if this is possible).

[I don't have enough rights on bgo to reopen it.]
Comment 3 Michał Sawicz 2007-08-10 08:10:39 UTC
Yes Andreas' idea seems good to me, too, apart from the "copy to temp", I'd rather opt for linking the file into the tmp dir so that it would be copied by nautilus, not by banshee.
Comment 4 Aaron Bockover 2007-08-13 13:16:53 UTC
This may be an option, I'll look into it.
Comment 5 Aaron Bockover 2007-08-13 13:40:47 UTC
A symlink won't work. Nautilus will simply copy the link. The only option regarding linking is to use a hard link, which is unreliable as it won't work on some systems.

The best option may be to do the IO in Banshee, and then issue a move operation for the DnD. I'll look into this next.
Comment 6 Andrew Conkling 2008-02-06 18:37:49 UTC
I don't have an iPod, but I assume this is still an issue in 0.13.2?
Comment 7 Andrew Conkling 2008-03-11 16:14:54 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!
Comment 8 Andrés G. Aragoneses (IRC: knocte) 2008-04-15 18:25:39 UTC
Sorry for the delay. This is not fixed yet in 0.13.2.
Comment 9 Andrés G. Aragoneses (IRC: knocte) 2008-05-07 20:13:41 UTC
FYI drag'n'drop from a track to the desktop doesn't work yet in trunk.
Comment 10 Andrés G. Aragoneses (IRC: knocte) 2008-09-13 17:11:16 UTC
(In reply to comment #9)
> FYI drag'n'drop from a track to the desktop doesn't work yet in trunk.

Ok, this was bug 535128 and it seems to have been fixed on r4512:

http://svn.gnome.org/viewvc/banshee?rev=4512&view=rev

I'll try to cook a patch for this now.

Comment 11 Daevid Vincent 2009-02-02 22:20:25 UTC
I have v1.4.2 and this still saves the file as "CSDU.mp3".

Another idea (and I am a programmer, but not a Gnome/GTK/Nautilus/HAL/DBUS/whatever one)...

Banshee keeps a mapping of the obscure name to the real name obviously. It also knows where you just dragged/dropped the files to. I assume it gets a SIG somehow when the copy is completed. So why not just do an extra step and rename the file from within banshee after it's copied/moved to the filesystem? It's "hacky" but I don't see why it wouldn't work, and sure would make this much more useable.

On a related note, I had no idea you could drag/drop files until just now when I was about to put in a feature request for an "export" menu item. For clarity and ease of use, could this be added to "Media > Export"?
Comment 12 Philipp Weissenbacher 2010-01-28 22:47:10 UTC
Please mark this bug as fixed, as it works as expected in 1.5.3 (beta 4)
Comment 13 Gabriel Burt 2010-01-28 22:49:33 UTC
I don't think you understand the bug report, Philipp.  AFAICT, this has not been fixed (and it not likely to ever get fixed, honestly).
Comment 14 Alexander Kojevnikov 2010-02-19 08:25:50 UTC
Updating the version, but feel free to close as WONTFIX.
Comment 15 Dave Wales 2011-04-27 07:23:37 UTC
Can someone please close this if that is the action to be taken, However i don't see the problem with importing songs from the ipod to the library then dragging to desktop as importing to library will cause banshee to manage the file regardless, hell, if you made a function to do it automatically people wouldn't even notice.
Comment 16 André Klapper 2020-03-17 08:33:07 UTC
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Please feel free to reopen this ticket (or rather transfer the project
to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the
responsibility for active development again.
See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.