uTorrent Windows not responding at startup

July 10, 2020

TL;DR: Make a clean install and just copy resume.dat (if you care for it), or everything but rss.dat.

I booted up my Windows uTorrent seedbox again, and am long overdue for moving to qBittorrent. I have about 3000 torrents, so it’s a pain to switch over, and none of the “convert resume.dat” tools seem to work. I’ve got some renamed files and all files are relocated, so this will take a few hours by hand. For now, I will continue to use uTorrent.

Randomly some time a couple weeks ago, it started hanging immediately after startup, but using normal amounts of traffic. I just let it be, but got around to figuring it out and thought I’d share.

I made a clean install and just brought resume.dat over, but that excluded my RSS feeds. As soon as I brought in rss.dat, the hanging started happening again. Maybe it’s due to rss.dat? I didn’t bother to verify this since I didn’t care enough to find out (it’s not my software, and I’m running away from it.)

Honestly, I should’ve guessed to just do this sooner, but not much was lost compared to this impending migration.

Emulating the “Available” status when using Hangouts on Android

May 22, 2014

If you don’t know already, Google+ Hangouts works with Google Talk on the backend, which uses XMPP (well, I suppose a variant of it) at its core. The thing is, as I mentioned in a post last year, an installation of Hangouts keeps one instance of your login (XMPP supports multiple logins) that’s always “Away”, regardless of whether your device is screen on, screen off, or even offline!

Many of us are aware of “status” in the old Google Talk. This still exists at the core, since the core (XMPP) has not changed. Hangouts does two things on the frontend, to shift towards an “just send the message” mentality:

  1. Hiding “offline” status from your “buddy list”.
  2. Your device no longer reports its XMPP instance as “Available” when your screen is on. In the past, this was an option that defaulted to “on”. It is useful to know when someone is “available” on their phone.

Since XMPP shows you as the “most available” out of all of your instances’ statuses, if you can make yourself Available on one instance, you can make yourself Available at the account level. I don’t think anyone (except me..) really pays attention to which devices you’re away/available from, so this is “good enough”.

I’ve come up with a ghetto, not-rocket-science method to emulate #2. By using a second IM client on my phone, which also features “away when screen off” (and thus implying “available when screen on”), I can get back the old behavior that Hangouts should really have.

I’m using Xabber. It’s not in the notification bar, and if I swipe away the application, it eventually gets closed (OS garbage collection of sorts.) However, on boot, it seems to stay persistently open, even without being present in the notification bar or recent-applications list.

This is good enough for me, and if I happen to ever bring up the application for some reason, I can’t swipe it away, so I just reboot.

Per-device settings for Google+ Location Reporting, post-Latitude era

August 29, 2013

In the Latitude era, the Maps app had settings to report location data to your Google account. This included a global account-wide setting, and a newer “Report from this device” setting. However, after Google axed Latitude in favor of Google+ Locations, they changed not only the frontend, but the backend as well. Gone are the familiar options to disable reporting from a specific device.

I turned on my tablet (HP TouchPad running a CyanogenMod build of Android) which I haven’t turned on in weeks. Since it stays at home, of course, the “Report from this device” option was always unchecked. I updated all my apps, and got the new Google Settings app. Then I saw that my location kept being set at home, even when I was out, so I was zigzagging at impossible speeds.

Looking around the settings on the tablet, there was no obvious alternative to “Report from this device”. I looked around and the options were not only less powerful, but less clear and more confusing. Since there were only a few options (“Location Reporting” and “Location History” on/off for my Google account completely), I figured it would be best to just try them.

Under myemailaddress@gmail.com, I turned “Location Reporting” from on to off. To me, this disables it from the entire account. They shouldn’t word it this way when they know that people have multiple devices – and they should’ve been aware of the “only report from specific devices” situation when making the old product’s replacement. But alas, they did not. I don’t know what Google is thinking nowadays, but their releases are getting sloppier, when they should be getting better.

