Bulk changing the assignee to banshee-maint@gnome.bugs to make it easier for people to get updated on all banshee bugs by following that address.  It's usually quite apparent who is working on a given bug by the comments and/or patches attached.

Still applies to 1.5.2

I'm seeing this in the 1.6.1 version of Banshee that's in Ubuntu 10.04. This is pretty confusing, as the "Device properties" context menu item allows setting of the "Encode to" parameter. When I set this to Ogg, and all my music went onto my Rockbox-ified iPod, I was pretty confused. While I'm not really a C# developer, more a Python guy, I'm going to have a look at the source and see what I can do about it, as if it can be done for non-supported formats, it shouldn't be too hard to override the supported one.

OK, I think I have a patch. No doubt it will require improvement, but I'm happy to redo it based on feedback from people who know what they're doing.

Created attachment 167218 [details] [review]
Patch to check current format against the user-requested one

Checked briefly, seems to work.

Created attachment 167223 [details] [review]
Patch to transcode only lossless formats

As discussed on IRC, it may be better to transcode only lossless formats. This patch uses a List<string> to contain a list of known lossless codecs. I am not sure if this is the best way to do this.

Created attachment 167268 [details] [review]
Perhaps prettier?

I had a look at this as well, there has to be a prettier way to store a list of lossless formats.

Next step is to investigate how to add an overwrite for users who prefer to tradeoff capacity for audio quality and provide a tickbox.

Review of attachment 167268 [details] [review]:

my bad

Created attachment 167287 [details] [review]
Patch to add "Prefer quality" preference setting and obey it

