Android Silliness Part II

Last year I documented at great length a mess I went through when a very straightforward morning radio alarm I had set on my bedroom smart speaker had to be replaced by a Google "automation". That post ended with my having successfully implemented a solution.

Well, that was then and this is now. Google recently introduced Android 16 and I recently upgraded my phone from a Pixel 6a to a Pixel 9a. One or both of those events killed my morning alarm. Instead of hearing Google's voice telling me "streaming NPR on WKAR" (my local NPR radio station), I heard "OK, here's a playlist from YouTube Music" followed by some noises that I suspect are used to soften up presumed terrorist before interrogating them.

This was baffling in several ways, starting with the fact that I have never, ever instructed Google to play random music from YouTube Music early in the morning. More baffling is that when I went into the Google automation settings, my morning routine was still there, still marked enabled, and still listed as doing the same things: playing the radio (station = WKAR FM) on the bedroom speaker. Manually triggering it, however, did not work.

I have no idea what the problem was (is), but I eventually found a work around. I changed the "action" setting from playing the radio (one of a menu of possibilities controlled by a multiple select input) to a "custom" action (selected via "Try adding your own (Experiment with custom actions)". That opens a text input where you can type pretty much anything you might verbally ask Google Assistant to do. In my case that meant "Stream WKAR FM radio". To date, that has worked, which I assume means Google has engineers working on a fix for it.

If any Google engineers are reading this, may I recommend consulting the "Redneck Repair Manual" (page 1): "If it ain't broke, don't fix it."

 

Android Silliness

Once upon a time I bought an Insignia smart speaker (with Google Assistant baked in) for my bedroom. I could set an alarm that would stream my choice of radio station using verbal commands ("Hey Google, set a radio alarm for ..."). It worked so well that Google decided to fix it.

At some point I saw a brief item in a tech feed about Google eliminating radio alarms in favor of some sort of automation thing, but my speaker kept on working and I ignored the story ... to my own peril. A few weeks ago, I canceled the existing alarm. When I went to set a new alarm, the speaker's response was "I'm sorry, I don't know how to do that."

After a bit of research, I discovered that the Google Home app now has something called "automations". It turned out a bunch of predefined automations were set on my phone, none of which ever did anything (because I never uttered the necessary incantation?). None were anything I wanted, so I turned them all off and created a new one. Automations involve one or more "starters" (in my case, every day at 6:57 am), one or more "actions" (in my case, play the radio station I want) and a "configuration" (in my case, play it on the bedroom speaker). You can test the automation by tapping a button (and I did). It worked when triggered manually.

So began the adventure. On day 1, the new automation failed to do anything. I woke up on my own (belatedly), changed the time to five minutes or so after I awoke (call it 7:20 am), and it worked. So I reset it to 6:57 am, and the next day it again failed. Eventually I found a notification hidden away somewhere that the automation had failed due to scheduled down time being set. I went to the settings menu in the Home app, found "Digital wellbeing", and sure enough there was a downtime setting. It was set to expire at 8:00 am, leaving me confused as to why the 7:20 am test had worked, but whatever. I deleted it.

Next morning, no luck. I went to the settings for the speaker and found it had its own digital wellbeing setting, which I also deleted. Still no luck, and no notifications I could find as to why it did not work.

I'll skip over the details of a very unsatisfying online chat with a level 1 Google support person (who did not seem to grasp that the 7:20 test working implied that the speaker really was connected to the home WiFi) and an email exchange with a level 2 support person who wanted the speaker's serial number among other things. (That was two weeks ago. Nothing back so far.) With some experimentation, I discovered the following. If I set the alarm time prior to 7:00 am, it did not work at all. If I set it to exactly 7:00 am, it triggered at 7:00 am the first day and 7:02 am every day thereafter. If I set it to 7:01 am, it triggered at 7:01 am every day. (Note that the 7:01 setting triggered a minute before the 7:00 am setting did, which offended me as a mathematician due to the lack of monotonicity.)

Ultimately I got another notification about something to do with downtime, which made no sense to me since I had deleted the downtime settings for both phone and speaker. So I went into the phone settings (not the Home app, but the phone itself). After considerable vertical scrolling, I found "Digital Wellbeing & parental controls". Wallowing around in that, I found a "Bedtime mode" (which was turned off) and a "Do Not Disturb" menu. "Do Not Disturb" was turned off on the phone, but fortunately I got curious and burrowed into the menu. In the "General" section of that menu was a heading named "Schedules" saying I had three schedules set. Two of those were "Gaming" and "Game Dashboard" (no idea what they do or why they were turned on). I forget the title of the third one (I have since renamed it "sleeping"), but that turned out to be what was blocking the alarm. I left the start time at 11:00 pm and changed the end time to "6:45 am next day". It had been set to 7:00 am, which apparently was what caused issues. You can customize what things get blocked (via "Do Not Disturb behavior"), but I didn't bother. Curiously, there is a switch labeled "Alarm can override end time", which was (and remains) turned on. Since that did not allow the automation to trigger before 7:00 am, I assume it only applies to alarms and not automations.

With that tweak, the radio alarm via the speaker started working at 6:57 am, and so I am tentatively going to declare victory. Why we need digital wellbeing setting scattered all over the place under various names is a mystery to me, one of many.

NOOK for Android: Bugs or "Features"?

I bought a NOOK Color when it was new on the market, and use it to read both books and magazines. Lately, though, I'm more likely to read magazines on a 10" Android tablet using the NOOK reader application for Android. It works well enough, with one glaring exception: periodically it refuses to download new issues of magazines, claiming the disk is full (which it is not).

I'm not sure exactly what causes NOOK to think it has a storage limit, but given the existence of such a limit I can see why NOOK believes it is reaching said limit. When you are done with content on an NOOK device, you have the options to either delete or archive the content. According to the FAQ for the NOOK app, archiving content theoretically removes it from your device but keeps it available in the cloud, from whence you can download it again if you want another look. Deleting content deletes it permanently; it does not remain available from the cloud. So archiving is generally the preferred route ... except that the part about deleting it is not entirely true.

After once again running out of space, I decided to go spelunking with a file manager. I found a folder (/Nook/Content/.Temp/Drp/) containing .epub folders for various archived issues. All told, a few hundred megabytes of storage were being consumed by issues that theoretically had been deleted from my tablet.

I did a web chat with a customer support person from Barnes and Noble, and at one point (s)he had me sign out of the NOOK application and then sign back in (which syncs the library). I pretty much never sign out of the app, having no particular reason to do so. Woo-hoo, all the archived issues were gone! Sadly, so was an issue I had downloaded but not yet read. There was no problem downloading it again, other than consumption of time and bandwidth.

I asked the support person to file a couple of bug reports. As far as I'm concerned, having to sign out and back in to free up space is dopey. I might add that I had previously synced the library (without signing out), and that did not deleted the .epub folders for archived content (despite the NOOK app correctly listing the content has having been archived). I also think that losing active (not deleted, not archived) content when you sign out is a (separate) bug.

We'll see if those things get fixed, but in the meantime my workaround is to use the file manager to delete .epub folders with old dates whenever the NOOK app tells me I'm out of space.

Controlling 3G/4G in Jelly Bean 4.3

My phone (a Samsung Galaxy S3) updated itself to Android 4.3 this morning. I'm sure it has all sorts of wizardous new features (most of which I'll never use). One feature that is somewhat handy is that you now have some control over which "quick setting buttons" you have in the notifications panel (top of the screen), and in what order they appear. If you swipe down from the top to expose the notifications stuff, you'll see the usual rows of buttons plus a new (I think) button in the upper right, as in the following screenshot.

