Windows 7 and Suddenly Changed to a Lower Sound Volume (Realtek)

After plugging in an unrelated USB device my built-in realtek sound card suddenly decided to go into low volume mode, where the output level was several levels below what it used to be. The mixer in Windows 7 shows the full volume for the application playing (Spotify in this case), but the volume output on the speakers was very low.

Go into the “Realtek HD Audio Manager” on the control panel, select “Speakers” and then “Default Format“. This had suddenly been set to 24 bit, switching it back to 16-bit 192KHz made the volume normal again. Unless you require another format on the digital output, 16-bit 192KHz or 48KHz should be more than enough (I’m guessing this adjust the quality of the internal DAC on the sound card, so go with 192KHz).

Update: turns out this still happens, but changing it to something else, then back to the previous value solves the issue. No idea why.

jQuery, Radio-buttons and attr(‘checked’)

To make this a bit more searcable on the magic intarwebs:

jQuery 1.6.x changed the behaviour of attr(‘checked’), as it is no longer used to manipulate the state of radio buttons (or other elements using the checked element). This is considered a property, not an attribute (the difference is subtle), so instead of:

    $("#element").attr('checked', 'checked'); // or
    $("#element").attr('checked', true);

The correct ™ way of doing this is:

    $("#element").prop('checked', true);

Sorting Strings as Numeric Values in Python3

A small hack to do natural, numeric sort of string values in Python is to use the int function when calling sorted (here, applied to a dictionary get it sorted by its keys):

    for position in sorted(positions.keys(), key=int):

This will call int() for each value in the list to sorted, and use the numeric value instead of the asciivalue (if the keys / elements are strings instead of numbers).

SQLAlchemy, MySQL and UTF-8

While SQLAlchemy uses UTF-8 by default, the charset used when communicating with MySQL will affect the encoding of the returned data. To be sure that everything is handled properly as UTF-8 (which you might use SET NAMES 'utf8' in the console (don’t do that here..)), add ?charset=utf8 to your connection url:


Thanks to RustyFluff at StackOverflow.

Debugging Python’s Memory Usage with Dowser

As I mentioned in my previous post, I had to hunt down a leak (which was intentional considering the functionality) somewhere in a batch import task in my Pyramid app. I’ve never played around with any memory profilers in python before, so this was a proper opportunity to see what the different options were. StackOverflow to the rescue as usual, with a handful of suggestions for Python memory profilers.

After trying a few, I ended up with Dowser. Dowser fit my use case neatly, as my application was a long running process, was console based (since it uses cherrypy to launch its own HTTP Server, it was a good thing that it didn’t conflict with any existing serv er) and I could pause it at a proper location before it consumed too much memory (a time.sleep(largevaluehere) worked nicely, thank you).

Installing Dowser was relatively pain free (a few of the other options I tried either needed custom patches, or required the process to run all the way through before giving me the information I needed).

I needed to get a few dependencies installed:

pip install pil

.. which Dowser uses to generate sparkline diagrams, and cherrypy itself:

easy_install cherrypy

.. and last, checking out the latest version of Dowser from SVN:

svn co dowser

I modified the example from the Stack Overflow question above a bit, and ended up with a small helper function in the application’s helper library:

def launch_memory_usage_server(port = 8080):
    import cherrypy
    import dowser

        'environment': 'embedded',
        'server.socket_port': port

Then doing launch_memory_usage_server() somewhere early in my code launched the HTTP interface (http://localhost:8080/) to see memory usage while the import process was running. This helped me narrow down where the issue showed up (as we were leaking MySQLdb cursors at an alarming rate), and digging deeper into the structure hinted to the underlying cause (the debug toolbar was active for a console script).

Leaking Memory / Cursors with SQLAlchemy and Pyramid

After spending the better part of the day trying to find out why the fsck my console script for importing a dataset through sqlalchemy needed just above 7GBs of memory before barfing out and swapping like a madman, I finally found the solution.

Make sure that Pyramid’s debug toolbar is disabled. It’ll keep an reference around to all queries ran through SQLAlchemy (for .. well, debugging purposes, obviously). This causes an issue if you’re running a very large number of queries, and you’re not going to use the debug toolbar from the console anyway, so .. get rid of it.

I created a second version of my development.ini, a development_console.ini that doesn’t load the debug toolbar, and finally stuff Just Worked ™ again.

Console / shell script runs twice when using pyramid.paster and bootstrapping

You’ve just created your new, exceptional shell script to maintain your pyramid application from the console, when you discover that everything runs twice. Usually not a very good idea, but .. why?

The issue is probably that you’re running pyramid with the scan option, which requires all modules in the path of your pyramid application to be imported. This will also import your console script, and if you haven’t placed everything into a function and added a check to see if the script has been invoked directly, you’re fscked!

The easy way out is to put your code into a function:

def main():
    from pyramid.paster import bootstrap
    env = bootstrap('../../development.ini')


if __name__ == '__main__':  

The last if-test check if this is the main file that has been invoked, and if true, calls main and launches your script. This should hopefully solve the issue!

Pyramid: pkg_resources.DistributionNotFound: <projectname>

When trying to start the built-in WSGI server in Pyramid after starting a new project, pserve refused to do anything useful with my project. Turns out I had forgot to run in my projects virtual environment to set up all the dependencies:

From my projects folder:

    ../bin/python develop

.. of course, you’ll remember this if you read the README.txt that the pyramid setup creates for you in your project directory.

“Klareringsforholdet mellom arbeidsstasjonen og primærdomenet ble ødelagt.” or “The trust relationship between this workstation and the primary domain failed.”

I added the Norwegian translation of the error message to the title as well to help any Norwegians trying to find a solution to this Windows AD issue. The root cause is that the kerberos secret on the client no longer (for some reason) matches the secret stored in the AD forest. The usual fix is to make the client rejoin the domain, however, there’s a better solution.

First you’ll need Administrator access to the client. If you’re unable to log in as an Administrator (because the computer was locked by a domain user account before the secret got borked), reboot the client without any network access. This will allow the user to log in with the cached credentials, as the client is unable to discover that its secret differs from the secret stored in the domain.

You’ll need to download the Remote Server Administration Tools for Windows 7, and install it on the client. After installing, go to Programs and features in the Control Panel, select enable / disable windows features on the left pane, and navigate through:

Remote Server Administration Tools > Role Administration Tools > AD DS and AD LDS Tools

.. and find the choice that includes “console tools” (I don’t remember the exact name).

Start cmd as an administrator (right click, select run as administrator under Accessories), and use netdom.exe to sort the issue out properly.

netdom resetpwd /s:<server.domain.local> /ud:DOMAIN\user /pd:*

The user referenced by DOMAIN\user needs to have access to add / edit clients in the domain.

svn: OPTIONS of ‘‘: SSL handshake failed: SSL error: A TLS warning alert has been received. ()

If your svn client suddenly starts complaining about something similar to

svn: OPTIONS of '...': SSL handshake failed: SSL error: A TLS warning alert has been received. (...)

The reason might be that the host in the URL ( => doesn’t match the ServerName setting in the SSL host for your web server. You might not have configured this, so for Apache add:


.. and restart the server. It might just work again!