Google+ Hangouts for Android update is snappier – no more message queue delay

August 29, 2013

This was one of my previous complaints about the new Google+ Hangouts for Android app, the Talk for Android replacement.

It looks like messages now appear as sending, immediately after hitting Send. Before, there was a seemingly random delay, perhaps associated with latency – which was weird, because you had to wait for it to appear to send, then wait for it to send.

Canon EOS 5D Mark II loose connectivity with Speedlite flash

August 19, 2013

This applies to any Canon EOS body, I suppose, and any flash. I’m using a Canon Speedlite 580EX II flash.

Some time late last year, my flash started going TTL, firing full power at my friends’ faces. They were blind, and I was blind too (as to why that was happening.) In the 2-3 times that I’ve used my flash since, I’ve seen it happen, and just switch to manual flash exposure, which is a huge pain to get right.

I thought something was really wrong with my body or flash. I tried another flash and it worked. I tried another body and it worked. Huh? I was able to get to the flash config menu……… sometimes. I eventually got it to consistently work and fail, by tilting the flash a certain way. Then I knew it was a loose connectivity problem.

So I finally Googled around and found a 5-minute answer. http://www.conraderb.com/flashrepair/

Apparently, the screws on the shoe were loose, and needed tightening. That alone did the job. Quite irritating that it inconvenienced me that much, but at least it was only that much, and the fix was fast.

Goodbye Google Latitude – hello Google+ Locations.. kinda

August 19, 2013

About a month ago, in its series of retiring good products, Google decided to axe Google Latitude.

Actually, Google Latitude was just short of perfect – the setup process was very confusing for a new user – you had to allow Google to access your location, THEN define if that particular device could update your location, THEN add or confirm friends that wanted to share your location with you. Sharing should be a one-way permission – that is, you shouldn’t have to accept my invitation to share my location with you. I’ve said before (though not here) that location sharing should be modeled after Google+ circles.

And here we are. Actually, when I first read that Latitude was going away (from 2-3 articles), none of the articles mentioned that it was only the frontend and the Latitude API – the location history dashboard with all the data was going to stay. Neither did those particular articles mention that location sharing would still exist, but through Google+ Locations. I only found that out when I read directly from the source, Google – but I’m quite surprised that I managed to go through a few articles without finding out.

Of course, I jumped to try to use the new service right away. I shared my location with a few friends, and had them share their locations with me. and then I discovered.. just about every feature from Latitude was missing, and the implementation was pretty broken in general.

1) The map doesn’t render on devices where Google+ is installed as a user app, instead of a system app. This affected everyone  (including myself) with a custom ROM. And a month later, even after Latitude was taken away, it still wasn’t fixed. Fortunately, there was a Titanium Backup update which fixed the “convert to system app” option failing on a few apps (coincidentally, Google+ was one of them, at least for me.)

2) The pins don’t show up as a Layer in the Maps app. This was useful for, you know, seeing your friends on a map, using the flagship Maps product. You used to also be able to navigate to their location. You have to go into Google+, then Locations, to see the map with friends on it.

3) This map uses an old render of Google Maps, and it looks awful, AND is less-featured.

4) No reported location accuracy. I encourage my friends to keep WiFi and WiFi location services on, to get good location accuracy. But sometimes it’s inaccurate, and I just get confused when the pin goes to a certain point on the map.

5) No reported location age. There’s nothing like my friend being out of town, but his location still shows as nearby, because it’s a 1-(or more)-day-old location.

6) No desktop viewer. Nuff said. You can actually see the location of an individual, by going to their Google+ page. That’s an awful implementation, though. You need to be able to see them on a map! Even worse, the map renders when you mouse over, too – but it looks fucking awful. Also, if the person defined a cover photo, it occupies the space of their cover photo, and even loses scale!

7) No iOS support. How the hell do you replace a product when you haven’t even offered iOS support yet?