Tap the button in the upper right, and you get an expanded display of the quick setting buttons.

Now tap the edit button (looks like a pencil), and you get a screen that allows you to drag and drop buttons within and between two groups, those displayed by default and those displayed only in the expanded view.

Unfortunately, there is some bad news: the quick setting button to turn mobile data (3G/4G service) on or off has been removed. I went online and found various people complaining about this on phone company support forums. I can't blame them for complaining -- this is a feature I use fairly frequently when traveling -- but I think the complaints may be misplaced. I doubt that the service providers (Verizon, Sprint, etc.) had anything to do with eliminating the button. It's possible it was a decision by the hardware vendors (Samsung, did you do this to me?), but may also be a "feature" determined by Google.

The good news is in two parts. First, you can still turn mobile data on and off by going through the device settings menu, although it's buried fairly deeply. Second, there are free third party apps that provide alternative ways to toggle data service. One very nice one is Notification Toggle (henceforth "NT"). Once installed from Google Play, it will drop a launcher icon somewhere on one of your desktops, as seen in the next shot.

You'll also see an icon in the upper left corner of the notifications bar, telling you that NT is running. Tap the launcher to get to the NT home screen.

There are lots of things you can set in NT, but for our purposes the next step is to tap the icon to the left of the program name.

Now tap the Toggles menu item to get a list of built in buttons.

The number available is truly impressive. Scroll down a bit and you'll find one for "Mobile data". Put a check next to it. (You can see in the shot above that I also added a button to turn on flashlight mode from the notifications screen.) There's also a button labeled "4G", which I assume controls whether you use 4G when available or 3G only. Now go to any screen and swipe down to expand the notifications bar.

In addition to the usual stuff, you get some new buttons (circled in the screenshot above). The one on the left toggles flashlight mode; the one on the right toggles data service on (lit) or off (unlit, as in the shot above).

Problem solved.

Minor Device Mysteries

