Rant-reprise: Intel's 7260 pci-e Wireless card...

This time round, my cross-hairs are trained firmly at the heart of the behemoth Intel.  As one or two of my previous posts will affirm, I'm a huge fan of Intel's wireless cards.  After years (literally) of suffering at the hands of Atheros cards in general, and the Linux-driver developers in particular, along came Intel - or rather, I bought an Intel card! - and all was well with the world again, at least the bits that had to do with my computer experience anyway!

Apart from a slight hiccup with my first Intel IWL3945 wireless card, which came bundled with my now long-in-the-tooth Dell XPS M1210 laptop, the performance of the new(er) Intel 5100 card has been close to exemplary - no drama, no fuss, it just works!  This I presumed was a result of Intel wretching from the hands of Linux developers, all thoughts of writing their own drivers, and supplying them with a 'binary-blob',  that could be packaged in a software 'wrapper' for Linux OS's, but nothing else - Intel took sole responsibility for the cards operation.   This policy seemed to work.  Then along came the 7260...

More specifically, the card I bought is a N-7260HMW.  I bought two cards actually - one an Intel, and to cover all bases, the other was a Broadcom.  Both were half-length, single-channel, and included Bluetooth 4.0.  But let's just stick with our little Intel saga for the moment.

Out of the gate, I had problems with the 7260.  The wireless performed perfectly, it was the bluetooth that gave me headaches.  From the get-go, I was using it in the Dell laptop, so that I could enjoy the great sound of my M-Pow bluetooth headset to the fullest.  Prior to the 7260, I was using the ancient bundled Broadcom bluetooth, that would disconnect after 15 minutes - so regular was it in fact, that you could almost set your watch by it!  The 7260's main problem was getting its bluetooth to start at boot-up.  It either started or it didn't, the latter occurring about 50% of the time.  The only recourse then was to reboot and try again, at least initially.  I later discovered that merely Suspending and restarting would do the trick as well.  But either way, it often took several tries before Bluetooth would initialise.  Once started, 'pairing' proved somewhat of a chore with the M-Pow, but I'm inclined to believe that this has more to do with them, than with Intel's offering.  Though once 'paired', everything was rosy, you could listen via Bluetooth for hours on end.

I noticed one curious thing however.  The laptop has two pci-e slots, labeled 'WLAN' and 'WWAN'.  Up till now, I had always figured that they were electrically identical.  Introducing the 7260 to the WLAN-slot however results in no bluetooth whatsoever, whereas it worked in the WWAN slot - so something is different!  That got me curious about how the card would perform in other motherboards, and that was when the shit really hit the fan.

I have two ITX pc's, one a 7 year old Zotac with an integrated quad-core Atom CPU, the other a just-bought ASrock mobo, which takes an AMD Athlon 5350 processor.  Given that the Asrock is a Zotac replacement, it's maybe truer to say that I have just the one ITX-pc, but both motherboards were tested as follows, and with identical results.

With the 7260 in the Asrock mobo, and Deepin Linux fired up, Bluetooth starts but is unusable.  After hours & hours of fcuking about, the only way I could get the M-pow headset to pair with the 7260 was from the terminal.  Once paired & connected, the connection was solid, as was the sound-quality.  But try as I might, I could not repeat the pairing, even from the terminal - clearly, the 7260 was not going to be usable on the ITX powered by Linux.   As I had a barely-used installation of Windows 7 on the same SSD, I thought I'd give it a shot, just to see the level of service the 7260 should be capable of delivering.  Only to recieve the biggest shock of all...

Go to Intel's web-site, you will find that there is no shortage of drivers available for downloading, so finding appropriate drivers took mere minutes.   The following hours & days were consumed by trying to find ANY DRIVER that worked!  There were none - I couldn't believe it!!!!!  I mean, this is INTEL!!!  They have either a flawed hardware version (7260) out there, or else they are incapable of fixing the 'Bluetooth problem'.  And yes, had I searched beforehand, I would have found dozens & dozens of people complaining about the exact same problem.  But I repeat, this is INTEL!  How incompetent must they be, that after 4+ years they are incapable of fixing a problem like this, and for Windows no less! - remember, this card first same out in 2012?!?!?!?  And the problem seems to also be effecting the newer generation 7260's as well, the 7260-AC's for instance.

To reiterate, with Window's System 7, the 7260's Bluetooth doesn't work - PERIOD! That to me is incredible!  With Linux Mint, and Intel's binary-blob driver, the failure to start problem excepted, Bluetooth performs incredibly well.  99 times out of 100, it is the opposite, Linux users always seeming to get the thin end of the wedge.  Granted, Bluetooth is almost unusable with Deepin Linux, so maybe I got lucky with Mint.  I even downloaded a Linux-lite (AntiX, 590megs) live-CD to test this conjecture, and admit that I could not get Bluetooth to work on that either, although wireless worked perfectly.  Intriguingly, I also tried the 7260 with a relatively ancient Ubuntu 12.04 live-CD, and was surprised to find that now its Bluetooth worked perfectly, although I had no wireless, due to a 7260 driver not being available back then.  So, a mixed, but generally positive performance where Linux is concerned, whereas Intel can't even get its own hardware working with Windows 7.  Shame on you Intel.  

But there was always my fall-back, the Broadcom 4314.   Curious thing about this card was that it was not even detected when inserted, in any of my computers!  After countless more hours trying to coax this thing to life, I finally admitted defeat, but out of curiosity, lifted the soldered-on RF-shielding to see if I could see anything amiss.  Sure enough, the main Broadcom chip had a little blackened 'volcano' rising from it near its centre - the chip had been fried!  This was sold as a new item, so it just goes to show that some Chinese Sellers (Ebay) will sell you anything.

