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 350773 - Transcode operates on files with no extension
Transcode operates on files with no extension
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: Device - Karma
unspecified
Other Linux
: Normal minor
: 2.x
Assigned To: Bob Copeland
Depends on:
Blocks: 348730
 
 
Reported: 2006-08-10 16:44 UTC by Bob Copeland
Modified: 2007-02-21 17:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Check for a known extension before transcoding something (2.22 KB, patch)
2006-08-10 16:45 UTC, Bob Copeland
none Details | Review
Check for known extensions before transcoding (2.28 KB, patch)
2006-11-10 18:42 UTC, Bob Copeland
none Details | Review
Rebased to subversion of 01/13/2007 (2.27 KB, patch)
2007-01-14 03:45 UTC, Bob Copeland
none Details | Review

Description Bob Copeland 2006-08-10 16:44:12 UTC
Refer to http://mail.gnome.org/archives/banshee-list/2006-July/msg00120.html for the impetus for this bug report.  Summary follows:

As I understand it, in Dap.cs, Banshee takes the list of all tracks that are supposed to be on the device (including those that are already on the dap added by loading the database) and sends them all to transcode.  Transcode skips any files that have an acceptable extension.  Finally, the core invokes the Dap's own Synchronize method which can then discriminate between tracks on the unit and those that need to be added.

On the iPod and other players, this doesn't matter because the files on the device retain their extensions.  However, on the Karma, all uploaded files get renamed to a number without an extension.  Transcode() will then deem that these are not 'acceptable' (even though they are on the device), so it will then do a pointless transcode, storing the newly transcoded file on the device as cached_filename.

I have a patch which first checks to make sure that files input into transcode are 'known' file formats; i.e. the file has to have an extension of mp3 or wav or whatever to be considered for transcoding.  This will exclude files already on the Karma from being transcoded since they don't have extensions.  I'll attach this.

This is really the only thing lacking to make the Rio Karma DAP plugin work.
Comment 1 Bob Copeland 2006-08-10 16:45:20 UTC
Created attachment 70662 [details] [review]
Check for a known extension before transcoding something
Comment 2 Bob Copeland 2006-11-10 18:42:59 UTC
Created attachment 76340 [details] [review]
Check for known extensions before transcoding
Comment 3 Bob Copeland 2007-01-14 03:45:39 UTC
Created attachment 80217 [details] [review]
Rebased to subversion of 01/13/2007
Comment 4 Josiah Ritchie - flickerfly 2007-01-18 21:04:28 UTC
component should be changed to karma
Comment 5 Josiah Ritchie - flickerfly 2007-02-21 16:30:01 UTC
The bug 348730 was blocked by this one and that has been resolved; however, this bugs latest patch is newer than the resolution of that bug. Either I'm confused or there is a conflict in information here. Bob could you clarify and if the patch still needs to be applied, confirm that it is good on SVN? I'll add abock to the CC if this is still unresolved so he'll get the update.
Comment 6 Bob Copeland 2007-02-21 17:07:48 UTC
AFAIK this patch still needs applying, or a different approach should be taken.  The patch in bug 348730 was applied and gives users the ability to play tracks from the DAP and sync -- *if* they delete all of the files on the device first.

The problem is that if they sync and there are files on the Karma, it will unnecessarily transcode those files on the device because they have no extension and the transcoder uses the extension to decide whether to transcode it.  IMO the transcode shouldn't consider the files that are on the device at all, and the fact that it works for ipod and all the rest is a happy accident.

As for alternate approaches, adding a flag to DapTrackInfo to know whether the song is on the device, or calling back into the dap plugin to ask if a file should be transcoded, either of these would work for me.  I'll code them up if abock has any input.  If the approach of the patch below is deemed ok, then I'll rebase it in a day or two.