Tuesday, August 20, 2013

Changing default clock-format from 24-hour to 12-hour in Fedora 19

When setting up my latest Kickstart files for Fedora 19 I noticed that the default GNOME clock format of the clock displayed on the login screen and user's desktop and lock screens were all in 24-hour time format. I wanted to change this to a 12-hour clock format. I first came across a post that explained how to do this using dconf under the gdm user's account:

This works great and may be what some users want. However, this only changes the format of the clock on the login screen and its lock screen -- Once you log-in as a user or create a new account on the system, the user ends up with a 24-hour clock.

I then stumbled across glib-compile-schemas which provided me with a way to override the defaults provided by the settings schema. To use glib-compile-schemas I must first create a schema override file in /usr/share/glib-2.0/schemas. Because I will be overriding the clock-format value in schema id /org/gnome/desktop/interface/ I will name my file org.gnome.desktop.interface.gschema.override. It is important that the file's name ends with .gschema.override as this is required by the glib-compile-schemas utility.

Once I have defined all my overrides I can execute the glib-compile-schemas utility on the /usr/share/glib-2.0/schemas directory:

There may be some warnings displayed as there are deprecation notices for some of the keys defined by other applications. Once that was done I restarted and can see that my override has resulted in the default time format for all users, gdm included, being set to 12-hour.

Hope this helps someone else who manages systems for multiple users and likes things as automated as possible.

Thursday, May 30, 2013

Google Music MP3s and The Hidden ID3 tag

I have been purchasing MP3s from a few select online retailers for a few years now. I am a strong believer in the terms of service and security of my accounts -- meaning that I do not share accounts among family members. Instead, we each have our own account. However, this does not mean we should have to each buy our own copy of the same MP3. The retailers I have selected provide me with the ability to download the files so that I can install them on my offline devices. Or at least, so I thought.

It turns out that recently Google has made a change to the MP3s sold on Google Music. When I was syncing my music folder I saw that Google Music Manager failed to upload a few hundred tracks. A closer look at the log reveals something unexpected:

Song was purchased with another Google Play account
This came as a shock to me as this has not happened in the past. I noticed that a few albums that had been purchased recently all seemed to fall victim to this error. Needless to say, I was pissed!

After a few minutes however, I found my resolution thanks to a post in a Google forum. The suggestion from Jay LaCroix was to use a little Python script called eyeD3 to strip a private ID3 tag frame called PRIV from the MP3. In his original post he was using eyeD3 to strip all the tags but a later post by Keerthi Madapusi Pera suggested to use eyeD3's --remove-frame command-line argument to remove the PRIV frame from the "infected" file. Sure enough, it took care of my little problem. In the end I was able to use the utility on the albums that fell victim to this pro-piracy tactic by executing the following from the command-line:

cd ~/Music/<artist>/<album>
eyeD3 --remove-frame PRIV ./
I could have run the command from my Music folder as it is recursive. However, I wanted to limit the command to the albums I knew were impacted. It's also worth noting that the --remove-frame command-line argument seems to have been added in a recent version of the utility. The version in your package repository may not be new enough. In my case I used 0.7.1-final.

In the future I will need to remember to make this an automatic part of my music download process. I am not sure who is to blame for wasting more of my time. Is it Google? The music industry? The people who illegally pirate content without paying? Or the users who legally purchase content and think its their right to share it with the rest of the world? I am sure the answer is a combination of all the above but content providers really need to watch themselves as these kind of tactics are how pirates are born and in my opinion have a negative impact on their revenue as I will move my business to Amazon.