8) No way to request a refresh from another user with automatic updating on. One cool part about Latitude was that the refresh button would actually attempt to get a new location from all of my friends with auto-update on.

9) No way to navigate to a friend. This doesn’t affect me that much, but too many people are crying about it.

Edit: I finally got yesterday (August 14)’s update, which looks like it resolved #1, #3, #4, and #5. I’m almost not angry at Google!

Edit2: posting this draft really late..

Mac OS X Server 10.8 (Mountain Lion) Apache server listens on ports aside from the one defined by “Listen” in the apache config file

August 9, 2013

I had defined “Listen 8080” in /Library/Server/Web/Config/apache2/httpd_server_app.conf (if you have Server installed, it’s NOT /etc/apache2/httpd.conf any more), but for some reason, it was also listening on ports 80 and 443. No, apache, I want you to listen on 8080, and I wanted to leave 80 and 443 open for my other web application.

After digging around, I found the following lines at the bottom of /Library/Server/Web/Config/apache2/httpd_server_app.conf. It basically offers additional handlers for “any” traffic on those ports. I commented them out, and apache can still run, without touching port 80 (which we want to reserve for OUR application.) Commenting ALL of them might not be the best behavior, but it’s what works for me.

#<IfDefine !WEBSERVICE_ON>
#    Include /Library/Server/Web/Config/apache2/sites/virtual_host_global.conf
#    Include /Library/Server/Web/Config/apache2/sites/0000_any_80_.conf
#    Include /Library/Server/Web/Config/apache2/sites/0000_any_443_.conf
#</IfDefine>

PSA: every installation of Google+ Hangouts keeps an “Away” instance on Google Talk/XMPP

August 9, 2013

As you may know, Google Talk worked with XMPP clients, with the good old offline/away/available presence statuses. Google’s trying to do away with offline, such that you’re always “away” on your mobile device (which I also disagree with – I should be Available on my mobile device when I’m available on my mobile device, and I should be offline when the device is unreachable.)

Similarly, this “away” instance stays away even when your device is offline. It doesn’t work like Talk did, where your device constantly disconnects and reconnects itself on a daily basis. So if you’re wiping your phone or transferring to a new phone, you might want to sign out of Hangouts first, to avoid having instances hanging around all the time.

In a fully-Google ecosystem where everyone’s using Hangouts as their client, it “won’t matter” (but it’s a bad practice for them to be doing that.) However, as Google wants to keep XMPP compatibility around, people will keep using IM clients, and consequently, keep the idea of presence.

Google+ Hangouts, from a power power user’s perspective

August 9, 2013

Somehow, messaging’s really hard to get right. There are so many wants and needs from so many varying types of users. Unfortunately Google has taken a “my way or else” approach on most of their products, and while it has worked well in some places, it has really backfired in others. Some might say that Hangouts is one of them. I’m in between – I’m not sure if Hangouts is one of them, but I can certainly see why people think so.

When Google I/O 2013 hit, everyone was wondering what big messaging changes Google would bring to the scene. Google made a huge disruption in the IM industry in 2004-2005 when it launched Gmail and Google Talk. People still used AOL Instant Messenger (popularly known as “AIM”) as their primary messenger, having to work around screennames and other limitations. Google Talk was an improvement in the sense that it worked with email addresses and a “universal” protocol, XMPP. However, it did have many feature limitations, most of whom people ended up not caring about. It also pushed the concept of being available on multiple devices at once – primarily, your phone, directly competing against the piece of shit that is SMS and MMS.

Google Talk’s main disadvantage was that it was simple IM. It didn’t support picture or group messaging, but it had the typical IM “online”/”offline” status that everyone was used to (and could accordingly configure, naturally, on their phone), and people could use IM clients of their choice, because of how close it’s tied to XMPP. However, Google couldn’t stick to XMPP forever. You really can’t push features on a product when restricting yourself to XMPP, so they finally introduced Talk’s replacement: Hangouts.