This is hopefully the final patch in terms of functionality. It is entirely possible that it could do with a few cosmetic tweaks (for example, I've no idea whether the OnPreferQualityChanged callback method (?) is actually required), but it seems to DTRT.

Created attachment 167288 [details] [review]
Improve on the other patch by using a list initialiser instead of .Add emthods

Created attachment 167289 [details] [review]
Small cosmetic changes from the previous patch

+                Catalog.GetString ("Don't convert lossless formats"),
+                Catalog.GetString ("Leave lossless formats as they are, despite the extra file size.")

Has no affirmative, don't convert them or leave them alone. :)

Should be:

+                Catalog.GetString ("Preserve lossless files when synchronizing (uses more space on the device),
+                Catalog.GetString ("Convert lossless files when synchronizing (saves space on device)")

To make the default clear I think we should default to true, this would make the default behavior very clear. Banshee will optimize your enjoyment by giving you the most songs on the device it can.

[x] Convert lossless files when synchronizing (saves space on device)

wow.. I'm tired, ignore the no affirmative bit. The rest should still be valid.


+                Catalog.GetString ("Convert lossless files when synchronizing"),
+                Catalog.GetString ("Converting lossless files will increase the amount of data you can store on the device");

If the device doesn't support any lossless formats then the option should be greyed out like the auto sync setting when all sources are set to manual?

So you are suggesting to switch the sense of the option, and to grey out the box when no lossless formats are supported? I'll look into doing that.

Created attachment 167312 [details] [review]
Patch to do all required, including setting the sensitivity of the checkbox

Created attachment 167346 [details] [review]
Patch builds on the previous but defaults to "true" for convert_lossless

Review of attachment 167346 [details] [review]:

I think this preference should be located where the existing encoding prefs are -- in the DAP's properties (which you get to by right clicking on it in the source list).

There's another bug/enhancement request asking for the ability to re-encode high-bitrate MP3s to some low bitrate -- just something to keep in mind, in case there are overlaps.

::: src/Core/Banshee.Services/Banshee.MediaProfiles/MediaProfileManager.cs
@@ +305,3 @@
+        {
+            Initialize ();
+            mimetype = GetExtensionForMimeType(mimetype);

put a space between the method name and (arg list)

Created attachment 171356 [details]
My mockup for the device properties window

Please excuse my inferior GIMP skills, but hopefully this shows what I mean.

Created attachment 171359 [details]
Re-done mockup

Note that I couldn't populate the comboboxes from Glade: the first one would show whatever formats the DAP supports, the second would contain "All", "Incompatible and Lossless" and "Incompatible only" to specify which files should be transcoded.

Confirming, also this may be of interest?

https://bugzilla.gnome.org/show_bug.cgi?id=627476
https://bugzilla.gnome.org/show_bug.cgi?id=637735

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

As stated by David at "duplicate" bug 638603 it might be good to include a way to prevent conversion all together, including those format that are not supported by the device.

In the latest mock-up a "none" value in the "Files to Transcode" combobox would suffice. When selected, all non-supported files will be ignored, read not transferred, during sync as a consequence.

Changing the order of both comboboxes might be more logical for the user. I.e:

--------------------------------------
Transcode on Sync: [ .... \/]
Encode To: [ ............ \/] [Edit]
--------------------------------------

Where the "Transcode on Sync" combobox would contain the values: 'None', 'Unsupported only', 'Lossless only' and 'Unsupported and Lossless'.
'All' as an option does not quite make sense to me but correct me if I'm wrong. It would imply transcoding MP3 to MP3 again as well.

The All profile would indeed force all files to be transcoded, there are uses for this and believe it or not, users actually request it.

I think we need to consider:

Conversion policy [Skip unsupported files, Unsupported files only, Unsupported and Lossless (default), Force for all files]
Conversion to [...] [Edit]

Defaulting to Unsupported and Lossless seems sane.

Fair enough on the convert all option.

What I'm missing is some hit or clarification about why and when transcoding is or has to be done in the first place. We know it is done on sync and because not all file types are supported by a device but it can not be determined by just looking the current dialog. To reduce confusion for new or inexperienced users I think to should be made clear somehow.
With the last proposal made by David I think we would be diving strait in the conversion aspect while it's about transfer of files to the device in the first place.
I'm all for keeping the dialog as minimalistic and simple as possible, thus preventing a long explanation text as well, but I'm afraid we need at least something more.

What about:
----------------------------------------------------------------------------
File Transfer Policy
   Files to convert: [None, Unsupported and Lossless, Unsupported only, Lossless only, All files]
   Convert to: [...] [Edit]
----------------------------------------------------------------------------

I was thinking about 'Synchronization' instead of 'Transfer' as well but that might be implying auto sync too much.

I think the desirable experience would likely be having all of this in one view.

Insert DAP, click DAP as it appears in Banshee to be presented with something functionally similar to:

---

David's Samsung Galaxy S

Music      [All, Playlist]
Audiobooks [All, Playlist]
Video      [All, Playlist]
Podcasts   [All, Playlist]

Conversion policy for this device [Skip unsupported files, Unsupported files only, Unsupported and Lossless (default), Force for all files]
Convert to [...] [Edit]

---

Neatly arranging what to convert and how. It is the best compromise I have been able to come up with so far.

I'd just like to chime in and say I'd like a way to disable this transcoding feature completely. It really irritates me that it's the default with no way to deactivate it. I'm sure it's a nice feature for people who have limited players, but when you're moving files to a capable device there's no reason to screw with them.

In my case I'm trying to sync MP3s to an Android phone. For some reason it's only giving me ogg vorbis and PCM as encoding options. That's doubly strange because not only does Android handle MP3 just fine out of the box, what it handles is completely established in software. It's perfectly possible to install media apps that can decode all sorts of wacky formats that stock Android knows nothing about. 

So even if the device is mistakenly reporting only some of the formats it supports there's no reason to assume that's 100% accurate. I'm sure I'm not the only person with a device that misrepresents itself or is reprogrammable. There should most definitely be a way to override it, and if there is I haven't found it after several hours of digging.

It seems like pretty bad usability to me to add any feature to a music player that could impact audio quality without providing a way to disable it right from the start.

Devices that support a format but which do not show up in the preferences is a bug. Can you please file that separately?

I once used a player that had a dialog that allowed you to transcode files over a certain bitrate.  If you set it to say 500 you'd transcode all the losslessly encoded files I have, but none of the lossy ones.  If you set it to say 250 you'd transcode for example high-bit rate mp3s to something smaller, and your flacs.  If you wanted to disable transcoding you could set it to 5000 or something silly.

With a setting like this I wouldn't need to tell Banshee (by modifying the code) that my Android phone doesn't support flac files (which it does, but I want them transcoded.)

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.