Archive

Posts Tagged ‘sync’

Samsung Captivate SGH-i896 Meets Linux

November 7th, 2010 2 comments

Yesterday, I picked up the newly launched (in Canada) Samsung Captivate. So far, I’m extremely impressed with the device. The super amoled display is gorgeous, the touch screen is responsive, and the UI is stunning to look at and use. Coming from a Blackberry Curve 8310, this phone is like a digital orgasm.

Once I finished gushing over how awesome this phone is, I decided to try and get it to interact with my Linux Mint 9 Isadora install. For now, I just want to be able to transfer images and music to and from the device, although later on, I’d like to get a development environment set up and try my hand at writing some apps.

My first try at getting the phone to play nicely with Linux was not successful. It took me a little bit of fooling around before I could figure it out, but here goes:

  • On the phone, navigate to Settings > Applications > USB Settings and make sure that ‘Ask on Connection’ is selected
  • Plug your phone into the a USB port, and when prompted, select ‘Mass Storage’ from the dialog that appears on the phone
  • At this point, if you open up your Computer in Nautilus, you should see an icon that says something like SAMSUNG SGH-I896, but you won’t be able to interact with it in any way
  • On the phone, grab the notification bar at the top of the home screen and drag it down
  • In the notifications area, tap USB Connected, and when prompted, select Mount from the dialog
  • Back in Nautilus, the icon under Computer should now say something like SAMSUNG SGH-I896: 14GB Filesystem, and you should be able to read and write to the card

With these steps complete, I was able to interact with the phone through the file system and from within Banshee and FSpot. I’m not sure why the phone won’t allow Linux to mount its storage devices by default when in Mass Storage mode, but this little work around seems to make it behave correctly.

Drop me a line in the comments if you have any Linux/Android compatibility questions, and I’ll do my best to help you out.




On my Laptop, I am running Linux Mint 12.
On my home media server, I am running Ubuntu 12.04
Check out my profile for more information.

Finally Synching my Blackberry on Linux

January 2nd, 2010 18 comments

Some readers may recall all of the attempts that I’ve made in the past to synchronize my Blackberry with Mozilla’s Thunderbird email and calendar client. During each of these tries, I had relied on the OpenSync framework, along with the Barry project for communication with my phone, and a number of different solutions to link into Thunderbird. At various times, these included the opensync-plugin-iceowl, opensync-plugin-sunbird, and bluezync packages, none of which yielded success.

While running GNOME on my Debian laptop, I had managed to successfully synchronize my phone with the Evolution mail client. Even so, I continued to work at Thunderbird synchronization because I disliked Evolution, seeing it as a Microsoft Outlook clone, which is a platform that I have had considerable problems with in the past.

With my recent installation of Kubuntu 9.10 on my PC, I have been exposed to the Kontact PIM suite, and have thus far been impressed. Kmail is a solid email client, although the way that it handles the setup of multiple email accounts is confusing to say the least, forcing the user to create a sending, receiving, and identity object for each account, and then to link them together. Likewise, Kontact is a decent application, but is sorely lacking basic GUI configuration options, something I never thought that I would say about a KDE app. Finally, Kalendar does everything that one would expect, and allows the user to display appointments in a number of useful ways. All have excellent integration, and live in a tray widget that uses the native KDE notifications system to let me know when something important has happened.

Most importantly however, I managed to get the entire Kontact suite to sync with my Blackberry after about five minutes of playing around in the terminal. Unlike during previous installation attempts, I found the latest stable Barry packages available in my repositories, so installation was a snap. I simply added the following packages to my system:

  • libopensync0 v0.22-2
  • multisync-tools v0.92
  • libbarry0 v0.14-2.1
  • opensync-plugin-kdepim v0.22-4
  • opensync-plugin-barry v0.14-2.1

