25 May 2016

Linux CD/DVD Cataloguers (GWhere & CdCat) rant...

I've got about 300 DVD's, and perhaps 100 CD's, choc-full of mostly media stuff, whose contents I keep track of using the application GWhere.  In spite of the fact that this app was last updated in 2007, it is quite good at what it does, it's only real problem being that it doesn't register a new DVD being inserted, and so has to be exited & restarted before it will read its contents.

So, everything was rosy on that front, until recently.  I had noticed with Ubuntu 10.04, that whenever I ran GWhere, sometimes, very noticable graphics-corruption would occur surrounding the text-font it used.  Although annoying, this wasn't a show-stopper until recently.  With Mint 17.3, this now results in the OS entirely locking up, something that is very, very hard to achieve with Linux.

As this is completely unacceptable, alternative solutions were tried.  First, as I suspect that this has something to do with an old Gtk graphics library being used, I tried building the package from source, in the hope that it would sort things.  This proved to be a non-starter however, as the new(er) Gtk libraries are no longer compatible.  Next I tried running the Win32 version under Wine, which worked to a fashion.  Unfortunately, whenever you move the mouse-pointer over a Gtk-control, the mouse-pointer disappears!  Assigned keyboard shortcuts seem to work, but this is not an acceptable solution either.  Finally, the only thing that worked properly was to install the Win32 version on a VirtualBox'ed Win-XP and run it from there - something I'm not at all happy with, but beggars can't be choosers!

Another disk-cataloguer that I had heard good things about, and development-wise, had only been abandoned in 2014, was CdCat.  This also had options to 'import' the contents of other Cataloguer softwares, which I had hoped would work with my already-existing GWhere database files.  No such luck!  Although it can import from 11 different Cataloguer applications, GWhere isn't one of them - which is stupid, given that as there were only 2 main contenders on the Linux scene in the first place (GWhere & CdCat) you would expect the CdCat developer to specifically cater for GWhere files.  Or rather, it doesn't import the data in a usable form.  The only import option that works is the really old (circa 2003) Linux 'Gtktalog' format.  After extracting the compressed database file using 7zip, and adding a 'csv' extension, all the data is imported, but no directory structure is retained - rendering it useless!  Incidentally, GWhere also has 'Import/Export' menu options, but unfortunately they are just there for show - what you have in reality are just a 'hook' entry-point for import/export plugins, something that was never developed...

Anyway, given that most of the available versions of CdCat that are built, don't use the most recent source - Ubuntu's 'Trusty' repository for instance has a positively ancient version 1.8, in contrast with the 'newest' CdCat 2.3.1 source - and particularly since its web-page lists the huge number of bugs that were removed in the final versions, I decided to build it from scratch.  Not a trivial matter either, as it turned out.  Some libraries are no longer compatible, some are completely missing.  I eventually found all of its various dependencies and managed to build the package, which can be downloaded from here by anyone so inclined.

It was only after going through all of this, that I discovered that CdCat could not import GWhere's databases - WHICH SUCKED!!!  I also then googled an old post of mine on the Ubuntu forum, something I'd completely forgotten about, where I criticised CdCat's speed at reading DVD's - up to a minute to read a disk, which is ridiculous!  I haven't tried the newly-built version, but I've little doubt that it's the same.  GWhere in comparison, takes 1-3 seconds.

So, I either stick with my present convoluted GWhere setup, or I laboriously re-create all of the databases from scratch using CdCat.  Hmmm, or maybe start looking for something Windows-based... 

No comments:

Post a Comment