Right now, I'm again on the lookout for another half-length wireless card, the only type that will fit in the Asrock motherboard.  Given my experience with the 7260, one thing I'm sure about is that it will not be an Intel!

Edit:  Seems like the wireless component of this card is flaky as well.  Since posting this, I've had multiple instances of the 7260-wireless just switching off, the only recourse left being to reboot the computer.  Unsurprisingly, 7260-Bluetooth also takes the unscheduled hiatus or two as well.  So yeah, the 7260 is a confirmed POS on all accounts it seems.  I've ordered a couple of Broadcom half-length pci-e wireless/bluetooth cards which hopefully will perform better, and allow me to jetison this turd.   Only reason I'm still using it is for the bluetooth.  I'm back to using the full-length Intel 5100 card for wireless.

Edit1:  I bit the bullet and re-ordered the Broadcom 4314 wireless card.  I had definite deja-vu pangs after installing it on my laptop running Linux Mint.  Wireless worked, Bluetooth was detected & enabled, but its resolutely refused to even detect any other bluetooth device, let alone pair with it.  Same with Linux Deepin.  As a last resort, I gave it a go on Windows 7.  After several hours of searching, I eventually managed to find drivers that worked.  Had I just downloaded the first driver I had come across, I would have saved myself a lot of time.  This was (to me) an astronomical 237meg in size, which I presumed contained drivers for all of the Windows platforms, so spent ages downloading smaller files - none of which worked properly.  Turns out the wireless driver is about 30meg, whereas the Bluetooth driver is a huge 220megs - both of which I eventually found & installed seperately, but it would have been so much easier to have downloaded the large 237meg package.

Even with the Bluetooth driver installed, Window's Device Manager happy that everything was working properly and my Mpow headset successfully paired, Bluetooth still wouldn't work!  The problem was that there was no Bluetooth option being added to Window's 'Audio devices'.  After another hour of messing about, as a last resort I got Windows to 'Troubleshoot' Bluetooth, and was surprised when it found a missing Bluetooth driver, something Device Manager hadn't flagged.  Once this was installed, Bluetooth worked wonderfully!  As I type this, I am listening to crystal-clear Bluetooth audio on the Mpow from another room while typing this on the laptop, the Windows 7 PC streaming the audio while also re-coding a large HEVC movie with Handbrake. :)

So, yeah, a thumbs-up for the Broadcom card (specifically a BCM943142A0) on Windows 7, it's just a shame that Bluetooth doesn't seem to work at all on Linux.  I guess I'll have to go back to using the Intel 7260 in the laptop - though imo, the Intel 7260 still sucks!

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... 

NaturalReader 14 text-to-speech application rant...

I have been a long-time user of NaturalReader, initially having bought version 6.6, which over time, I managed to upgrade online, up to version 9 in fact, before being informed that I was no longer entitled to any more free upgrades.  Being also a long-time Linux user, I loathe paying for software, especially where there is a perfectly adequate free alternative available.  Well, there wasn't in this instance, on either Windows or Linux - hence, the purchase, along the lines of $40 if memory serves!

In my opinion, the speech-engine used by NaturalReader is by far the best available, and which is licensed by NaturalReader from the mega-corp, AT&T.  Although the Google speech-engine is very good, IMO, it still falls quite a bit behind its AT&T counterpart, particularly where higher speech-rates are concerned, though this 'edge' comes at a cost.  AT&T's approach uses very large libraries of speech samples, or the phonemes-parts thereof, whereas Google, judging by its speech-engine footprint, uses a different technique, and though smaller, is less effective.  So, although the AT&T (henceforth NaturalReader, or 'NR') approach necessitates the use of more disk-space/processing-time, the end-results are I think, worth the effort.

Just recently, out of curiosity more than anything else, I searched out a demo of the latest-and-greatest (sic) NR online, deciding to give it a spin.  What immediately caught my eye was the installation size, a whopping 200meg - version 6.6 was about 25meg, whereas version 9 comes in at just under 50meg.  So I figured that all those extra megs must be doing something interesting, and sure enough, NR now comes with a built-in Optical Character Recognition (OCR) feature, which piqued my interest still further.

Given that I'm stuck with using long-defunct VirtualBox'ed Windows XP's (Win7 being both too slow and taking up too much disk-space) I thought this would  prove to be a problem.  Imagine my surprise when it installed without a hitch.  Then imagine my disgust at finding that it would not run without NET 3.0 having to be installed!  After downloading and installing this, re-running NR saw it spring to life.  Or maybe 'lurch' is more apt - it's painfully slow to load, and more so in operation!  But imagine my disgust at finding that this 200meg behemoth doesn't include any proper voices - you are stuck with using Microsoft's Sam, which is, ahem, less than adequate.  So off I go asearching again, this time for a disk containing my 'Mike-US' voice for NR 9, all 700megs worth.  After installing this, I was relieved to find that it was detected and worked without a problem, albeit as I mentioned, a mite sluggishly.

Next up, a check of NR's OCR prowess.  Or at least that was the intention.  In practice, it crashed every time I tried it!  So, the main reason for installing it in the first place proved to be its epic-fail.  Sucks huge.