From a terminal, I then used the msynctool application and the following steps to do a little bit of configuration:

  1. msynctool –listplugins if the install went well, this command should list both kdepim-sync and barry-sync as available plugins
  2. msynctool –addgroup BB create an OpenSync sync profile for my Blackberry called BB
  3. msynctool –addmember BB barry-sync add the barry-sync plugin to the BB sync group
  4. msynctool –addmember BB kdepim-sync add the kdepim-sync plugin to the BB sync group
  5. msynctool –showgroup BB this lists each of the plugins that we just added to the BB sync group, along with their member numbers. In my case, barry-sync was member number 1, and kdepim-sync was member number 2. The output also showed that while barry-sync still needed to be configured, kdepim-sync had no configuration options to be set.
  6. msynctool –configure BB 1 configures member number 1 of the sync group BB. In my case, this was barry-sync, and simply popped a config file in the nano text editor. All that had to be changed in the file was the PIN of the Blackberry that the plugin would attempt to sync with.
  7. msynctool –sync BB actually performed the synchronization process. For safety’s sake, I made sure that Kontact was fully closed before running this command.

And that’s it! In the future, I simply have to run the msynctool –sync BB command to synchronize my Blackberry with Kontact. That’s one more reason to stick with Linux – Blackberry synchronization that isn’t tied to Microsoft Outlook!




On my Laptop, I am running Linux Mint 12.
On my home media server, I am running Ubuntu 12.04
Check out my profile for more information.

Filling a Zune from Linux

January 1st, 2010 2 comments

Thinking that I was up for a challenge, I decided to spend the day figuring out how to put the music in my Banshee library onto a Microsoft Zune. Since my library contains a good number of FLAC files that I’ve ripped in from my CD collection, my solution called for a caching system that converts the FLAC files to mp3s and stores them so that the playlist can be changed without having to re-convert the FLAC files into something that the Zune can play on every sync. My weapons of choice for the project were a Windows XP instance running inside of Sun Virtual Box, and 126 lines of perl script.

The Steps:

  1. Create a WinXP VM that has the Zune software installed and can see two shared folders on my Linux machine:
    1. My normal Music folder, which contain my entire collection
    2. The cache folders, which contain all of the FLAC files in my collection, but converted to mp3 so that the Zune can play them
  2. Open the Banshee database, located at ~/.config/banshee-1/banshee.db
  3. Select all of the FLAC files in the playlist that we’d like to put on the Zune
  4. For each, check if it has been converted and cached
    1. If so, simply add the path to the cached copy of the track to an m3u file in the cache folder
    2. If not, convert the track, and then add the path to the cached copy of the track to an m3u file in the cache folder
  5. Select all of the mp3 files in the playlist that we’d like to put on the Zune
  6. Put those in a separate m3u file that is located in the Music folder.
  7. Boot up the Zune software on the VM. It should autoscan it’s monitored folders, find the m3u playlists, and put them in its library
  8. Sync the playlists with the Zune by dragging and dropping them to the device icon in the lower left corner of the screen

As previously mentioned, steps 2 through 6 were accomplished by way of a perl script that I can run as often as I like:

#/usr/local/bin/perl

#Requirements: libdbd-sqlite3-perl, flac, lame

#We need database support
use DBI;

#Database path – change this to reflect your user environment
my $dbpath = “dbi:SQLite:dbname=/home/jon/.config/banshee-1/banshee.db”;

#Playlist name – change this to reflect the playlist that you want to export
my $plistname = “Favorites”;

#Cache Path – the path to the directory where you’ve been caching converted FLAC files
my $cachepath = “/home/jon/Storage/mp3Cache/”;

#Music Path – the path to the folder where your music collection is actually stored
my $musicpath = “/home/jon/Music/”;

#Connect to the database – no username/password
my $dbh = DBI->connect($dbpath,””,””,{RaiseError => 1, AutoCommit => 0});

if(!$dbh) {
print “Could not connect to database $dbpath”,”\n”,”Exiting”;
exit;
}

