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 410498 - Banshee forgets iPod transcoding settings
Banshee forgets iPod transcoding settings
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: Device - iPod
0.11.7
Other All
: Normal normal
: 2.x
Assigned To: Banshee Maintainers
Banshee Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-02-21 19:19 UTC by Lauri Kotilainen
Modified: 2007-10-06 15:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Remember the active profile in ProfileComboBox.ReloadProfiles (772 bytes, patch)
2007-03-27 14:29 UTC, Lauri Kotilainen
committed Details | Review

Description Lauri Kotilainen 2007-02-21 19:19:08 UTC
Please describe the problem:
Banshee reverts the iPod transcoding settings to AAC after I manually change them to MP3.

Steps to reproduce:
1. Plug in an iPod
2. Start Banshee
3. Change the transcoding settings from AAC to MP3
4. Go to the library
5. Go back to the transcoding settings
6. ???
7. Profit!


Actual results:
iPod transcoding setting has reverted to AAC

Expected results:
transcoding setting is remembered

Does this happen every time?
Yes

Other information:
Bitrate settings for MP3 transcoding seem to stick, but the selected format doesn't.
Comment 1 Lauri Kotilainen 2007-03-27 14:29:17 UTC
Created attachment 85389 [details] [review]
Remember the active profile in ProfileComboBox.ReloadProfiles

Ok so this patch is probably really not the proper way to fix this issue, but hell, it's my first patch. :)

Here's the deal: The transcoding settings get loaded from GConf just fine, but calling ReloadProfiles effectively a) resets the setting to AAC and b) overwrites the settings in GConf. This patch does the simplest thing that could possibly work: stores the active profile at the beginning of ReloadProfiles and sets it back in the end.
Comment 2 Lauri Kotilainen 2007-03-27 14:48:26 UTC
Oh, lest I forget: the patch is against SVN HEAD :) 
Comment 3 Ruben Vermeersch 2007-03-31 14:50:00 UTC
Isn't there a risk in this code that we'll set the Active Profile to a profile that doesn't exist? I think the SetActiveProfile method is there to prevent this.
Comment 4 Lauri Kotilainen 2007-03-31 17:13:09 UTC
The ActiveProfile setter calls SetActiveProfile(value); so I don't see much of a difference there, except for the possibility that someone might change the ActiveProfile setter in the future. But if you think it's better to make the call explicit, I may just find the energy to change that single line. :-)
Comment 5 Ruben Vermeersch 2007-03-31 17:21:06 UTC
Oh my bad, didn't notice that :-). Looks good then, marking accepted for a final (second) review. Great work, thanks!
Comment 6 Aaron Bockover 2007-04-18 19:41:37 UTC
Committed, Thanks!