But my main reason for this blog entry is to point out one simple fact.  Although NaturalReader has 'progressed', at least version-wise, from 6.6 to 14 on my watch, the speech quality of the files it produces has not improved one iota!  What you are getting now for your money ($120 for the 'Pro' version) is a piece of bloatware that NaturalReader keeps adding bits to in order to justify the version (and price) increases.  Versions 6 through to 9 were definite lack-lustre affairs.  These softwares were so badly designed, that, for example, you could not search & edit a piece of text simultaneously - you needed to close the Search dialogue prior to editing text due to the shoddy 'modal' nature of the Search menu employed.  This was barely acceptable with Windows 3.1, never mind Win-XP and beyond.  NaturalReader 14 fares little better in my opinion.  Huge file size, dependent on NET, therefore slow as hell, topped off with crashes at the bits that may be of interest.

Do yourself a favour and leave this dog alone.  Granted, NaturalReader produces some of the best text-to-speech output there is, but kudos must go to AT&T for this, not the still-lame attempt by NR to 'package this TTS-engine proficiently.  If you must go with NaturalReader, search out version 9.  Primitive as hell, feature-wise, but it's fast, and sound quality is still the same as with version 14, and it's NR's best attempt, before it became completely dependent upon M$ NET.

Ruizu X06 Review.

It's been a long time since I invested in a mp3 player, about 12-14 years in fact - that was the CMTech CA-F200 that I have posted about here already.  That 'only' has 1gig of memory, though for the time, was seen as more than adequate.  But time marches on, so after buying a MPow Bluetooth headset on Amazon, I figured a mp3-player upgrade was also in order - enter the Ruizu X06.

First off, price-wise, this is a steal, especially when you consider what I payed for the CMTech model - around $80 versus the $21 I paid for the Ruizu X06!  Spec-wise, it is also far better.  Playback-time is spectacular (allegedly, I haven't had it long enough to know!) at around 80 hours - that's about 4 times the once-amazing 20 hours from the CMTech.  Memory wise, it's 'only' 4 times that of the CMTech, coming in at 4gig. However, this is almost not a consideration since it has a micro-SD slot, taking cards up to 64GB.  Like the CMTech, it also has a built-in FM radio that allows the user to record broadcasts in either WAV or MP3 formats - a huge plus in my eyes, even though after 14 years, I have used the same functionality of the CMTech only a couple of times.  But it's nice to have!  Then there's the main reason for buying the Ruizu X06 - Bluetooth audio-streaming.  Finally, the icing on the cake, support for multiple audio formats - as well as the standard mp3, wma, and wav formats, it also handles ogg, flac, ape and aac.  Ogg playback was the one I was most interested in, given that I convert all of my audio-books (400+) to this format.  It also has a cool colour LCD 1.8" display that allows you to watch (converted) videos, or to read ebooks.  Personally, to me these are just gimmicks and something that I'll never use.

So, how does it perform?  To begin with, I was anxious to find out if it worked with my Bluetooth headset, as I'd seen a few people complaining that it didn't work with theirs - it does, perfectly!  Sound quality is also excellent.  Although it comes with a manual of sorts, it is in fact easier to figure things out for yourself.  Once this is done, the flaws start to become apparent.  Hardware-wise, this seems a sweet deal - its problems are firmware-related.

What quickly becomes apparent is that the Bluetooth feature hasn't been properly implemented - you might even say that it looks more like an after-thought!  You can have the sexiest hardware in the world, but it all counts for naught if you don't have the firmware to exploit it - and this seems to be the case here.  The Bluetooth firmware addition is clearly a software-bodge that has been added to the already-existing Ruizu X02 firmware, and it shows.  Entering the Bluetooth menu, you find that once you enable Bluetooth, you are then 'locked' in the Bluetooth menu - you have rudimentary playback options that allow you to playback music from here, but you cannot simultaneously listen to music via Bluetooth while accessing other non-Bluetooth menu options - ie. browse folders, change playback-style, read ebooks, browse album-art etc. etc.  You cannot even fast-forward/reverse through an audio track from within the Bluetooth menu.  In other words, all of the stuff that is accessible & usable when using wired headphones, cannot be used when listening using Bluetooth - no doubt because it was easier to bolt on a software 'kludge' to an already-existing piece of firmware, than take the time to properly integrate the new Bluetooth features!  This also means that during any mp3-player session, you find yourself continually having to re-enable Bluetooth every time you access any of the non-Bluetooth menu options, which gets real old, real fast!

What really pisses me off about this 'Bluetooth-bodge' is that it also contains a huge ogg-specific bug.  With Bluetooth enabled, you find that the ogg-format is no longer available as a playback option, even though it is available & plays fine when using wired headphones.  How can a so-called software developer have signed-off on this firmware without checking basic stuff like this first?  Other users are complaining about playlist-sorting bugs, ebook viewing bugs, no 'lock-keypad' option etc. but imo these are small-fry problems compared to this.

Moving on, next up for critique is the Ruizu X06's 'Playlists' feature.  This mp3-player is capable of holding 64gig + 4gig of music files - by any standard, that is a potentially HUGE number of music tracks, in the order of tens of thousands of files for any reasonably large mp3 collection.  One would therefore think that a mp3-player manufacturer, Ruizu in this instance, would provide firmware capable of catering for such music libraries - not a bit of it!  The 'Playlist' option, where the user is allowed to build lists of favourite tracks, is a case in point.  While you can indeed theoretically add any file from your library to a playlist, what you find is that in practice, you must potentially scroll through EVERY file on the system in order to do so!!!  This is perverse!  It will not even allow you to select single tracks from individual folders (never mind, 'add the entire folder') in order to create your playlist - it just lists alphabetically the entire contents of internal memory or any SD-card!!!  Potentially 10,000+ files to scroll through if the track you want begins with 'Z'!!!  This is unbelieveably stupid!  It renders the Playlists option unusable where any large music collection is concerned.

Lastly, there's the playback of music itself.  This is a confused mess.  You start playing music by way of 2 different routes (3, if you include Bluetooth, but for simplicity, let's forget about that one!) - the 'Music' menu, and the 'Folder view' menu. First off, why are there 2 (3) routes, when all achieve the same thing - more bloody stupidity!  Going via the 'Music' menu, you are greeted with various 'hard-wired' track-sorting methods - 'All Songs', 'Artist', 'Album' and 'Genre' being the main ones of interest.  Being 'hard-wired', none of these sorting methods can be enabled/disabled by the user - it's a case of take it (one option), or leave it!  The problem with this is that this setup depends entirely on the mp3-tags being set correctly - which is very often not the case - otherwise you are often presented with almost-empty folders.  More to the point, what happens with compilations that contain many different artists, from a variety of different albums - take the 'US Billboard Top 100' for instance?  It renders it almost unusable, is what happens!  Which I suppose is why the firmware developer(!) added the separate 'Folder view' menu - so let's try it!  Navigate to a folder, and click on a track.  One might reasonably expect that music would be played from that track, onto the last one in the folder - and one would be wrong!  What actually happens is that it plays to the end of the folder, then starts the next one - and on and on till it plays every track on the system.  This happens because there is no 'Play music from... [option]' selection-menu here, like there is available from the 'Music' menu...

