Jason’s postings and stuff

While QBP 2006 is apparently unsupported by Intuit (surprise!), it is possible to install it on Windows Vista Home, 64-bit edition. I encountered two problems, with both solutions documented somewhere on a QB support site, but only viewable via the Google page cache. To ensure their availability, I am re-posting the steps here.

During the install, there will be a failure in registering a OCX file for shipping, ZRush_ShipRush3_QB.ocx. The error will be regarding 1904.module. I simply clicked “Ignore” and install finished successfully.

Next, I ran reboot.bat which is located in the Quickbooks 2006 directory under Program Files (x86)/Intuit. It will register various files.

Finally, I changed the EXE files for QBP to run in Windows 2000 SP2 compatibility mode and started Quickbooks. It should be possible to run Help -> Update QuickBooks…

When starting Quickbooks after, the update installer will run, but still explodes on ZRush_ShipRush3_QB.ocx. I simply clicked Ignore again. The update did succeed. The error recurs during each update.

Error 1904.Module
"C:\Program Files (x86)\Common Files\Intuit\QuickBooks\ZRush_ShipRush3_QB.ocx"
failed to register.

I never had all the updates actually apply, so it remains to be seen if the above actually works.

Update, November 12th. Thus far, it doesn’t seem to have worked. I haven’t had the interest in messing with it anymore of late.

While you can reencode MP3s fairly trivially with gnump3d, no limiting is applied. Whatever you’ve reencoded will be delivered to the client as quickly as it can accept the packets being sent. If your objective is to limit the stream to the neighborhood of the reencoded MP3’s new bitrate, you will need some Apache reverse proxying magic.

First, you need mod_bw 0.7. Building is a simple process.

# /usr/bin/apxs2 -i -a -c mod_bw.c

If there’s a build fail, you may need to edit mod_bw.c accordingly:

-/* Compatibility for ARP < 1 */
-#if (APR_MAJOR_VERSION < 1)
-    #define apr_atomic_inc32 apr_atomic_inc
-    #define apr_atomic_dec32 apr_atomic_dec
-    #define apr_atomic_add32 apr_atomic_add
-    #define apr_atomic_cas32 apr_atomic_cas
-    #define apr_atomic_set32 apr_atomic_set
-#endif

On Debian GNU/Linux, activating the module is straightforward.

# a2enmod bw
# a2enmod proxy_html proxy_http rewrite

Finally, a new virtual host is created.

<VirtualHost *:80>

ServerName mp3.example.com

DocumentRoot /var/www

ErrorLog /var/log/apache2/mp3.example.com_error.log
LogLevel warn
CustomLog /var/log/apache2/mp3.example.com_access.log combined
ServerSignature On

So far, the usual stuff.

ProxyRequests Off
<Proxy *>
Order allow,deny
Allow from all
</Proxy>

We need to ensure we can reverse proxy. By default on Debian all requests are denied.

RewriteEngine On
RewriteCond %{REQUEST_URI} ^/mp3$
RewriteRule . /mp3/ [R=301,L]

Using mod_rewrite, the root URL is redirected to our proxy location.

BandWidthModule On
LargeFileLimit .mp3 250 16384

mod_bw is enabled and any file with an MP3 extension (not a MIME check) that is at least 250K is size is limited to 16KB/s, perfectly suitable for MP3s reencoded to 128Kbps.

ProxyPass /mp3/ http://10.10.1.1:8888/
<Location /mp3/>
ProxyPassReverse /
SetOutputFilter proxy-html
ProxyHTMLURLMap / /mp3/
</Location>

</VirtualHost>

Finally, the magic for the reverse proxy. All requests are proxied to our gnump3d server running on another system. The HTML sent back from GNUmp3d is filtered using the proxy-html filter to ensure all the links are rewritten. However, the m3u files will still be incorrect.

At least two options are available. The simplest way is to modify the existing gnump3d.conf so the m3u file uses the correct path, bouncing it through our reverse proxy.

use_client_host = 0
host_rewrite = mp3.edseek.com/mp3

The second option would be to filter m3u files and use an external tool, say, sed, to rewrite the URLs in the m3u file with Apache’s ext_filter module.