Month: June 2013

Does this look familiar to you?

Welcome to my world. Not sure at this point how I got on this list, how to get off it, or even where this list is. But perhaps my findings will help you resolve the same issue for your domain. At this point, my suspicion is that it's due to and odd report from Google Safe Browsing that "Yes, this site has hosted malicious software over the past 90 days. It infected 0 domain(s), including .". It would be great if I knew what the malware/badware is/was so that I could remove it. Even more odd is that my supposed infection infected no other sites.

Oh well. More to come...

Update: I've emailed "Certmaster" and they responded letting me know that they see my domain on Google's Safe Browsing blacklist results. Oddly enough, here are the results:

I see the report that "Yes, this site has hosted malicious software over the past 90 days. It infected 0 domain(s), including ." What's odd about this is that when I check my Google Webmaster tools, the site reports that "Google has not detected any malware on this site.", and it seems I'm not the only one. Not sure if I'm just bitten by a previously unseen issue that I've since cleaned up with WordPress updates or what.

Given the date that is shown above (2013-05-04), I'd guess that the "past 90 days" implies I'll have to wait until 2013-08-04 for this status to clear. I guess that's the penalty I pay for lack of diligence in monitoring the updates and health of my server up until then. If you're saying to yourself "I can't wait that long!", you do have the option of paying StartSSL the fee required for them to manually intervene in what would otherwise be an automated process. I choose to wait it out: I don't really need SSL for anything practical. For my purposes, it's just for the sake of writing articles like this: research and writing howto's based upon my experiences. So I'll be waiting out the presumably prerequisite "90 days" for the sake of research.

See you on 8/4 with an update!

Update 8/15: As the saying goes: "Time heals all wounds". I'm now off the naughty list for Google. Now to (re-)try obtaining a cert from StartSSL...

Today I came in to work to find that the video output for my Dell Latitude e6520 laptop's NVidia head was displaying in black and white. At first I thought that the problem was a driver bug, something wrong with the video memory, or a faulty display. But eventually I found out that, somehow (without any user interaction with the applicable setting), the "Digital Vibrance" setting was set to 0%, when it should be 50%. Below you'll see a simple annotated screenshot showing where you can quickly fix this.

Good luck!

This quick post is as much for your benefit as for the benefit of my memory...

To stream RTMP with VLC, you'll need rtmpdump, which you can get here: http://rtmpdump.mplayerhq.hu/. I used rtmpdump-2.4-git-010913-windows.zip, though you may be able to use the latest version. I also had VLC 2.0.6 32-bit installed. Once installed, you can run the following from a cmd window:

rtmpdump.exe -r "rtmp://your.domain.com:1935/yoururl/here" -v -o - | vlc.exe -

This worked nicely for me. YMMV. Good luck!

If you found this helpful, maybe you'd like to send a thank you from my wishlist?

Just a quick post about a problem I helped a buddy of mine resolve. He was setting up a Helix media streaming server, and was trying to capture the stream data to a file with the following command:

ffmpeg -i "rtmp://10.132.245.4:1935/flash/meet.flv" out.flv

The result was this error in the output:

[rtmp @ 0x28e1dc0] Server error: Not Found

Oddly enough, the connection information shown on the Helix console showed that a strange URL was being requested. Upon further investigation with Wireshark, I found that this was the request being made.

play('\360xw0meet')

Note that "\360" is a hex character. For some odd reason, it would appear that ffmpeg improperly handles short URLs, inserting a string of "\360xw0". If you pad the URL with the current directory "./", then the request succeeds:

ffmpeg -i "rtmp://10.132.245.4:1935/flash/./././././meet.flv" out.flv

This results in a request of

play('././././meet')

Which worked fine in our environment.

For future reference, I was running this ffmpeg version (on CentOS 6.4 x86_64):

ffmpeg version N-53616-g7a2edcf Copyright (c) 2000-2013 the FFmpeg developers
built on May 29 2013 00:19:54 with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-3)

So if you're running into the "Server error: Not Found" error on a known good URL, try padding the path of the stream with "./" and see if that fixes it for you. I'm guessing this is an ffmpeg bug, but don't really have the access to a streaming server to troubleshoot and submit a bug report. From the time that I did have, it appears that it's related to the .flv extension in the rtmp URL. If you drop the extension, the URL can be of any size.