Confused enough?  Well, like I said, the firmware on the Ruizu X06 is a convoluted, confused mess!  The firmware on the old GMTech CA-F200 is a dream in comparison.  It really sticks in my craw that someone actually got paid for producing such a pile of poo.  It really stinks.

But every firmware has bugs I hear you say - wait for a version upgrade!  In an ideal world, yes - unfortunately, although Ruizu supply a firmware upgrade app, they (apparently) do NOT provide firmware upgrades!  After much searching, this seems to be the general consensus as well, which sucks - probably something to do with the extremely low prices they are asking for their players.

This would have been a beautiful mp3-player with well thought-out firmware - unfortunately, what you get is fine hardware let down by some awful firmware, with seemingly no hope of future firmware upgrades.  Shame.

Edit1:  Well, that's a mite depressing.  I've just done a battery-endurance test and I'm underwhelmed.  With a fully charged battery, and the volume set to a comfortable listening value of 7 (of 30), I got a run-time of about 38 hours - a long, long way from the 80 hours quoted, never mind the 100 hours that is sometimes mentioned.  Up to hour 37, the battery indicator was still showing about 70% remaining - so it's a fairly crap indicator in practice!  Just goes to show why most seem to take Chinese manufacturer claims with a pinch of salt.

Edit2:  After a little more research, I find that hardware-wise, the Ruizu X06 is almost identical to the AGPtek A06, though the internal memory is twice that (8gig) of my Ruizo X06.  I gather from a AGPtek-forum comment, that the AGPtek A06 is the model that is marketed internationally, with the Ruizo-brand aimed more at the Chinese/Asian market.  AGPtek more realistically list its playback time as 50 hours, which tallies more closely with my finding.  Battery life while using the radio is quoted at just 10 hours, about the same as achieved by the old CMTech CA-200 [new CMTech radio-test: with a freshly-charged Eneloop 1900mAh AA battery, and with a pair of headphones attached at volume-level 12 (of 30), it achieved an incredible 21-22 hours!].  However, another black-mark against the Ruizu is that its FM radio is mono-only, at least according to the the AGPtek A06 manual!  I actually dug out the old GMTech and did some off-air recording with both - sure enough, the CMTech records a stereo-track, while the Ruizu's is in glorious mono!  [New research: Ruizu uses a single Bluetooth/stereo FM-radio i.c. (RDA5876).  The CPU (SoC ATJ2127) also has 2 channels for stereo-FM, but appears to be 'sacrificing' one of them to the Ruizu's voice-recorder function].  Even when using the Ruizu's own earphones (as antenna) with the CMTech, it also has far better reception as well.  There apparently was a reason the CMTech was more expensive than the Ruizu - you get what you pay for I suppose!
 
The good news is that there is a software upgrade available for the AGPtek model, which should also be compatible with the Ruizo X06 - downloadable from here.  From reading AGPtek forum comments, the bad news is that I probably have the most current firmware already, so there would be no advantage to reflashing the unit.  I would also end up seeing a AGPtek logo, rather than a Ruizo one, at startup.  It's nice to have for emergencies though.  The 'no ogg with Bluetooth' bug is also known about with AGPtek, but they view it more as a limitation than a bug!  Call it what you want, it still sucks!

Edit3:  Another really stupid firmware bug that has become apparent is that whenever the unit is powered-off via the software route, (holding the red button down for a second or so) it will invariably power itself on again on its own, after a certain amount (an arbitrary amount, it appears) of time.  Initially I thought  that it was a 'feature' that I had accidently enabled, but there's nothing (bug, excepted) that should cause that to happen.  Stupid software developers!

Note:  This 'bug' turned out to be temporary in nature.  After restoring its factory settings, the problem vanished.  HOWEVER, I've also just noticed it powering itself up, just for a second or so, before powering itself off again - not like before, where it would continue to operate until the battery was exhausted.  [Nope, I have now observed this 'auto-power-up' happening so many times with the Ruizu, that it almost seems like a 'feature' - sigh...]  So, yeah, flaky firmware affirmed.

