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 608678 - Naming routines while syncing
Naming routines while syncing
Status: RESOLVED DUPLICATE of bug 634096
Product: banshee
Classification: Other
Component: Device - USB Mass Storage
1.5.3
Other Linux
: Normal normal
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-02-01 13:38 UTC by Misha Shnurapet
Modified: 2011-06-27 13:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
config log (8.50 KB, application/octet-stream)
2010-02-01 13:38 UTC, Misha Shnurapet
Details

Description Misha Shnurapet 2010-02-01 13:38:42 UTC
Created attachment 152728 [details]
config log

If a file has its track field set to "0/0" then the file will be copied with the name ". Track Name .mp3" while syncing instead of "00. Track Name.mp3" (like it would normally be stored in the library).

It means that it will not be seen in Banshee upon the next device connection (though will be shown as non-audio data on the analyzer chart).

Changing the track number to "1/0" in the library is a workaround to this, the file will be copied as "01. Track Name.mp3", but it means setting false info about tracks in their tags. Please fix it.

Thanks.

--

Basic info about me:

bash-4.0$ uname -a
Linux saw 2.6.31.12-174.2.3.fc12.x86_64 #1 SMP Mon Jan 18 19:52:07 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
bash-4.0$ rpm -qa | grep banshee
banshee-1.5.3-0.1.20091216git.fc12.x86_64
banshee-musicbrainz-1.5.3-0.1.20091216git.fc12.x86_64
bash-4.0$ rpm -qa | grep mono
mono-web-2.4.3.1-1.fc12.x86_64
mono-data-sqlite-2.4.3.1-1.fc12.x86_64
dejavu-sans-mono-fonts-2.30-2.fc12.noarch
liberation-mono-fonts-1.05.1.20090721-2.fc12.noarch
mono-core-2.4.3.1-1.fc12.x86_64
mono-zeroconf-0.9.0-2.fc12.x86_64
mono-data-2.4.3.1-1.fc12.x86_64
mono-debuginfo-2.4.2.3-2.fc12.x86_64
mono-winforms-2.4.3.1-1.fc12.x86_64
mono-addins-0.4-9.20091702svn127062.fc12.x86_64
bash-4.0$
Comment 1 Alexander Kojevnikov 2010-02-02 04:22:47 UTC
(In reply to comment #0)
> Changing the track number to "1/0" in the library is a workaround to this, the
> file will be copied as "01. Track Name.mp3", but it means setting false info
> about tracks in their tags. Please fix it.

Why false, it's *one* track isn't it? Why not setting it to 1/1?

Anyway, this will be fixed when item 2 from bug 489861, comment 22 is addressed. Closing as a duplicate.

*** This bug has been marked as a duplicate of bug 489861 ***
Comment 2 Misha Shnurapet 2010-02-02 10:51:18 UTC
Seems to be a more human-readable naming algo, hope to see it in the near future. Thank you.
Comment 3 Andrés G. Aragoneses (IRC: knocte) 2011-06-27 13:05:27 UTC
The duplicate bug was actually wrong, this is a duplicate of bug 634096, which was fixed 3 months ago.

Misha, if you still see this bug in banshee 2.1.0 or newer, can you reopen bug 634096? Thanks!

*** This bug has been marked as a duplicate of bug 634096 ***
Comment 4 Andrés G. Aragoneses (IRC: knocte) 2011-06-27 13:08:25 UTC
Sorry I meant 7 months ago, not 3.