I have a couple of mildly annoying, though thankfully not crippling, issues with computing devices. Honestly, the fact that I cannot figure them out (the mental itch I cannot scratch) devils me more than the issues themselves. Interestingly, they may both turn out to be sleep disorders.

MythTV

I have a PC running Mythbuntu and dedicated to recording and playing back TV shows. I've written about it before (click "MythTV" in the label cloud, bottom right, if you're curious), including setting it up to wake from a G3 (unpowered) state to record shows or capture program database information. As I mentioned in an earlier post, neither of these works correctly. I find that I have to reload the database manually, and I occasionally find the PC waking for no apparent reason. The latter always seems to happen at 8:00 p.m. local time, which (I think not coincidentally) is 0000 GMT. I'm not positive, but I suspect it only happens when the MythTV front end is showing no scheduled recordings. Initially, I thought this was when MythTV was going to grab program data, but when the PC starts at 8:00 pm (and no recording is scheduled at that time), I check the MythTV front end, and it says that MythTV is idle (which the more detailed information provided by the back end confirms).

Instructions for setting the BIOS alarm clock (see the ACPI Wakeup document for MythTV) specify that the alarm should first be cleared, as the following line from the setwakeup.sh script illustrates:

echo 0 > /sys/class/rtc/rtc0/wakealarm      #this clears your alarm.

I'm left wondering if some script is writing a zero to wakealarm after the last scheduled recording takes place, and if this somehow translates into a (persistent) wakeup call for midnight UTC.

Update: I've fixed this; details are here.

Android

I have a Toshiba Thrive tablet, which by and large has served me well. For months after Android 4 ("Ice Cream Sandwich", also known as "ICS") came out, the Thrive stubbornly remained on Android 3 ("Honeycomb"). A week or so ago, Toshiba finally rolled out the update to ICS.

I'm not sure what all the hoopla about ICS was, but I suspect the improvements most important to me (if any) are under the hood. The user interface got new icons (woo-hoo) and a feature to unlock the device using facial recognition (except this did not make it into the Toshiba version). There's now rather usable handwriting recognition built in, but only on the Google search page in the Google browser (another woo-hoo). You can now close apps by swiping them out of the list of running apps, which is a nice feature.

I use an iGo Stowaway portable Bluetooth keyboard (no longer listed on iGo's web site, so I suspect it's been discontinued). It worked fine before the upgrade, but after I installed ICS I started running into problems where the Thrive would not recognize the fact that I was typing on the keyboard (but did tell me, in the Bluetooth settings, that it was seeing the Stowaway and treating it as an input device). Eventually I deleted and paired the Stowaway, and that seems to have reduced the frequency with which it is ignored ... but not eliminated the problem completely.