Edit 4:  Just happened to do a search on Youtube and found this link to the X06 firmware - finally!!!  Also pointed to in the comments section, there is mention of someone upgrading the Ruizu successfully with AGPtek software.  Well, after successfully upgrading the Ruizu with the Ruizu firmware, I thought, what the hell, so tried flashing it with the AGPtek firmware as well.  Mistake - it flashes ok, but I was left with a white screen, no graphics whatsoever.  Thankfully, reflashing with the latest Ruizu firmware again rectified the situation.

And what refinements are introduced by upgrading from 1.00 to 1.10 firmware?  As near as I can make out, zero, as far as added options are concerned anyway.  I was at least hoping those clowns would add a lock/unlock keypad feature, but all that's apparent is a new "Welcome" startup screen graphic that replaces the original "Ruizu" graphic entirely - so maybe another reason to not upgrade.  No doubt there are also bug-fixes as well, but seeing as I'd come across no major bugs with the version 1.00 software, who knows!

In case anyone finds it of use, or it vanishes from the Youtube link above, I've uploaded the Ruizu X06 firmware (including flasher app) to Google Drive, downloadable from here.

Note, in the comments below, one user 'bricked' his X06 after flashing it.  The same thing happened to me - it would no longer switch on - BUT it was not a terminal condition.  While my Ruizu was no longer seen by the computer as "Ruizu" per-se after being 'bricked', it was detectable as an unknown USB device once the USB cable was removed/reinserted.  It was then restored to life by reflashing.  

32-bit computers - my Linux Mint woes.

Amongst the Linux distros that I deem warrant some of my precious harddisk-space, Mint has earned a coveted spot, mainly due to its long-term support for its stable releases - the current one is good till 2019.  It has become apparent to me however that this 'support' is spotty at best, particularly where 32-bit hardware is concerned.  Anyway, Mint/Mate-desktop was/is set to eventually replace Ubuntu 10.04 on my setup - progress, and all that.

Although I've had problems with Mint from the get-go, two issues have been particularly annoying on my 32-bit laptop from the beginning.  One, Caja's audio-preview has a bug where, while 'previewing' an audio file, the file-manager itself would freeze, requiring that it be forcibly closed.  And two, already-generated thumbnails would be deleted each time you logged-out/rebooted, necessitating that Mate generate all of the thumbnails-cache over again - a time-consuming, CPU-intensive process.

With the latest major upgrade of Mint having been recently made available, now up to 17.3, it was with a heavy heart that I discovered that not only are these two bugs still alive & well, things have actually gotten worse.  Now, thumbnails are deleted throughout the session, so there is no rest-bite at all!  I actually contributed to a bug-report on these problems here about 6 months ago, although these problems have existed for much longer than this.  Then, I also discovered a way of fixing the thumbnail-bug, which involved patching the source-code before recompiling.  The Caja-freeze problem was fixed by 'merely' recompiling the Caja package.  'Merely' is emphasised for a reason - unfortunately, Mint doesn't make things easy for you, with its current Caja-build requiring many separate packages, whereas Git's Mate/Caja compiles everything into a single package.  What all this means is that you can get conflicts between installed Mint-built packages, and those that you build locally from Git source when you try installing them.

Fixing it!

As stated in the long-winded version above, this only effects 32-bit Mint 17.x setups, in this particular case Mint 17.3 (Rosa).  Three packages need to be rebuilt;