Actually, Hangouts replaced Google+ Messenger as well. I don’t really know why Google+ Messenger existed (or rather, I don’t know why it was limited to mobile, and existed separately from Talk, which confused people), but it did support photo and group messaging, and used Circles/google+ users as IDs, instead of email addresses as XMPP usernames, which had to add each other to communicate. (Actually, once Google+ started rolling, Google automatically allowed two users who mutually circled each other, to have “added” each other, though by a Google+ reference and not an email address reference.) This is the direction that they needed to go, but they didn’t get enough velocity on it. They also confused users with the multiple services. I’m all for separation of concerns, in the sense that I should be able to reach someone on all endpoints via one resource, regardless of what device they’re on, what their phone number is, if their phone breaks, etc. Such is key for ensuring easy communication, regardless of situation. This is actually a key topic of my life recently, and thus I have a lot to say about it, so I’ll write more on this in detail in a later post, since this post is for Google+ Hangouts.

My overall response from Google’s announcement of the Talk replacement at I/O was “great”. We really needed Talk to expand past XMPP (while working backwards with it), use Google+ circles (though many will disagree), support group and photo messaging, and stick an axe into Google+ Messenger. I would’ve liked for my Google+ Messenger conversations and photos to be converted to the Hangouts format, but that didn’t happen :(. Google hit all of these marks, in a sense. Thus, it was a big hit for me. Others will disagree, saying that it needed to be baked into the stock Messaging app for Android. Some even said that Hangouts should even integrate with Google Voice.

While these two things should happen, I can already imagine that the implementation would not be easy, and understand why Google left these things out of the initial release. Android is Google’s operating system with Google-y things removed – though I guess that installing Google-y things on top of Android would enable the functionality. How would the Messaging functionality even work? Would Google start associating IDs with phone numbers, and then presenting a list of send-methods, once you select a contact? Would Hangouts just “know” that your text is going to a Google Voice number, and just intercept? I really don’t want to think about these things right now – honestly, to me, it seems easier to just make sure the other person has Hangouts – and then always reach them over Hangouts.

I used Talk full-time with my closest friends, such that I could have long conversations with my IM client of choice. When Hangouts came out, they extended the functionality of their flagship messenger (Talk), while still allowing backwards-compatibility with XMPP – used by a lot of people – and still used by myself. This was great. But how did it work?

Contact presence is about the same. Available and Away states are still around, and when you’re signed on from a desktop client or a third-party application, your status is probably Available, and set to Away accordingly. On Google’s new web design, “Offline” is gone for good once you install Hangouts, so perhaps, that’s how they detect whether or not to present you the “user is not on Hangouts yet” message.  The Away state no longer exists, but instead, a green bar appears when the user is available. Unfortunately, I can’t see the green bar on my mobile client, which is probably a design decision, but IMO, a flawed one. I should be able to see that kind of information on my phone, if I can see it on my browser. Plus, many people (including myself) use Google Apps, which doesn’t have Hangouts yet, and thus, presence is still important over there. I can no longer see if my coworkers are online, since I updated my phone to Hangouts (which I use for both my personal and work [Google Apps] accounts.)

Another significant flaw is that my Mobile resource’s presence no longer updates to Available when my screen is on, even if I’m actively messaging someone.  I am available, so my presence should signify such – it doesn’t matter that I’m on my mobile device – who is Google to say that I’m as unavailable on my phone (when I’m on my phone) as when I’m off my phone?

The worst flaw is that a mobile resource’s presence continues to be Away, even after the device is powered off or disconnected. This can be confusing for others who haven’t switched to Hangouts yet, and can actually be quite devastating. In the event that you sell your phone or wipe/reinstall Android (ROM junkies, beware!), you will have a hanging “Messaging” (Hangouts) instance shown on XMPP every time you sign in, if you don’t sign out first. This deserves its own post and PSA.

The implementation of photo messaging for classic/XMPP clients is not surprising – Google recognizes those capabilities, and instead sends a link to the photo on the album of that particular Google+ Hangout. Group messaging doesn’t have this kind of signaling system though – there’s no real solution to that kind of problem.

Group messaging is done by creating a conversation ID (say, a “Hangout”) with those users, instead of defining it based solely on the user. This way, you can add users to an existing Hangout, and continue the topic properly in the same room (or vice-versa, remove a user), and also, you can have multiple Hangouts with the same set of users, which is unnecessary for most. Personally, I actually like the group MMS model, where the participant-list defines the group. If someone composes a new message with the same participant-list as an existing Hangout, it would create a new Hangout, but in group MMS, it would continue the existing thread. While it is useful to be able to have separate Hangouts, I think that it becomes more complicated for general users than it helps the specific users that need it. By the way, with this logic, shouldn’t I be able to have separate one-on-one Hangouts? If I start a new Hangout with one person, it just uses the existing Hangout with that person. I think I have seen the ability to have multiple one-on-one Hangouts with the same person, but I’m actually not sure how.

And now for flaws on a smaller scale..

Sometimes people don’t get notifications. Some users in particular, don’t get many of their notifications. I assume that this is a bug in Hangouts for Android, but I’m not really sure. The desktop client seems to work well, and the Android client has been solid at notifications for me, so far. I haven’t heard any complaints about Hangouts for iOS notifications dropping, but maybe I don’t know enough iOS users (or iOS Hangouts users…)

Whenever you send a message, it doesn’t appear in the message history instantly. It lags now (and based on latency, it seems.) It should’ve preserved the old Google Talk functionality, where the message appears in the thread as “sending”. Instead, it looks like it has to process some amount of network data before it even appears as “sending”. So there’s like two tiers of sending. Sometimes I can even queue up a series of messages and send them all, and it would be a while before they even display as “sending” on my device.

Some people are mad about the lack of voice calling. I personally don’t find it to be too much of a nuisance to start a Hangout and disable the video part, but obviously there’s a demand (and a market) for voice over data. Google could market this to be a useful feature. People could stop paying for minutes and get higher-quality calls for free… but I’ll save that point for another blog post, I guess.

The desktop client is really under-featured. It looks like someone started writing an app.. and then left it alone after they stubbed out basic functionality.

Signing in to Hangouts signs me in to all instances of Hangouts on all Chrome windows I have. This might be okay. However, it also signs me in on other browsers, too – say, I sign out at work at the end of the day, and sign in at home. Suddenly, I’m online at work again. This is not okay.

Selecting contacts is really weird. I’ll start typing a name and then I see a bunch of people who I haven’t even circled yet, before seeing my own name. I went on my  mom’s computer the other day, who only had me and my sister on Google Talk. Since she hasn’t messaged me in a while(?), I’m not even on the list. When I started typing my name, I saw a bunch of other random people on the internet. It wasn’t until I actually typed all 5 letters of my name that my name showed up.

Fuck, that was long. I probably have more, but I’ve kept this post drafted for way too long, and need to move on. If anything, I’l just append via edits.

Edit 8/26: Looks like there was a recent update in the past few days, and the message queueing is snappier now.

Full-time Google Voice, for reals now, and my history with Sprint and T-Mobile

August 1, 2013

I’ll provide some history: I got Google Voice as soon as I got an invite in June 2009. I was on a grandfathered AT&T (AT&T Blue [pre-Cingular!]) plan, when those plans came with free text message receiving. I always got texts from friends, but used various online tools to text them back. (AT&T’s was the coolest, since it actually came from my number!)

Finally I had the ability to text, and in thread-format, too. I didn’t even care that it required being next to a computer, since that was already a requirement for me to send text messages. I instantly became on Google Voice full-time.

Fast forward a few years later – in April 2012, I decided to make use of the Sprint-GoogleVoice integration (released ~March 2011), and decided to use my Sprint number on Google Voice (I preferred my original number over my GV number anyways), allowing me to receive SMS and MMS on the same (my “primary”) number, though MMS would show up on the device and SMS would show up in Google Voice (note that there is an option to deliver SMS to the device, and with Sprint integration it would appear native [no phone-number translation] as well, but I preferred that to stay in the cloud.)

I actually got out of my Sprint contract in March 2012, and used that to sign another contract to get a Sprint Galaxy Nexus. At the time, I was considering a GSM Galaxy Nexus on T-Mobile, with T-Mobile’s $30/month prepaid plan (100 minutes, unlimited text and data throttled after 5GB). Also at the time, cheap deals for the Galaxy Nexus ($400-450) were showing up, and the GNex wasn’t in the Play Store yet – nor was Jelly Bean out yet.

I chose to stick with Sprint so that I could use the GV integration, and get MMS. However, I was already used to being unable to get MMS, so I don’t know why I didn’t just port my primary number into Google Voice and get it over with. I thought it would override my Google Voice number (which I also wanted to keep), but it turns out that I can actually have both numbers on the same account. I deeply regret choosing this route, and I deeply regret sticking with Sprint, as if the Sprint network wasn’t enough, the radios in the Galaxy Nexus were awful, and 3G performed much worse than my older Sprint phones. It would’ve also been nice to go GSM, and have a spare GSM phone around.

Back on topic – so I used my Sprint number with Google Voice (and kept the Google Voice number on the same account, for $20), for most of 2012, and some of 2013. I was like “ooh, I can participate in group MMS now!”. Guess what? No one used it.

I picked up a Nexus 4 in November 2012 and got the T-Mobile prepaid plan. I was immediately hooked to HSPA+ speeds, and even the quad-core CPU. Everything was amazingly fast. and of course, I was using it with Google Voice, such that both of my phones were, basically, endpoints to the same phone number.

I “double-fisted” phones for a while (about 6 months in total – Nov 2012 to May 2013.) Sprint’s LTE buildout was slow, though all the Sprint defenders will call it “fast”. However, in March 2013, T-Mobile provided the greatest surprise of all – San Jose was a launch city for LTE! I instantly had LTE everywhere. It was EVERYWHERE and it was FAST – the GSM standard LTE, not the stupid shitty slow-to-negotiate LTE that Sprint had with my Galaxy Nexus. I continued to use both phones until May 2013, where somehow I had a slip in T-Mobile data usage, and went all the way up to 4.99 of my 5 GB for that month. You get throttled to 2G/EDGE speeds afterwards, which is slower than Sprint 3G… and can hardly send IMs or check in to venues on foursquare.

Or at least I thought it was slower than Sprint 3G. Turns out that it was around the same awful speed in most places (around 100-200 kbps – ISDN, anyone?)

I figured that if Sprint couldn’t even save my bacon when T-Mobile was stuck on 2G/EDGE speeds, there was no point of having it around. I have enjoyed Sprint LTE here and there, but it’s definitely not everywhere it needs to be – yet in San Jose (even including Santa Clara/Sunnyvale, essentially the entire South Bay), T-Mobile LTE is really indeed everywhere, and coverage is growing quickly around the Bay Area.

I paid the ETF to leave Sprint, and only wish I did it earlier.

Now my friends got a bunch of iPhones – I told them to only get top-of-the-line Android phones – they didn’t listen, and suffered accordingly. But now, they’re all aware of group texting.. BUT they don’t know that it’s MMS. I’m now on a “fuck SMS/MMS, stop using the shitty protocol which also ties you down to a phone number and a single device” crusade – Google+ Hangouts and Facebook Messenger are the two awesome messaging applications of choice right now, each with their own pros and cons – and I’ll post more on that soon.