The more annoying issue, though, is battery life. Google "android ics battery life" and you quickly discover that a variety of people, on a variety of devices, are complaining that their battery life has decreased greatly since installing ICS. In my case, I'd guess that it is roughly halved, although that's a very subjective estimate. (Yes, I believe in the importance of analytics. No, I haven't bothered to track this, at least not yet.) Some people have issues with their screens not turning off, but that is not the problem on the Thrive. The power indicator should blink when the Thrive is in sleep mode, and with Gingerbread and then Honeycomb it did so consistently. With ICS, sometimes it does, sometimes it does not (meaning the power light stays on, even though the screen does go dark). Either way, a surprising amount of the charge drains when the device is sleeping (about 25% over ten hours). So I have to be diligent to recharge early and often.

I just checked the battery settings. (This is another plus for ICS: it give more detailed information about the battery. Now if I could only find out how to interpret it ...) The Thrive had been on battery for 16:44 (all times here are hours:minutes -- ICS gives seconds as well, but that's rounding error to me). It was down to 72% of full charge, so 28% bled off while it was sleeping. According to the battery info, Android OS accounted for 75% of battery use. Drill down, and then turns into 1:26 for "CPU total" and 5:44 for "Keep awake".

Now I have the device in airplane mode when it sleeps, so the WiFi and Bluetooth should both be off. Why the "keep awake"? Is this because I have antivirus (Avast, which I happily endorse) installed? Is it because I did not shut down all possible apps before sleeping it? Do Google Reader or the Google Play Store try to keep the device awake when there is no Internet connection and it's supposed to be sleeping?

I guess I'll have to try to remember to clean out all running apps before I put it to sleep tonight, and see if that affects battery life.

Update: Apparently running apps are not the culprits. I shut down everything I could last night (antivirus, for one, being excluded) and let the Thrive sleep. After 15.5 hours on battery, 26% of the charge drained. Battery use by Android once again dwarfed use by anything else, and the ratio of keep-awake time to CPU cycles was 4.5:1.

Android Remote Control for VLC

This is part of my continuing adventure setting up MythTV at home. (You can find related posts by clicking the MythTV label in the tag cloud on the lower right portion of the page.)  Having set up MythTV, I copied over backups I'd made of my Windows Media Center recordings.  It turns out that they are recorded in a somewhat proprietary format (.dvr-ms file extension).  I'm sure you are as shocked as I am that Microsoft would deviate from the file format standards adopted by, oh, the rest of the world.  At any rate, it is theoretically possible to transcode those files into something like MPEG format, but after one failed attempt I decided not to bother.  These are TV shows I intend to watch once and then delete, and VideoLAN's VLC player, which is available and multiple platforms and a standard part of many (most?) Linux distributions, handles .dvr-ms files nicely.

I've used VLC (frequently) on PCs, but always when I was sitting at the keyboard watching a (typically short) video.  Watching a TV show means sitting at a distance from my TV (and keyboard), so I needed a way to control VLC from a distance.  (It was either that or watch the commercials.)  Enter Remote for VLC, a free VLC remote control app by Peter Baldwin, available for Android devices (such as my Toshiba Thrive tablet) from Google Play (formerly known as the Android store).  There are several VLC remote control apps on Google Play, but this one has one of the highest customer satisfaction ratings, has a very well done interface, and is free.

I have a Wi-Fi network in my house, including the computer running MythTV and VLC, and of course including the tablet.  My version of VLC is "2.0.1 Twoflower".  There are setup instructions for the app online, and I found general instructions for enabling VLC's web interface several places, but not of them exactly matched my setup, so I though I would post my steps here in case they might help someone else.

First, you have to enable the built-in web interface to VLC.  In VLC, click Tools > Preferences, and at the bottom left set Show settings to All.  Expand Interface and select Main interfaces.  Put a check next to Web.  (This is the first place where I had to deviate -- slightly -- from posted help, which mentioned "http".)  Now exit VLC.

Find VLC's .hosts file and open it in your favorite editor.  On my Mythbuntu box, the path is /usr/share/vlc/lua/http/.hosts.  On the PC I'm using right now (Linux Mint), the path is /etc/vlc/http/.hosts, but both /usr/share/vlc/lua/http/.hosts and /usr/share/vlc/http/.hosts symlink to it.  So you may have to do a little detective work, bearing in mind that file names that start with a period are hidden by default (so use ls -a, click ctrl-H in Nautilus, or do whatever is analogous in your file manager of choice).

The troubleshooting instructions say, somewhat vaguely, that you should edit this file after you find it.  Specifically, you need to enable whatever address or range of addresses will be used by your remote control device.  My Wi-Fi network uses non-routable addresses in the 192.168.whatever.whatever range.  So I found the line containing the mask 192.168.0.0/16 and uncommented it by removing the initial hash (#) character, then saved the file.  The file contains masks for all standard private network ranges, so you just need to know what range covers the address your device will be using.  If you will be using a device that is not on the same network as the PC running VLC, you will need to add a line enabling the specific address of the remote device (and make sure the device can communicate with the PC, i.e., that you don't have a firewall that will block the remote device).

Once you have saved the modified .hosts file, start VLC.  (VLC needs to be running so that the remote device can see the built-in web service.)  Make sure your Android device is connected to the network, and start Remote for VLC.  It will scan for VLC servers and, hopefully, find yours and add it to its internal list.  You can tap the menu button in the upper right and select Settings to verify that it is connected and see whether it found your VLC server.

With that, you should be good to go. Have fun exploring the controls.

Android-Linux File Transfers

I recently acquired a Toshiba Thrive tablet (Android Honeycomb, currently version 3.2.1), in part because it comes with two USB ports (one full size, one mini).  The USB ports theoretically allow me to move files between my Ubuntu PC and the tablet by mounting the tablet as a disk drive on the PC.  I say "theoretically" because Google recently moved to Media Transfer Protocol for handling connections over USB. This seems to be okay for Windows PCs and Macs, but for Ubuntu (and other Linux systems) it requires using the mtpfs package. I've found connections to be excruciating slow, and for some reason (probably a setting I'm missing), when I do get connected, all I see is an empty root and an empty Playlists subdirectory. Trust me, there are tons of files on the Thrive.

Fortunately, I found WebSharingLite File/Media Sync, a free app in the Android Market. (As one might expect from the "Lite" part, there is a paid version, rather economically priced.) I have a WiFi DSL gateway at home (and of course my laptop has WiFi). Running WebSharingLite on the tablet, I can connect via a web browser from my PC or laptop and upload/download files considerably faster than what mtpfs over USB seems to allow. (Again, though, I should stress that there's no guarantee I'm setting up mtpfs correctly, despite hours of poking around the web looking for help.) The connection requires a password; coupled with the fact that it's on a nonroutable segment, behind the firewall in my gateway, I think the security is adequate.

I can definitely recommend WebSharingLite.