#Pull the list of FLAC files for conversion and caching
my $flac = $dbh->selectall_arrayref(“SELECT sme.TrackID, ct.Title, car.Name AS ‘Artist’, ca.Title AS ‘Album’, ct.Uri, ct.Duration AS ‘Length’ FROM corealbums AS ca, coreartists AS car, coresmartplaylistentries AS sme INNER JOIN coretracks AS ct ON sme.TrackID = ct.TrackID WHERE sme.SmartPlaylistID = (SELECT `SmartPlaylistID` FROM `coresmartplaylists` WHERE `Name` = ‘$plistname’) AND ca.AlbumID = ct.AlbumID AND car.ArtistID = ct.ArtistID AND ct.MimeType LIKE ‘%flac'”);

#open the m3u file to write the cached items to
open my $m3u, ‘>’, $cachepath.$plistname.’_cached.m3u’ or die “Error trying to open cache m3u playlist for overwrite. Do you have write permissions in $cachepath ?”;
print $m3u “#EXTM3U\r\n\r\n”;    #note windows \r\n here

#add /music to $cachepath so that files are in a subdirectory, away from the m3u file
$cachepath = $cachepath.”music/”;
if( ! -e $cachepath ) {
`mkdir “$cachepath”`;
}

#loop through the files and check if they need to be cached
foreach my $i (@$flac) {
my ($trackid, $title, $artist, $album, $uri, $length) = @$i;

#correct the uri by removing the file:// prefix and reverting the uri escaping
$uri = substr $uri, 7;
$uri =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;

#fix time into seconds
$length = int($length/1000);

#check if the flac file has already been converted and cached at cachepath
#if not, convert it and put it at cachepath.
my $path = $cachepath . $artist . ‘/’ . $album . ‘/’ . $title . ‘.mp3′;
if( ! -e $path ) {
#file dne, convert it
print “\nTrack: $title by $artist has not yet been cached, converting…”,”\n”;

#make sure that the file actually exists before attempting to convert it
if( ! -e $uri ) {
print “WARNING: Track $title by $artist does not exist at $uri”,”\n”;
} else {

#ensure that cache album/artist directories exist
my $partpath = $cachepath.$artist;
if( ! -d $partpath ) {
`mkdir “$partpath”`;
}
$partpath = $partpath.’/’.$album;
if( ! -d $partpath ) {
`mkdir “$partpath”`;l
}

#do the conversion – we’re chaining flac and lame here, reading in the flac file from $uri, and putting the resulting mp3 at $path
`flac -cd “$uri” | lame -h – “$path”`;
}
}

#add the track to the m3u file – note that these entries are relative to the location of the m3u file in the root of $cachepath
#the paths use a backslash and a \r\n newline so that they work correctly on windows
print $m3u “#EXTINF:$length,$artist – $title\r\n”;
print $m3u ‘\\music\\’.$artist.’\\’.$album.’\\’.$title.’.mp3′,”\r\n\r\n”;
}

#close the m3u file in the cachepath directory
close $m3u;

#TODO: scan the m3u file and delete any files that aren’t in it from the cache directory

#Pull the list of MP3 files and dump them into an m3u file
my $flac = $dbh->selectall_arrayref(“SELECT sme.TrackID, ct.Title, car.Name AS ‘Artist’, ca.Title AS ‘Album’, ct.Uri, ct.Duration AS ‘Length’ FROM corealbums AS ca, coreartists AS car, coresmartplaylistentries AS sme INNER JOIN coretracks AS ct ON sme.TrackID = ct.TrackID WHERE sme.SmartPlaylistID = (SELECT `SmartPlaylistID` FROM `coresmartplaylists` WHERE `Name` = ‘$plistname’) AND ca.AlbumID = ct.AlbumID AND car.ArtistID = ct.ArtistID AND ct.MimeType LIKE ‘%mp3′”);

#open the m3u file to write the cached items to
open my $m3u, ‘>’, $musicpath.$plistname.’.m3u’ or die “Error trying to open music folder m3u playlist for overwrite. Do you have write permissions in $musicpath ?”;
print $m3u “#EXTM3U\r\n\r\n”;    #note windows \r\n here

#loop through the files and check if they need to be cached
foreach my $i (@$flac) {
my ($trackid, $title, $artist, $album, $uri, $length) = @$i;

#correct the uri to become a windows file path
$uri = substr $uri, 7;            #remove file:// prefix
$uri =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;    #correct uri encoding
$uri =~ s/$musicpath//g;            #remove musicpath prefix
$uri =~ s/\//\\/g;                #change forward slashes to backslashes
$uri = ‘\\’.$uri;                #add the leading backslash

#fix time into seconds
$length = int($length/1000);

#add the track to the m3u file – note that these entries are relative to the location of the m3u file in the root of $cachepath
#the paths use a backslash and a \r\n newline so that they work correctly on windows
print $m3u “#EXTINF:$length,$artist – $title\r\n”;
print $m3u $uri,”\r\n\r\n”;
}

#close the m3u file and the database connection
close $m3u;
$dbh->disconnect;

Sorry for the horrible formatting.

The only snag that I hit during the entire process was really my fault – I have a tendency to overcomplicate things, and did so on this project by initially writing the script to output a *.zpl file instead of a *.m3u file. That didn’t work at all, and I ended up simplifying the script greatly by just outputting an *.m3u file and hoping for the best.

On the off chance that the Zune jukebox software refuses to properly update its playlists after you change the *.m3u files, first try deleting them from the application, and then restarting it. If that doesn’t work, you can write a Windows batch script with code similar to the following:

del /q “C:\Documents and Settings\Jonathan\My Documents\My Music\Zune\Playlists\*”
xcopy “\\Vboxsvr\mp3cache\Favorites_cached.m3u” “C:\Documents and Settings\Jonathan\My Documents\My Music\Zune\Playlists”
xcopy “\\Vboxsvr\music\Favorites.m3u” “C:\Documents and Settings\Jonathan\My Documents\My Music\Zune\Playlists”

This script deletes all files from the Zune playlists directory, and then copies each of the *.m3u files that we created with the above perl script directly into the Zune playlists directory. This should force the application to get it’s act together.

Overall, I’m happy with this patchwork job. It allows me to use the Zune on Linux, which is great because the Zune really is a beautiful piece of hardware. Now if only the libmtp guys could get it working natively, without a WinXP VM…

This piece was mirrored at Index out of Bounds




On my Laptop, I am running Linux Mint 12.
On my home media server, I am running Ubuntu 12.04
Check out my profile for more information.

Configuring BlueZync and Failing at Barry

November 6th, 2009 1 comment

After successfully compiling and installing the BlueZync for Thunderbird plugin last night, I decided to take a shot at actually synchronizing my Blackberry with Thunderbird. The first step was a little bit of configuration. For that, I followed this guide on the BlueZync website.

Everything was going fine until I got to the section entitled “Mozilla plugin for OpenSync.” In this section, you are instructed to execute the command ldconfig -p | grep libxpcom.so, which checks if the file libxpcom.so is registered as a symlink on your system. After finding out that it was not, I entered the command locate libxpcom.so from a root terminal, and found three locations for the file in question on my system. I then used the line export LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/iceowl:/usr/lib/xulrunner-1.9 to register the symlink. Unfortunately, even after running the export command, ldconfig failed to find the link. Although this one will probably bite me in the ass later on, I’ll skip it for now.

At this point in the install process, I could access the BlueZync settings panel from within Thunderbird, and run the command line osynctool –listplugins and see the mozilla-sync plugin listed, which is the part of the BlueZync suite that really interests me. mozilla-sync is a plugin for OpenSync that should allow me to interface my Blackberry with Thunderbird (with the help of the Barry libraries, which provide another OpenSync plugin that communicates with the phone).

To continue, it was necessary to install all of the elements of the Barry libraries in order to get their OpenSync plugin that would complete the chain. This is where I may have committed my second cardinal sin – dpkg notified me that in order to install the opensync-plugin-barry package, I had to install a version of the libopensync0 package that was between v0.22 and v0.3. As I understand it, Bluezync already installed some version of OpenSync onto my machine, and I have a feeling that reinstalling a different version may ruin all of the progress that I’ve made thus far.

Indeed, after finishing the Barry install and running osynctool –listplugins again, mozilla-sync was still listed, but opensync-plugin-barry was not. This is strange, as in my last three attempts at this process, getting Barry to show up was the easy part. Now the tables have turned, and I have what I assume to be a properly working BlueZync install, but without the Barry component that would make it all work with my phone.

Back to the proverbial drawing board with me…




On my Laptop, I am running Linux Mint 12.
On my home media server, I am running Ubuntu 12.04
Check out my profile for more information.

(Finally) Installing Bluezync for Thunderbird

November 5th, 2009 1 comment

After some constructive comments from Henrik, the developer of the BlueZync plugin for Thunderbird, I decided to take another shot at getting Blackberry sync working on Linux. This time, instead of making up my own instructions, I actually followed his (which have been updated somewhat since my last visit).

Surprisingly, when I followed the instructions to the letter, the plugin built correctly the first time without any problems. When I launched Icedove (the Debian rebranding of Mozilla Thunderbird), the plugin even loaded correctly! If you’ve read my past posts detailing this process, you’ll feel as incredulous as I did.

The only trouble that I ran into along the way was actually with version 0.9 of the Lightning plugin for Icedove (Thunderbird). Upon installation of the plugin, I was not able to create a calendar, an event, or a task. Turns out that this Ubuntu bug applies to Debian as well, and that the problem can be easily fixed by uninstalling Lightning, downloading and installing the libstdc++5 package, and reinstalling the Lightning plugin. For whatever reason, I could not find this package in the Debian Testing repositories, and instead downloaded and installed it from the Lenny repositories.

With that issue solved, I tried running the ./test-bluezync.sh script, and was met yet again with a slew of failed tests:

21% tests passed, 15 tests failed out of 19

The following tests FAILED:
5 – thunderbird (Failed)
6 – tbird_empty (Failed)
7 – tbird_slow (Failed)
8 – tbird_slow_3 (Failed)
9 – tbird_fast (Failed)
10 – tbird_add (Failed)
11 – tbird_delete (Failed)
12 – tbird_modify (Failed)
13 – light_empty (Failed)
14 – light_slow (Failed)
15 – light_slow_3 (Failed)
16 – light_fast (Failed)
17 – light_add (Failed)
18 – light_delete (Failed)
19 – light_modify (Failed)

However, unlike in past attempts at this install, this time the Bluezync plugin is visible from within Thunderbird… Now all I have to figure out is how to use it. More on that later.




On my Laptop, I am running Linux Mint 12.
On my home media server, I am running Ubuntu 12.04
Check out my profile for more information.

Blackbery Sync Attempt #3: Compiling from Source

October 5th, 2009 7 comments

After my first two attempts at getting my Blackberry to sync with Mozilla Thunderbird, I got pissed off and went right to the source of my problems. I emailed the developer of the opensync-plugin-mozilla package that (allegedly) allows Thunderbird to play nicely with OpenSync, and gave him the what for, (politely) asking what I should do. He suggested that I follow the updated installation instructions for checking out and compiling the latest version of his plugin from scratch instead of using the older, precompiled versions that are no longer supported.

I set to it, first removing all of the packages that I had installed during my last two attempts, excluding Barry, as I had already built and installed the latest version of its libraries. Everything else, including OpenSync and all of its plugins went, and I started from scratch. Luckily, the instructions were easy to follow, although they recommended that I get the latest versions of some libraries by adding Debian’s sid repositories to my sources list. This resulted in me shitting my pants later in the day, when I saw 642 available updates for my system in Synaptic. I figured out what was going on pretty quickly and disabled updates from sid, without ruining my system. If there’s one thing that Windows has taught me over the years, it is to never set a machine to auto-install updates.

Once I had the source code and dependency libraries, the install was a snap. The plugin source came with a utils directory full of easy to use scripts that automated most of the process. With everything going swimmingly, I was jarred out of my good mood by a nasty error that occurred when I ran the build-install-opensync.sh script:

CMake Error at cmake/modules/FindPkgConfig.cmake:357 (message):
None of the required ‘libopensync1;>=0.39′ found
Call Stack (most recent call first):
cmake/modules/FindOpenSync.cmake:27 (PKG_SEARCH_MODULE)
CMakeLists.txt:15 (FIND_PACKAGE)

CMake Error at cmake/modules/FindOpenSync.cmake:46 (MESSAGE):
OpenSync cmake modules not found.  Have you installed opensync core or did
you set your PKG_CONFIG_PATH if installing in a non system directory ?
Call Stack (most recent call first):
CMakeLists.txt:15 (FIND_PACKAGE)

It turns out that the plugin requires OpenSync v0.39 or greater to be installed to work. Of course, the latest version of same in either the Debian main or lenny-backports repositories is v0.22-2. This well-aged philosophy of the Debian Stable build has irked me a couple of times now, and I fully intend to update my system to the testing repositories before the end of the month. In any case, I quickly made my way over to the OpenSync homepage to obtain a newer build of their libraries. There I found out not only that version 0.39 had just been released on September 21st, and also that it isn’t all that stable:

Releases 0.22 (and 0.2x svn branch) and before are considered stable and suitable for production. 0.3x releases introduce major architecture and API changes and are targeted for developers and testers only and may not even compile or are likely to contain severe bugs.

0.3x releases are not recommended for end users or distribution packaging.

Throwing caution to the wind, I grabbed a tarball of compilation scripts from the website, and went about my merry way gentooing it up. After a couple of minor tweaks to the setEnvOpensync.sh script, I got the cmpOpensync script to run, which checked out the latest trunk from the svn, and automatically compiled and installed it for me. By running the command msynctool –version, I found out that I now had OpenSync v0.40-snapshot installed. Relieved, I headed back to my BlueZync installation. This time around, I managed to get right up to the build-install-bluezync.sh script before encountering another horrible dependency error:

– checking for one of the modules ‘glib-2.0′
—   found glib-2.0, version 2.16.6
— Found GLib2: glib-2.0 /usr/include/glib-2.0;/usr/lib/glib-2.0/include
— Looking for include files HAVE_GLIB_GREGEX_H
— Looking for include files HAVE_GLIB_GREGEX_H – found
— checking for one of the modules ‘libxml-2.0′
—   found libxml-2.0, version 2.6.32
— checking for one of the modules ‘libopensync1′
—   found libopensync1, version 0.40-snapshot
— checking for one of the modules ‘thunderbird-xpcom;icedove-xpcom’
—   found icedove-xpcom, version 2.0.0.22
—     THUNDERBIRD_XPCOM_VERSION 2.0.0.22
—     THUNDERBIRD_VERSION_MAIN 2
—     THUNDERBIRD_XPCOM_MAIN_INCLUDE_DIR /usr/include/icedove
—     NSPR_MAIN_INCLUDE_DIR /usr/include/nspr
—     THUNDERBIRD_XPCOM_LIBRARY_DIRS /usr/lib/icedove
—     THUNDERBIRD_XPCOM_LIBRARIES xpcom;plds4;plc4;nspr4;pthread;dl
— checking for one of the modules ‘sunbird-xpcom;iceowl-xpcom’
—   found iceowl-xpcom, version 0.8
SUNBIRD_INCLUDE_DIRS /usr/include/iceowl;/usr/include/iceowl/xpcom;/usr/include/iceowl/string;/usr/include/nspr
SEVERAL
—      SUNBIRD_MAIN_INCLUDE_DIR /usr/include/iceowl
—      SUNBIRD_VERSION 0.8
— Found xpcom (thunderbird and sunbird):
—   THUNDERBIRD_XPCOM_VERSION=[2.0.0.22]
—   SUNBIRD_VERSION=[0.8]
—   THUNDERBIRD_VERSION_MAIN=[2]
—   SUNBIRD_VERSION_MAIN=[0]
—   XPCOM_INCLUDE_DIRS /usr/include/nspr;/usr/include/icedove;/usr/include/icedove/addrbook;/usr/include/icedove/extensions;/usr/include/icedove/rdf;/usr/include/icedove/string;/usr/include/icedove/xpcom_obsolete;/usr/include/icedove/xpcom;/usr/include/icedove/xulapp;/usr/include/iceowl
—   XPCOM_LIBRARY_DIRS /usr/lib/icedove
—   XPCOM_LIBRARIES xpcom;plds4;plc4;nspr4;pthread;dl
—   SUNBIRD_VERSION 0.8
CALENDAR_VERSION=[8]
LIBTBXPCOM_INCLUDE_DIR
XPCOM_LIBRARIES  xpcom;plds4;plc4;nspr4;pthread;dl
ENABLE_TESTING [yes]
TESTING ENABLED
— checking for one of the modules ‘check’
CMake Error at cmake/modules/FindPkgConfig.cmake:357 (message):
None of the required ‘check’ found
Call Stack (most recent call first):
cmake/modules/FindCheck.cmake:27 (PKG_SEARCH_MODULE)
CMakeLists.txt:73 (FIND_PACKAGE)

CMAKING mozilla-sync 0.1.7
— Configuring done

From what I can gather from this output, the configuration file was checking for dependencies, and got hung up on one called “check.” Unfortunately, this gave me zero information that I could use to solve the problem. I can verify that the install failed by running msynctool –listplugins, which returns:

Available plugins:
msynctool: symbol lookup error: msynctool: undefined symbol: osync_plugin_env_num_plugins

Ah, shit. Looks like I’m stuck again. Maybe one day I’ll figure it out. Until then, if any of our readers has ever seen something like this, I could use a couple of pointers.

Barry: Round Two with the Blogosphere riding Shotgun

September 30th, 2009 2 comments

Given the problems that I’ve been having lately with getting my Blackberry calendar and contacts to synchronize with anything in Linux, I was quite surprised when I almost got it working tonight. Forgetting everything that I’ve learned about the process, I started over, following these helpful tutorials and working through the entire install from the beginning. Unfortunately, aside from some excellent documentation of the install process (finally), the only new idea that those blogs provided me with was to try syncing the phone with different pieces of software. Specifically, Chip recommended KDEPIM, although I opted to  jump through a few more hoops before giving in and dropping the Thunderbird/Lightning combination entirely.

After a bit more mucking about, I decided to give up Lightning and installed Iceowl, Debian’s rebranding of Mozilla Sunbird, instead. Iceowl is the standalone calendar application that Lightning is based on, and is a very lightweight solution that is supposed to cooperate with the opensync-plugin-iceowl package. In theory, this allows calendar data to be shared between my device and the Iceowl calendar after configuring the plugin to read my Iceowl calendar from the /home/username/.mozilla/iceowl/crazyfoldername/storage.sdb file. In practice, the sync process gets locked up every time:

Screenshot-PIM Synchronization - KitchenSync-1

Why must you tease me?

Well, I’ve tried everything that I can think of to get my phone to synchronize with any Mozilla product. I’m very close to giving up, which is a shame, because they really are superior products. The ridiculousness of the entire thing is that I can easily dump my PIM data to a folder, and Thunderbird stores it’s data in an SQLite database. If this were Windows, I’d have written a VB app to fix my problems hours ago… Anybody know any python?

Update: I’ve also managed to successfully synchronize my phone with the Evolution mail client. Unfortunately, Evolution looks rather pale next to Thunderbird. In fact, the entire reason that I switched to Thunderbird about a week ago is that Evolution mysteriously stopped receiving my IMAP email with no explanation. No new email comes in, and the Send/Receive button is grayed out. Until now, I was happy with my decision, as Thunderbird is a superior application.

Barry: The Open-Sourced Blackberry Utility

September 30th, 2009 No comments

There is no denying that the installation process for the Barry project sucks. That said, the promise of having the ability to sync my blackberry with a linux-based calendar application like Mozilla’s Thunderbird or the Evolution mail client kept me working at it through the wee hours of the night. The Barry site at Sourceforge provides not one, not two, but four Debian packages (which rely on an additional two undocumented packages), that need to be downloaded and installed in a specific and undocumented order:

  1. libbarry0_0.15-0_i386.deb (sourceforge)
  2. barry-util_0.15-0_i386.deb (sourceforge)
  3. libglademm-2.4-1c2a (debian.org)
  4. barrybackup-gui_0.15-0_i386.deb (sourceforge)
  5. libopensync0 (debian.org)
  6. opensync-plugin-barry_0.15-0_i386.deb (sourceforge)

With the packages installed, I launched a terminal and used the auto-complete feature to find the command barrybackup. At first, I couldn’t figure out what it’s syntax was, until I realized that it doesn’t need any arguments, because it simply launches a GUI (that doesn’t appear anywhere in my Applications menu) that lets you back up your device databases:

Screenshot-Barry Backup

Well, thats a handy utility, assuming that it is also capable of restoring the backups to the device. I shied away from trying the restore feature, as I didn’t have access to a Windows box with which to fix the device should the worst happen.

I’m currently using Mozilla’s Thunderbird (re-branded in Debian as Icedove) as my primary mail client, along with the Lightning calendar plugin, and would be thrilled if I could synchronize it with my Blackberry. You’ll note that libopensync and a Barry opensync plugin were both a part of the installation process; having never used libopensync, I had a tough time figuring out how to make them cooperate.

The opensync page on Wikipedia lead me to install the multisync-tools package, which claims to be able to “synchronize calendars, address books and other PIM data between programs on your computer and other computers, mobile devices, PDAs or cell phones. It relies on the OpenSync  framework to do the actual synchronisation.” I have PIM data that I would like to sync! I have the OpenSync framework! We’re on a roll!

Finally, I installed the multisync-0.90 GUI and opensync-plugin-evolution v0.22-2 opensync plugin packages, which should have allowed me to sync between the Evolution mail client and my phone. I chose to try the process with this software first, as a plugin for Thunderbird was not immediately available. Unfortunately, when attempting to sync, I got this message:

Surprisingly, it was the evolution plugin that failed to connect

Surprisingly, it was the evolution plugin that failed to connect

Useful? Sort of. The Add button let me set up a Blackberry profile with both the barry and evolution plugins, but no matter how I tweaked the settings, I couldn’t get the evolution plugin to connect to my PIM data. Further, after making a synchronization group and adding plugins to it, I couldn’t find a way of replacing a plugin with a different one.

Sick of the limited GUI, I moved on to try KitchenSync, the KDE-based alternative. While it was uglier, I found it to be a far more useful front-end, and managed to get it to sync my device calendar and contacts with my filesystem:

Screenshot-PIM Synchronization - KitchenSync

This process exported all of the calendar and contact information from my Blackberry to a folder full of vCalendar and vContact files on my machine. Now if only I could get Thunderbird to read these files.

After a bit more looking around on the OpenSync webpage, I found a link to these guys, who claim to have programmed an opensync plugin called libopensync-plugin-mozilla-0.1.6 that allows Thunderbird and Lightning to talk to the OpenSync manager. They provide the plugin as a tarball that contains a *.so binary file and a sample *.xml configuration file… but no instructions on how to install them.

Thouroughly lost, I turned to the #opensync channel on freenode.net for help. Until they see fit to help me out, I’m taking a break from this. No sense in giving myself a heart attack out of extreme frustration.

Edit: I got some help from the members of the #opensync channel, who recommended that I drop the mozilla-sync.so file into the /usr/lib/opensync/plugins/ directory. While this didn’t immediately allow OpenSync to see the plugin, I noticed that every other plugin in the directory has an associated *.la configuration file. So I fabricated my own *.la file, and tried again. That didn’t work either.

The members of the channel then recommended that I try downloading the source code directly from the creators. I did as much, and found that it didn’t include a configure or make script, but just the source code. Not knowing how to proceed, I attempted to follow these instructions, which entailed downloading another 20 or so packages, including the sunbird-xpcom-devel package, which again lacks documentation on how to proceed with installation.

Lacking that package, and again frustrated beyond belief, I decided to drop the issue for another hour or so and do some math homework. That’s right, I chose to do math homework over playing with my computer, because this process has been that frustrating.

It doesn’t help that this entire process seems to be aimed at installed BlueZync, and not the opensync-mozilla-plugin. What the hell is going on here?