mate-settings-daemon (thumbnails bug)
caja (audio-preview bug)
caja-extensions (so we don't lose extensions, like 'caja-share')

Essentially, you should build these packages yourself from the Mate-Git repository, and in the case of 'mate-settings-daemon', first applying this patch, but in case this all seems a bit too much, I'll provide links to the packages that I built for my setup, but with the warning that it is always risky to install 'unknown-packages' on your computer!  You of course need to first remove the affected packages, so as a first step, remove the following Mint-built packages;

mate-settings-daemon-common (which will also remove 'mate-settings-daemon')
caja-common (which will also remove 'caja', plus a few more)
gir1.2-caja (causes a dependency-issue otherwise)

Now things get a little tricky!  Most people will want to hold onto the 'mate-control-center' application, which the Mint developers have seen fit to have made 'caja-common' one of its dependencies - a part of the main app we are replacing!  Our new Caja-build, although functionally identical, is built differently, incorporating all of its required dependencies (like 'caja-common') in a single package. So in order to get things to play nicely together, a little subterfuge is called for.  The easiest thing to do was when building the 'caja' application, to build it as 'caja-common' - that way, when re-installing 'mate-control-center', 'caja-common' is seen to be already installed, so the installation will proceed.  Short version - only one Caja package is installed, the newly-built 'caja-common', which contains everything needed, extensions excepted, while also satisfying the 'mate-control-center' dependency issue.  So, install the following new packages;

caja-common
caja-extensions
mate-settings-daemon

And then reinstall 'mate-control-center'. The final step is to add a new entry to Startup Applications (System->Preferences->Personal->Startup Applications) that will auto-start 'mate-settings-daemon' each time - name it 'mate-settings-daemon' and set its 'Command:' line to "/usr/libexec/mate-settings-daemon".

That's it!  Logout/reboot and everything will hopefully be hunky-dory.  The only casualty of doing all of this seems to be that you can no longer change Caja folder-colours, as there's no code for this function available in Mate's Git repository.  On the upside, you do get up-to-date versions of these packages (1.13 versus 1.12), as well as no longer suffering the indignity of Caja continually locking up, or thumbnails being continually regenerated.

Edit1:
I didn't expect to be returning to this, but here I am! I suffered a mini-meltdown on the Linux front today, after a software lockup, followed by a somewhat impatient physical switch-off of the computer.  Mistake.  When my Linux installation would no longer boot, I went the suggested route of doing a manual 'fsck' - Mistake 2.  I was greeted by (what turned out to be) 100's of 'inode' errors, to which I blithely Yes'd all of the prompts to repair.  Mistake 3.  Although it would now boot, it was obvious that the damage was extensive - Caja or Nemo for instance refused to run.

Though things looked bleak, I knew I still had the backup of Mint 17.3 that I had made before my aborted attempt at replacing it with Mint 18.1 - 7 months old, but good enough.  The OS image rewrite got about half way through the process when the writing software complained that the saved OS image-file was corrupt - despite having been on a different partition! - and it needed to reboot.  Now it appeared, not only had the crash completely fcuked up my 50GB OS partition, but my 200GB data storage partition as well - FUUUCCKKKKKK!!!

On recovering, one fresh installation of Mint 17.3 later, followed by an online software update, I discovered that ALL of the bugs that existed over 2 years ago in Mint 17.3 are still there - really disheartening.  Compiz for instance, still does not work.  Neither have any of the bugs mentioned in this post been fixed, nor has the ability to mount ISO's greater than 2GB - so much for 2 years worth of "Development".

But to the point of this edit.  After the fresh install of Mint 17.3, I set about fixing the bugs noted here by downloading the files & following the instructions listed above.  To my surprise, for the most part it worked!  I had installed so many packages on the old setup over the years that I felt sure that some dependency issue with a fresh install would have arisen - but no!   The only problem that I encountered concerned the Caja extensions.  The Mint developers have a one-package-per-extension policy, whereas the single extensions package that I built contains all of the extensions.  The only problem this caused me was that I first had to locate & remove 4 or so extension packages that had already been installed, before installing my 'all-in-one' "caja-extensions" package.  No biggie, just irritating.

Other than that, I'm almost back with a working system.  Compiz caused me the most problems.  With all versions since 2014 unworkable on my now ancient hardware, and after a fruitless internet search for ppa's containing the sought-after versions, I eventually was forced to go trawling for the individual packages themselves - an onerous chore, or so I thought!  Turned out that Canonical's site layout makes it really easy to locate all of the needed files - just do a search from this page (this for the 'Trusty' software-base), select the package, then your CPU architecture, then download the file, just a few clicks for each file, easy peasy!  The only challenge is discovering the order that these (9) packages then need to be installed in, as many treat others as dependencies.  I could list their install-order here, but where would be the fun in that!

Edit2:
I hate a mystery, so I decided to hunt down the reason for Mint 17.3's 'Disk Image Mounter' not working.  It's not confined to Mint either - I know from experience that it doesn't work with the 32-bit version of Deepin Linux 15.4 as well, so basically the Debian package itself is broken.

The problem is that, compilers, on their own, for 32-bit builds, default to defining variables as 32-bit numbers, unless explicitly told otherwise.  However, many programs need to work with numbers whose magnitudes can greatly exceed 32-bits - 'gnome-disk-utility' for example and the package of interest here, may encounter disks of many terrabytes in size.  'Little' 32-bit variables are no longer sufficient in situations like this, and require the use of 64-bit variables instead.  In the past, 'gnome-disk-utility', properly programmed, had no problem doing this, and long before 64-bit CPU's were even widely sold - so it has nothing to do with "ancient hardware" as many suggest. So what has changed?  It seems obvious, with fewer & fewer 32-bit computers being used, less and less testing is being done of 32-bit applications running on 32-bit hardware.  Understandable in a way, but imo, unacceptable where obvious bugs are allowed to occur across multiple version releases, often spanning YEARS - 'gnome-disk-utility' being a prime example.

Technically, all that is required is the following one-liner at the start of the code;

#define _FILE_OFFSET_BITS=64

I tried to do this on my 'fresh-install' of Mint 17.3 but failed miserably as it resisted all of my attempts to install some of the needed development packages.  This I think was down to my having added a ppa ('mc3man') to my setup in order to acquire 'ffmpeg', which 'Trusty' doesn't have in its repositories.  As this version is 'current', I suspect that up-to-date dependencies were also installed which had the effect of breaking 17.3's old libraries setup. Whatever the reason, I instead opted to install a 'fresher-install' of Mint 17.3 on another drive and try to build it on that.  It worked - another bug bites the dust!  'gnome-disk-utility' 3.12 is the result, downloadable below.

gnome-disk-utility_3.12.1-1_i386.deb

Incidently, while playing with the 'fresher-install', I also installed the working version of Compiz, realised that it was even more of a chore second time round, so made note of the packages installation-order, listed below.

libdecoration0_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compiz-core_0.9.11+14.04.20140409-0ubuntu1_i386.deb
libcompizconfig0_0.9.11+14.04.20140409-0ubuntu1_i386.deb
python-compizconfig_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compizconfig-settings-manager_0.9.11+14.04.20140409-0ubuntu1_all.deb
compiz-plugins-default_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compiz-plugins_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compiz-gnome_0.9.11+14.04.20140409-0ubuntu1_i386.deb
compiz_0.9.11+14.04.20140409-0ubuntu1_all.deb

Edit3:
Another 'tweak' to my setup before backing it up, in readiness for the next crash!  This time it's the file-manager Thunar.  Although Caja is obviously my file-manager of choice, Thunar has its uses, as it's much faster & efficient memory-wise at thumbnailing lots of pics, and also has a really nifty extension application called 'BulkRename'.  As I had already read that the 'current' 1.6.10 version in the Trusty repositories was buggy as hell, I initially opted to install an earlier version that is still in the repositories - version 1.6.3 - couldn't get it to work properly, so decided to build from source, version 1.6.11 instead.  This I did, but on running the following little test, discovered that it too had another (different) bug that also caused it to freeze.  The test simply creates some files in the folder of your choice (first line) then continually renames them.  Leaving said folder open in Thunar would normally result in it locking up within a few minutes.

 for i in $(seq 1 10); do touch "$i.txt"; done
 while true; do for i in $(seq 1 10); do mv "$i.txt" "$i.txt.txt"; done; sleep 1; for i in $(seq 1 10); do mv "$i.txt.txt" "$i.txt"; done; sleep 1; done

After some more reading, I found that the 'freezing' bug has (hopefully) been fixed as of version 1.6.12.  Below is the package that I built, which has one dependency (exo-utils) that will be downloaded & installed automatically.  Even so, one thing that caused me a major headache was that although all of Thunar's dependencies are accounted for, on my 'build-machine', Thunar would run, whereas on my 'work-machine' it wouldn't, complaining that a certain shared library was not found.  Yet there it was, plain as day, for all to see!  After searching aimlessly for inspiration for what seemed like an age, I eventually came across this post on a French forum that provided the solution.  Merci!!!  Run as root;

ldconfig

That's it!  Not sure exactly what it does but after running it, the shared library was found and Thunar now works.  The above test has been running on it for over an hour with no lock-up - so fingers crossed!  One other thing, I've had to "--exclude" one item from the package when building it with 'checkinstall' - /usr/local/share/icons/hicolor/icon-theme.cache.  This as it happens is also part of my 'gnome-disk-utility' build, and while I'm not entirely sure as to its purpose, I do know that Thunar appears to function perfectly well without it - even with 'gnome-disk-utility' not installed.

thunar_1.6.12-1_i386.deb

Note:  While adding this 'fixed' Thunar to my Deepin Linux installation, an issue arose.  Without having first installed Thunar from the repositories, BulkRename refuses to run, even after issuing the 'sudo ldconfig'.  Investigating, apparently the 'repository-install' creates a symbolic link (named "Thunar") to "thunar", which is in the same directory.  This requirement is part of a "dirty hack" - Thunar-source comment - to get it to run on the Xfce desktop.  My build on the other hand, does not create this symbolic link to "thunar" that BulkRename needs,  so it doesn't work, pure & simple!  If this occurs, first create the symbolic link manually - ie. do a;

sudo ln -s /usr/local/bin/thunar /usr/local/bin/Thunar

Then do a sudo ldconfig to include this link in the rebuild of the 'symbolic links to shared libraries cache'.  From reading, 'ldconfig' is normally done automatically whenever an application is installed via 'makeinstall', but since I'm building a discrete package with 'checkinstall', this does not occur.

Edit4:
 Never figured on an Edit4 for this old post!  I recently became fixated on getting the appImage of 'Avidemux' running on Mint 17.3.  After discovering that Avidemux 32-bit versions were no longer a thing, I had the cunning plan of installing Mint 17.3_64-bit alongside my everyday OS, so side-stepping the issue.  This ultimately proved futile, because as others had discovered before me, recent (yet, going way back) appimage builds use updated libraries that never made it to the Mint 17.3 repositories.

 Nevertheless, with the 64-bit version installed, I decided to enable Ubuntu's 'esm' critical updates service, particularly when I (re)learnt that it would extend the life of this old girl, all the way to April 2024 - cool!  I then resolved to fix the 'audio-preview freezing bug' as I did here for Mint 17.3 32-bit.  Below are the new Caja builds, which also feature a version-upgrade bump to 1.14.2.  There's no messing about this time with caja-common as described above - just install the new Caja & caja-extensions, leaving the old caja-common in-situ.

caja

caja-extensions

I'm an Android Owner... finally! First Impressions.

I've intentionally avoided getting involved in the smart-phone/tablet mania of the last few years.  In truth, I didn't see the need for one.  My trusty old Dell laptop, over 10 years old now, can still handle anything I can throw at it - and no, I'm not a games-player, apart from the odd game of Mahjongg, so no state-of-the-art hardware needed here!  Phone-wise, I still have an old Samsung SGH-D500 (original battery too) that is more than adequate of my humble needs.

But a Dragon x10 tablet owner I've become, for better or for worse.  Being a hater of all things Microsoft, and a Linux-buff with 8 years experience using that OS, an Android-based tablet was always going to be my first and only choice - Android of course having derived from Linux.

First, a word about the hardware.  The x10 sounds on paper a fairly impressive beast.  ARM7-based, it features a 8-core CPU, clocked up to 2Ghz, a snappy GPU, 1Gig RAM and 16Gig internal memory, 5M-pixel/2M-pixel cameras, coupled with a wide-viewing-angle 10.6" screen - all for €130, available from Amazon Germany.  Incidently, it is available marginally cheaper from Amazon UK - or would be, if they shipped to Ireland, which they don't - hence the German sourcing.  Fuller details on the x10 are available here.

So yeah, for the price, it's a well-spec'ed piece of kit, and very snappy in use.  It comes with a 7600mAh battery and claims some impressive run-times between charges - so I decided to do a quick test with a looped video.  With a fully-charged battery and using MX-player with hardware-decoding enabled, I managed to get just short of 13.5 hours of continuous video playback from it - which I found kinda amazing!  I should also add that that was with the minimum screen brightness, namely because that's the way I use it normally, but it also had both wireless & bluetooth enabled at the time, as I had forgotten to turn them off.

Firmware-wise, my x10 came with Android Kitkat 4.4.4.  Amazon UK had claimed that Tablet Express (the x10 manufacturer) was selling them with the new & improved Lollipop 5.1 before I had ordered, so I was disappointed to discover mine was Kitkat-based when it arrived.  Lollipop was available as a download from T.E though, so it was an opportunity to compare & contrast both systems.  I played with Kitkat for about a month before upgrading to Lollipop.

Upgrading proved a real ordeal too!  Although T.E don't make clear what Microsoft OS's are compatible with their upgrade software, as it looks like something that was produced for Windows 3.1 (so really bad) I presumed XP could easily handle it.  No such luck!  Try as I might, over the course of two days, XP resolutely refused to work with the upgrade-software.  I eventually had to borrow a copy of Win7 and to temporarily install that, all just to upgrade the x10's firmware!  It was also the first time that I had ever installed Windows 7 on a 'real' machine (I used it once with VirtualBox, but it had proven too slow) and must admit given my past recollections with Windows installations, this was a much improved experience.

Anyway, onto Android itself, and (imo) the whole setup's Achilles-heel.  First, its good points.  On the x10, most user-actions are super-slick.  Obviously a lot of thought has gone into the user-interface.  You also have more software available for it than you will ever get a chance to try - if you can ignore all of the ads!  But given that I'm old-school (my first computer was a Sinclair Spectrum) and more interested in the implemention, and know from experience just how good Linux's multitasking capabilities are, I was surprised at the obviously poor job that Android does on this front!  Given that there are 'proper' Linux distros that come on installations as small as 10Meg (Core Linux) I know that it doesn't take gobs & gobs of memory to create a 'proper' multitasking environment.  This Android does not do!  I was even more surprised to discover that earlier versions of Android had no multitasking capability at all!  Rather than a System Monitor (or Task Manager in M$ parlance) where the user can monitor & interact with running processes, all Android has is the Back-button - and it is not at all clear what this does!  Sometimes this will terminate an app, sometimes it will just send it to the background.  A perfect example of this sloppy implementation involves the use of Browsers for surfing the net.  Boot Firefox, open your favourite page, do some reading, hit the 'Recently used apps' button to start say Gmail, then head back to Firefox - what you find is that FF has been terminated, and is forced to reload its entire setup!  This sloppy handling cannot be down to lack of memory - I have 1Gig after all!!!

It is hard to come to terms with this shoddy performance, especially given that Android is derived from Linux, which has being doing 'proper-multitasking' since forever!  I can only surmise that Google has been putting all of its development effort into the GUI - but that still doesn't explain their not using already-existing technology!  I have even read that Google/Android, rather cynically, terminate/reopen apps intentionally in order to generate more revenue from the ads having to be reloaded!  If Google is following this route, then they will eventually end up getting their just desserts.

Long before Google even existed, Microsoft & Yahoo ruled.  Yahoo in particular I remember as dominating cyber-space.  And they really took the piss!  I recall how Yahoo would lace their search-engine results with irrelevant links (mostly porn-related) and to hell with what the user was searching for.  Along came Google, offering a really good search-engine with the minimum of unobstrusive ads - and they cleaned up!  If they are now going to go and undo all of that good work by producing a half-arsed OS that intentionally starts/stops apps, just so they may generate a little more revenue, then they are idiots and deserve to be kicked off of their pedestal.

After the initial novelty of the tablet, I find myself going back to the laptop more & more.  Sure, the tablet is handy, indespensible in some ways - I forgot to mention its bluetooth-headset music capability, which is superb, and its main-use here nowadays.  But being somewhat of an OS-purist, imo, Android is a huge step-backwards as far as proper multitasking is concerned.

Edit:
A quick addendum.  3 - 4 months down the line, here are a few more thoughts on this purchase of mine.  First off, one thing I didn't mention above, and something that has existed from the get-go, is that this x10 tablet suffers from a charging problem.  The charger itself is your typical cheap-and-cheerful Chinese type, complementing the tablet perfectly.  The problem is that when you plug it into the tablet's charge-socket, the tinest movement of the charger's lead will cause intermittent charging - I have often set it to charge overnight, only to find next day that no charging has taken place!  Given that the charger-plug itself looks fine, I initially thought that it was a soldering dry-joint that was causing the problem.  After carefully opening the tablet - no unscrewing necessary, it's of the 'clam-shell' variety - I am now (thankfully) again of the opinion that it is probably the charger-plug after all.  Although a dab-hand with a soldering iron, given the component dimensions involved (sub-millimeter resistor/capacitor sizes, which is kinda scary!) I really didn't want to go messing in there.  The circuit board is also tiny, especially considering the tablet's size - probably 100mm square all told.  Thing about the charger is, it's a 'custom-type', with a teeny 2mm charging plug - so no place to buy another to see if that would fix things!  Another charging-related problem is that occasionally when you plug in the charger, the tablet completely freezes.  This is really disconcerting, as the only thing you can then do is hold down the power-off button and hope!

Regarding Android, one thing I've discovered is that despite all the 'anti-rooting' articles I've come across, after you use Android for a while, rooting is the only way to go!  Two places where a rooted-device is essential, ad-removal and Bluetooth-GPS.  Before I rooted my tablet, no matter what software I installed, I could not get my Bluetooth GPS-dongle to work with the tablet.  Once rooted, things 'just work'!  Same goes for ads-removal - internet browsing with an unrooted Android is generally a pain, often unusable.  Once I installed 'Adaway' on my rooted device, browsing became a pleasure again.  My opinion of Android itself has not improved one iota either.  If only Unix/Linux could sue Google for bringing its superb multitasking capabilities into disrepute - seriously, it sucks!!!