A co-worker and I were remarking about someone who had 3TB of music. So then we got out the scientific calculator and figured:
1TB = 2 x1040 which ends up being 109951162777610 …so 3TB ends up being 3,298,534,883,32810
We decided that the average song was 4 minutes and that a 4 minute song encoded would be about a MB/min. Not exactly hyper-accurate, but close enough for IT work.
4MB is 4,194,30410 so, we divided 3TB by 4MB to come up with 786432 songs.
We then multiplied it by 4 minutes to come up with 314572810 minutes of music.
3145728 minutes divided by 60 minutes = 52428.8 hours
52428.8 hours divided by 24 hours = 2184.5333333333333333333333333333 days
And, assuming a non-leap year, 2184.5333333333333333333333333333 divided by 365 days was 5.9850228310502283105022831050228 …just shy of 6 years of continuous play without any repeats before the entire catalog had been played.
I haven’t ‘Googled’ this, but I’d bet you we aren’t the first geeks out there to wonder about this esoteric crap. The whole point of this exercise was to understand how gathering music just to “have” it is essentially a waste of time and money. Apply this idea to your DVD library and estimate – based on your age – if you’ll have enough days left in your life to see all the DVDs you have accumulated. I’d bet not.
Important information for those of you IT folks out there that have Macs in your environment.
This fix from David Shen (TechNet) solved my issue so I wanted to pass it along. My issue stemmed from my backup server running Backup Exec 2010 failing to do a proper snapshot “freeze” of my server volume because the server’s VSS (Volume Shadow Service) was having “issues”. Those issues were generating massive VSS Error 8193’s in my server’s System log. Here’s a sample of what I was seeing:
And here is David’s fix, which worked for my situation:
According to the research, the issue may be caused by an invalid entry inside the following registry sub tree.
Please open the registry editor with regedit.
Expand and local to the subtree, check if there is an entry that has a “.bak” value appended. If so, this may be cause the failure when trying to resolve the SID of the writer.
Please backup the registry key first, and then delete that entry with the extra “.bak”
Then you may reboot the problematic server to check if it the issue can be fixed.
Hope it helps.
David Shen – MSFT
I found the .bak entry and I deleted it and after the restart, it was fixed.
Issue: Some Outlook emails to Mac users result in an empty email with an attachment named winmail.dat that is a bunch of unreadable junk. Winmail.dat is a result of the email client being used (usually Outlook) sending the email as an RTF (Rich Text File). Mac systems cannot interpret messages sent in an RTF format. Since the Mac won’t read the file, it converts it to a winmail.dat file.
There are two ways to fix this issue. One is a Windows fix and the other is a Mac fix. I suggest both the Windows & the Mac users fix their side of the issue or they will continue to run into this problem again and again with other users.
Windows Users: Know your audience and adjust your email format.
Mac Users: Bombard Apple with requests that they fix this issue!
Fix (Mac): There are dozens of free programs available for the Mac which allows them to read the file. Here’s an example:
Fix (Windows): Please verify that you are sending in plain text or HTML. If you want to send “clickable” email links then HTML is the option you want.
If you’re using Outlook 2007 or 2010, go to File >Options >Compose Messages and then select the format to “HTML” or “Plain Text”
A colleague adds this bit of anti-Mac venom: “Mac users are convinced the root problem is a Microsoft problem, not a Mac problem, so they don’t bother ….to fix the issue. The Mac user simply points the problem back to the Microsoft user … The only way you can remedy the problem on [the Windows] end is not to use rich text format and only use plain text format. This is the only rudimentary format that Macs can handle.”
Symptom: Even though the admin has installed the license and received a good response from the AMOS License Authorization Wizard, you continue to get this when you launch AMOS:
The temporary period for running Amos without a license has expired. Use the License Authorization Wizard to contact SPSS for a license code.
I found that the AMOS lservrc file (C:\Program Files\IBM\SPSS\Amos\19\lservrc) didn’t match the license hash based on my original license key I’d received from them via email. This is a sample hash so you know to what it looks like:
So I opened lservrc up in notepad and pasted the correct hash, saved it…and voila!
The issue appears to be one of permissions. Even a program (the AMOS License Authorization Wizard, f’rinstance) set to run with the ‘elevated’ admin token in Win 7 cannot write into anything located in the Program Files directory. So I saved the updated lservrc file on the desktop, exited notepad.exe and just slid it into the proper folder.
Inspired by http://guardian74.wordpress.com/ while looking up a strange Adobe Acrobat Pro phenomenon (Adobe doing something wierd? …go figure!), I decided I needed a place to share my technical experiences.
Windows 7, 2008R2 and the applications that play in those OS’s are my current interest.
So welcome and I hope I assist you in getting stuff done. And thanks to Guardian for such a great blog! Do visit his/her sight.