Updated to 10.3.9, QTSS will not start

Question

A year after updating my OS X Server 10.3 to its final version release, QTSS still refuses to start. Server Admin, either at the colo or on a remote desktop, yields no error message.
I've been content producing fast-start 3 minute .mp4 and .m4v downloads w/ FCP5 and QT7 Pro, so I haven't really missed streaming, but now I want it back for long form web videos.
With OS X Server 10.1, .html files enabled remote or in situ setup and launch of QTSS and those files can still be found on my 10.3 Library, but they now appear corrupted. For example, attempting to launch the QTSS Admin index.html file yields the error, "NO FILE EXISTS: /parse_xml.cgi" though it is right there as a peer in the folder" Dropping the start up .html folder into Safari displays two unlabelled text form boxes (presumably user name and password) with a form button with html tags, clearly a corrupted value.
So, if the mere html files in QTSS are corrupted, no wonder there's something funky going on under the covers for the QTSS GUI in Server Admin.
My question is not limited to whether anyone else has experienced this after the ultimate OS X 10.3 upgrade and what's the solution, but also whether Apple has a standalone QTSS installer which can restore the functionality I enjoyed beforehand. It would be a burden with all the websites and users I have configured to start over from scratch...especially since there's no guarantee the same fall down in QTSS's ability to start up would happen again once I upgrades to 10.3.9.
any help?

Answer 1

Success. I discovered the issue that was preventing QTSS start up.
The IP Bind tab listed a set of new Class C IP addresses that ARIN forced us to move to last year and which had been properly configured into our network and I had checked the matching address shared in our new web server config.
However /library/quicktimestreaming/config/streamingserver.xml had not exterminated the obsolete address and I pico'ed in the Terminal to replace these lines
<LIST-PREF NAME="bindipaddr" >
<VALUE>old ip</VALUE>
<VALUE>new ip</VALUE>
</LIST-PREF>
with this line, which will now overide whatever's poking in the old ip, probably one of those pesky permanently-burned Net Info DB's that can't be purged despite the reality that servers sometimes need wholesale refreshes to be re-networked:
<PREF NAME="bindipaddr" >new ip</PREF>