Search This Blog

Friday, August 21, 2015

There was a problem playing this protected content. (Error Code: 3336)



Once again, the powers at be, controlling DRM software integration at Google and Hulu have decided to disregard the users of 'free' software and instead prioritize users of Windows, Apple and Google Chrome/Android devices.  QoS for the mainstream is understandable.  But there is a difference between low quality code that is not efficient or ideal, and code that simply doesn't work.

What is more annoying, is that these legal issues are masquerading as 'error codes'.  It can be determined I'm using linux via browser request headers, and IF the OS is linux, and the error is DRM related, just be honest and tell me that it's not supported on this platform, because of a recent update.

I'm sure they have been forced to enabled DRM, and waited until the last minute to do so.  And didn't have time to rework the baseline framework to support HTML5 for linux users.  I'm sure they'll do it eventually, but for now are covering their lack of planning with an error code.

This is not the first time this has happened.  We all remember the days of Linux tweaks getting Netflix to work using VMs, Wine, and god knows what else.  Finally, after years of complaining, Netflix allowed HTML5, and all is well... for now.

It seems that a new update from Hulu and Google does not permit Google Chrome running on Linux variants to support DRM protected content. This is apparently due to licensing issues, copyrights, and cost.  It would seem that Hulu blindly added the DRM requirements, without considering the repercussions (Or they just don't care).

Not surprising, small businesses with a great idea like Hulu once was, has become a draconian enterprise in which legal pressure and money woes force a quality product to become sub-par and only available to paid platforms.

After working a decade in software engineering, I have realized that what is important to those of us creating the software for the rest of society, is not relevant to the mainstream.  The same users who would tell you Linux is 'shit' because you can't be productive, are the ones who will ultimately whine and complain like a child whenever their Windows boot partition shits the bed.

As expected, the Linux base is now responding with the usual rhetoric about leaving Hulu and not giving them any more money.  There are some workarounds being expressed.  But likely I'll switch to either my Windows box, or I'll end up going w/ Firefox + HAL.

 For now, here are the most informative forums with users doing exactly what I described above.

Looking forward to the comments from those of you who 'know' whats really going on.

Thursday, August 20, 2015

Collecting Apache Storm time series data with Graphite

Naturally, Apache Storm processes data as tuples over time.  This is an ideal framework to utilize for streaming data through a 'pipe line'.  However, maintaining a record of this information is not necessarily an inherent feature of storm.  For metrics collection and analysis, I used Graphite.  Graphite is available in the Fedora EPEL and a great option for quickly collecting some metrics and generating a graph w/ overlaying analytical functions.

The easiest way to collect information is by going straight to the source.  The Nimbus server.  Using the NimbusClient class, available from the package backtype.storm.generated, you can easily review the ClusterSummary and iterate through each TopologySummary's ID to retrieve TopologyInfo and each topology's ExecutorSummary, to determine emitted and transferred tuples. Additionally, you can get information about errors, threads, and likely other details related to Apache Storm topologies I have not collected in my example code.

First, Lets look at how I will push data in to the carbon-cache daemon.
https://github.com/charlescva/graphite-common/blob/master/src/main/java/zkCliTest.java#L44

   // TCP Stream to carbon-cache.
    private void graphite(Map metrics) {
        // Current Time-Stamp for test
    long epoch = System.currentTimeMillis()/1000;
   
        try { // output  stream to the host on default port.
        Socket conn          = new Socket("cabon-cache.novalocal", 2003);
        DataOutputStream dos = new DataOutputStream(conn.getOutputStream());
        // graphite syntax map the #ngsm to output stream.
            for  (String metric : metrics.keySet() ){
                dos.writeBytes(metric +
            " " + metrics.get(metric) +
            " " + epoch + "\n");
            }
        //CLOSED CONNECTION.
            conn.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
The above code simply opens a TCP socket to the carbon-cache, writes a Map of metrics with the current timestamp, and closes the connection.  Easy.  The Take-away here, is the syntax. '[metric_path] [value] [time]' as String.

It would be redundant for me to display all of the Java code here: https://github.com/charlescva/graphite-common/blob/master/src/main/java/zkCliTest.java#L125 which essentially takes a Nimbus client connect, and builds a model of the nimbus state with your topoloy as each child node of the root context.

So, rather than bore you.  Here is a screenshot!


As you can see, the "My Topology" is a test, and clearly a static source that is linear.  But all and all, you can quickly get some good information.  Feel free to comment, as I find this article particularly interesting.

Thursday, August 6, 2015

Intel NUC won't turn on (after Ubuntu suspend)

UPDATE: THE SOLUTION TO THIS PROBLEM IS IN THE COMMENTS!  READ ON IF YOU WANT TO MAKE SURE YOUR PROBLEM REQUIRES THE SOLUTION!

Just got my NUC back up and running before posting this blog.  It doesn't surprise me much, as we have had a lot of issues with the Core i3 model at work.  I will say though, after ordering around 30 of these things, we have not had a single one brick or be dead on arrival.  Anyway, back to this issue.

I have been using a Microsoft Remote to power my NUC on and off via the Infrared sensor on the front.  I had to install a custom kernel module to get the operating system to understand the signal correctly.  As a result, I noticed if I use the remote to suspend the unit, I have to use the remote to turn it back on.  Pressing the soft switch on the unit itself does nothing.  I'm not sure if this issue is w/ the linux community drivers, intel, or both, but it is likely to be related.

The issue seems to be with the way the NUC hibernates after a software power down signal.  The BIOS/CMOS (whatever it's called these days), seems to store a bit somewhere in memory along with the system clock information related to the power state.  So the only way to get my NUC to power back on was to remove the battery from the motherboard, wait about five minutes for good measure, replace it, put the NUC back together, and boot on up.

To get to the bottom of the motherboard, you should first remove RAM and SSD (unless you really don't care about them.)  I was able to keep wifi connectors attached, but be gentle not to yank them off.  There are two black phillips head (+) screws located on the sides.  Remove these in front of a cat so he/she will look directly at where they land when you drop them on the floor.

Tricky Part: Turn the NUC upside down w/ your hand on the bottom to prevent the board from falling out and gently pry the back out w/ your finger.  Once the back is lifted up, you can shift/slide the board 1/16 of an inch (or about 1.5 cm) towards the rear to get the headphone jack and IR sensor clear of the holes in the chassis.

Battery is located to the left and removed via 2-pin connector

At this point the motherboard should be out and you can flip it around and get to the battery.

Also interesting is that on first boot, my mSATA SSD could not be detected.  Of course this initially had me worried, but after a second reboot, the OS discovered the disk just fine.

Not sure if a firmware update would have fixed this, but I've been running this NUC for more than 6 months without issue and am not going to bother w/ a firmware update at this time.

Likely related is the kernel modules used to power on/off the NUC via remote.  Here are the ones I have loaded:

charlie@NUC:~$ sudo lsmod | grep -i IRir_sony_decoder        12713  0 ir_lirc_codec          13021  0 lirc_dev               19980  1 ir_lirc_codecir_mce_kbd_decoder     13214  0 ir_sanyo_decoder       12839  0 ir_jvc_decoder         12751  0 ir_rc6_decoder         12874  0 ir_rc5_decoder         12710  0 ir_nec_decoder         12915  0 nuvoton_cir            17778  0 rc_core                28124  12 lirc_dev,nuvoton_cir,ir_lirc_codec,ir_rc5_decoder,ir_nec_decoder,ir_sony_decoder,ir_mce_kbd_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_sanyo_decoder,rc_rc6_mce

And some additional information about my model/firmware.

BIOS Information
Vendor: Intel Corp.
Version: WYLPT10H.86A.0038.2015.0410.1634
Release Date: 04/10/2015
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 6656 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6
Base Board Information
Manufacturer: Intel Corporation
Product Name: D34010WYK
Version: H14771-303
Serial Number: XXXXXXXXXXXX (redacted)
Asset Tag:
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: To be filled by O.E.M.
Chassis Handle: 0x0003
Type: Motherboard

Ubuntu 14.04.2 (amd64)
Linux Kernel 3.13.0-61