Warren Togami: Amazon Instant Video on Fedora

Wednesday, December 19, 2012

Amazon Instant Video on Fedora

These instructions will fix Adobe Flash Player DRM to allow use of Amazon Instant Video on Fedora 20+ or RHEL7. This works with 32bit or 64bit flash-plugin-11.2+ from Adobe in Firefox.

Update September 9th, 2014:
fakehal-0.5.14-8 below should now automatically work on Fedora 20 or RHEL7 to allow Firefox to play Amazon Instant Video.

Step 1: Install FakeHAL

Adobe Flash Player for some reason uses HAL for its DRM to function, but HAL was removed from the operating system in Fedora 16. The fakehal packages below contain a stripped down subset of hal necessary to allow this to work on newer versions of Fedora. If your firefox and flash-plugin are x86_64, then you will want the corresponding x86_64 fakehal and fakehal-libs packages.

Download fakehal: [Fedora 20+] [RHEL7] [SRPM]

Step 3: Delete the ~/.adobe and ~/.macromedia Directories

According to this page, you need to delete not just the contents within that directory, but the entire directory tree. Then kill and restart Firefox.

Step 3: Test Adobe DRM

Follow the instructions here to test it using the demo video player. Enable the "Show DRM Events" checkbox to see error messages. If you see the train video then it is working.

Troubleshooting
Sometimes it seems Amazon Instant fails to work. Repeat the steps of killing Firefox, deleting ~/.adobe and ~/.macromedia, then follow Adobe's instructions to view the train video. It seems that if the train video works then Amazon Instant will subsequently work.

64 comments:

Luke HutchisonJanuary 19, 2013 at 12:07 AM
Thanks for creating fakehal, I was thinking of creating the same thing myself, so I'm glad it has already been done.

It doesn't work as stands on my F18 machine, however. I get the following:

Jan 18 23:59:48 localhost dbus-daemon[744]: dbus[744]: [system] Successfully activated service 'org.freedesktop.PackageKit'
Jan 18 23:59:48 localhost dbus[744]: [system] Successfully activated service 'org.freedesktop.PackageKit'
Jan 19 00:02:12 localhost systemd[1]: Starting HAL Hardware Manager...
Jan 19 00:02:12 localhost hald[2068]: Runner started - allowed paths are '/usr/libexec:/usr/libexec/scripts:/usr/bin'
Jan 19 00:02:12 localhost hald[2068]: ** (process:2068): WARNING **: Failed to add monitor on '/usr/share/hal/fdi/preprobe': No such file or directory
Jan 19 00:02:12 localhost hald[2068]: ** (process:2068): WARNING **: Failed to add monitor on '/etc/hal/fdi/preprobe': No such file or directory
Jan 19 00:02:12 localhost hald[2068]: ** (process:2068): WARNING **: Failed to add monitor on '/etc/hal/fdi/information': No such file or directory
Jan 19 00:02:12 localhost hald[2068]: ** (process:2068): WARNING **: Failed to add monitor on '/etc/hal/fdi/policy': No such file or directory
Jan 19 00:02:12 localhost hald[2068]: 00:02:12.235 [E] create_cache.c:551: Cannot scan '/usr/share/hal/fdi/preprobe': No such file or directory
Jan 19 00:02:12 localhost hald[2068]: 00:02:12.235 [E] create_cache.c:709: Error generating fdi cache
Jan 19 00:02:12 localhost hald[2068]: Usage: udevadm info OPTIONS
Jan 19 00:02:12 localhost hald[2068]: --query= query device information:
Jan 19 00:02:12 localhost hald[2068]: name name of device node
Jan 19 00:02:12 localhost hald[2068]: symlink pointing to node
Jan 19 00:02:12 localhost hald[2068]: path sys device path
Jan 19 00:02:12 localhost hald[2068]: property the device properties
Jan 19 00:02:12 localhost hald[2068]: all all values
Jan 19 00:02:12 localhost hald[2068]: --path= sys device path used for query or attribute walk
Jan 19 00:02:12 localhost hald[2068]: --name= node or symlink name used for query or attribute walk
Jan 19 00:02:12 localhost hald[2068]: --root prepend dev directory to path names
Jan 19 00:02:12 localhost hald[2068]: --attribute-walk print all key matches while walking along the chain
Jan 19 00:02:12 localhost hald[2068]: of parent devices
Jan 19 00:02:12 localhost hald[2068]: --device-id-of-file= print major:minor of device containing this file
Jan 19 00:02:12 localhost hald[2068]: --export export key/value pairs
Jan 19 00:02:12 localhost hald[2068]: --export-prefix export the key name with a prefix
Jan 19 00:02:12 localhost hald[2068]: --export-db export the content of the udev database
Jan 19 00:02:12 localhost hald[2068]: --cleanup-db cleanup the udev database
Jan 19 00:02:12 localhost hald[2068]: --help
Jan 19 00:02:12 localhost hald[2068]: org.freedesktop.Hal.Device.Volume.UnknownFailure
Jan 19 00:02:12 localhost hald[2068]: Cannot open /media/.hal-mtab
Jan 19 00:02:12 localhost hald[2068]: in hal-storage-cleanup-all-mountpoints
Jan 19 00:03:42 localhost systemd[1]: haldaemon.service operation timed out. Terminating.
Jan 19 00:03:42 localhost systemd[1]: Failed to start HAL Hardware Manager.
Jan 19 00:03:42 localhost systemd[1]: Unit haldaemon.service entered failed state
ReplyDelete
Replies
AnonymousJanuary 23, 2013 at 9:06 AM
Hi - thanks for your work. However, in FC18 I get the same error as Luke. It doesn't matter if I start it manually or at boot. However I found that if I start it without daemonizing it, it works. Sort of. Flash plays for about 30 sec and then freezes. All recent amazon HD and std shows do this. If I only install libhal, flash doesn't play at all (I get "Unable to update player" message). I don't think I had any of these issues in FC17, I might just downgrade.
ReplyDelete
Replies
MrErrFebruary 9, 2013 at 9:10 AM
After followig your instructions, drm protected movies on amazon.com would start to play but only for 25 seconds. Is there something i am doing wrong? I am using F18.

ReplyDelete
Replies
dietyyliFebruary 11, 2013 at 1:20 AM
Thank you! for this. I've been googling few days why some videos wont play. Now I can watch Criminal minds on ruutu.fi :)
ReplyDelete
Replies
DebFebruary 17, 2013 at 8:15 AM
Thanks for your work on fakehal.
Followed your instructions on a 3.7.7-201.fc18.i686 machine- did Step 2 even as selinux=0 was issued at boot option.
Ending up with the 3322 error code in the Adode drm test page- no train video.

ReplyDelete
Replies
UnknownMarch 10, 2013 at 6:36 PM
Same problem: works for about 25 seconds then freezes.
ReplyDelete
Replies
dietyyliMarch 11, 2013 at 9:23 AM
I'm still on Fedora 17. So is everyone who has problems using Fedora 18?
ReplyDelete
Replies
UnknownMarch 11, 2013 at 4:03 PM
Here are all files and dirs under paths referenced in the messages:

[04:01 PM root ~/]$ whoami
root
[04:02 PM root ~/]$ find /usr/share/hal /etc/hal /var/cache/hald

/usr/share/hal
/usr/share/hal/fdi
/usr/share/hal/fdi/policy
/usr/share/hal/fdi/policy/10osvendor
/usr/share/hal/fdi/policy/10osvendor/20-ntfs-config-write-policy.fdi
/usr/share/hal/fdi/information
/usr/share/hal/fdi/information/20thirdparty
find: `/etc/hal': No such file or directory
/var/cache/hald
ReplyDelete
Replies
UnknownMarch 11, 2013 at 4:06 PM
Related software versions:

[04:05 PM root ~/]$ sudo yum list | grep -e ^firefox -e flash-plugin
firefox.x86_64 19.0-1.fc18 @updates
flash-plugin.x86_64 11.2.202.273-release @adobe-linux-x86_64
[04:05 PM root ~/]$ cat /etc/fedora-release
Fedora release 18 (Spherical Cow)
[04:05 PM root ~/]$ sudo yum update
Loaded plugins: langpacks, presto, refresh-packagekit
No Packages marked for Update
ReplyDelete
Replies
wtogamiMarch 11, 2013 at 10:10 PM
Sorry about that. I have no idea why it fails for some people but most have no trouble. I don't have time to look into this. Sorry.
ReplyDelete
Replies
Luke HutchisonMarch 11, 2013 at 10:50 PM
Hi Warren -- I did follow your instructions, and yet still had the issue. I'd be happy to set up an account on my machine if you have a chance to connect remotely and take a look at the problem. My gmail acct name is luke.hutch if you want to set this up. Thanks for your help!
ReplyDelete
Replies
UnknownMarch 11, 2013 at 11:36 PM
I did some more research and it seems that systemd allows service to start the first time they're accessed (using dbus). This is probably why Warren suggested that haldaemon should not be manually started. However, it appears it is needed, because when I mask the haldaemon.service to completely disable it (ln -s /dev/null /etc/systemd/system/haldaemon.service; systemctl daemon-reload), and I try the Adobe test again, this time it gets farther (past the loading dialogs) but it still fails and /var/log/messages shows that it is still trying to load haldaemon (and of course it doesn't load because it's masked).

So I think the problem is the fact that haldaemon is not starting. Warren, it will be very interesting to know what messages you get when your haldaemon starts (do a search for org.freedesktop.Hal). I'm guessing you don't see the same errors we do, and this will probably be a key aspect to why it's not working for us (then there's a question of why fakehal behaves differently).
ReplyDelete
Replies
Luke HutchisonMarch 12, 2013 at 12:08 AM
I'm really curious to know what parts of Hal that Adobe DRM depends upon (i.e. what parts are not stripped out in fakehal?), and why haldaemon doesn't need to start...
ReplyDelete
Replies
AnonymousMarch 12, 2013 at 5:58 PM
This comment has been removed by the author.
ReplyDelete
Replies
UnknownMarch 12, 2013 at 6:01 PM
Warren, I was able to reproduce your issue when installing a vanilla Fedora 18 in a virtual machine and hitting the same issue even after the three sudo commands above. I must have done something else on my working machine, so I'm trying to retrace my steps. At least we know it's possible :)
ReplyDelete
Replies
UnknownMarch 12, 2013 at 6:28 PM
If I run strace, the hang is primarily asking for a password, which I don't see on the working system:

[pid 2116] 18:05:50 stat("/run/systemd/ask-password-block", {st_mode=S_IFDIR|0700, st_size=60, ...}) = 0
[pid 2116] 18:05:50 mknod("/run/systemd/ask-password-block/136:0", S_IFIFO|0600) = -1 EEXIST (File exists)
[pid 2116] 18:05:50 open("/run/systemd/ask-password-block/136:0", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_CLOEXEC) = 3
[pid 2116] 18:05:50 stat("/run/systemd", {st_mode=S_IFDIR|0755, st_size=300, ...}) = 0
[pid 2116] 18:05:50 gettid() = 2116
[pid 2116] 18:05:50 open("/proc/self/task/2116/attr/current", O_RDONLY) = 4
[pid 2116] 18:05:50 read(4, "unconfined_u:system_r:unconfined"..., 4095) = 50
[pid 2116] 18:05:50 close(4) = 0
[pid 2116] 18:05:50 mkdir("/run/systemd/ask-password", 0755) = -1 EEXIST (File exists)
[pid 2116] 18:05:50 stat("/run/systemd/ask-password", {st_mode=S_IFDIR|0755, st_size=40, ...}) = 0
[pid 2116] 18:05:50 inotify_init1(IN_CLOEXEC) = 4
[pid 2116] 18:05:50 inotify_add_watch(4, "/run/systemd/ask-password", IN_CLOSE_WRITE|IN_MOVED_TO) = 1
[pid 2116] 18:05:50 rt_sigprocmask(SIG_SETMASK, [INT TERM], NULL, 8) = 0
[pid 2116] 18:05:50 signalfd4(-1, [INT TERM], 8, O_NONBLOCK|O_CLOEXEC) = 5
[pid 2116] 18:05:50 openat(AT_FDCWD, "/run/systemd/ask-password", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 6
[pid 2116] 18:05:50 getdents(6, /* 2 entries */, 32768) = 48
[pid 2116] 18:05:50 getdents(6, /* 0 entries */, 32768) = 0
[pid 2116] 18:05:50 close(6) = 0
[pid 2116] 18:05:50 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}], 2, 4294967295

On the working system, the only reference I see is this:

[pid 5564] 18:05:25 execve("/usr/bin/systemd-tty-ask-password-agent", ["/usr/bin/systemd-tty-ask-passwor"..., "--watch"], [/* 21 vars */]
[pid 5563] 18:05:25 <... recvmsg resumed> {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\0017\0\0\0\4\0\0\0\17\0\0\0\5\1u\0\2\0\0\0\10\1g\0\1o\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 87
ReplyDelete
Replies
UnknownMarch 12, 2013 at 6:55 PM
I think the password stuff is a red herring. If I try to manually start with sudo systemctl --no-ask-password haldaemon.service, it also hangs, here's the end of the strace:

18:43:38 recvmsg(3, {msg_name(0)=NULL, msg_iov(1)=[{"l\2\1\1\10\0\0\0\4\0\0\0\17\0\0\0\5\1u\0\3\0\0\0\10\1g\0\1v\0\0"..., 2048}], msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 40
18:43:38 recvmsg(3, 0x7fff2cc2f1b0, MSG_CMSG_CLOEXEC) = -1 EAGAIN (Resource temporarily unavailable)
18:43:38 poll([{fd=3, events=POLLIN}], 1, 4294967295

Strace comparison here:

http://pastebin.com/Gn4yLrdy
ReplyDelete
Replies
UnknownMarch 12, 2013 at 10:35 PM
Okay I learned how to ask hald to output verbose debug:

Edit /lib/systemd/system/haldaemon.service
Add --verbose=yes to ExecStart

vi /etc/rsyslog.conf
# Update the line
*.info;mail.none;authpriv.none;cron.none;hald.debug /var/log/messages
# Then
sudo systemctl restart rsyslog

Then in comparing the two outputs it becomes clear that hald is not completing startup in the bad case because hotplug events are not created and processed. When hald/linux/hotplug.c : hotplug_event_process_queue is called, the hotplug_event_queue is NULL and so it just returns.
ReplyDelete
Replies
UnknownMarch 12, 2013 at 10:50 PM
Okay, got it to work! Here's the patch. I still have no idea why my virtual machine has a different behavior in the hotplug than my host machine.

$ cat ../../SOURCES/hal-hack.patch
diff -uNrp hal-0.5.14.orig/hald/linux/hotplug.c hal-0.5.14.new/hald/linux/hotplug.c
--- hal-0.5.14.orig/hald/linux/hotplug.c 2013-03-12 19:53:45.445429300 -0700
+++ hal-0.5.14.new/hald/linux/hotplug.c 2013-03-12 22:46:13.374644193 -0700
@@ -460,8 +460,11 @@ hotplug_event_process_queue (void)
GList *lp, *lp2;
static gboolean processing = FALSE;

- if (G_UNLIKELY (hotplug_event_queue == NULL))
+ if (G_UNLIKELY (hotplug_event_queue == NULL)) {
+ HAL_ERROR (("hotplug_event_queue NULL, trying early finish"));
+ hotplug_queue_now_empty();
return;
+ }

if (processing)
return;
ReplyDelete
Replies
UnknownMarch 12, 2013 at 10:51 PM
I should note that this is probably not the best solution, and I really don't know what the impact to HAL is. The correct solution would be to understand why the hotplug events are not being queued, but this patch seems to work okay enough.
ReplyDelete
Replies
Luke HutchisonMarch 13, 2013 at 2:31 AM
(Part 2/2)

[E] coldplug.c:176: /sbin/udevadm returned 512
[E] coldplug.c:583: Unable to get sysfs to dev map
[I] osspec.c:496: Synthesizing powermgmt events...
[E] acpi.c:762: Couldn't open /proc/acpi/battery: Error opening directory '/proc/acpi/battery': No such file or directory
[E] acpi.c:762: Couldn't open /proc/acpi/processor: Error opening directory '/proc/acpi/processor': No such file or directory
[E] acpi.c:762: Couldn't open /proc/acpi/fan: Error opening directory '/proc/acpi/fan': No such file or directory
[E] acpi.c:762: Couldn't open /proc/acpi/ac_adapter: Error opening directory '/proc/acpi/ac_adapter': No such file or directory
[E] acpi.c:762: Couldn't open /proc/acpi/button/lid: Error opening directory '/proc/acpi/button/lid': No such file or directory
[E] acpi.c:762: Couldn't open /proc/acpi/button/power: Error opening directory '/proc/acpi/button/power': No such file or directory
[E] acpi.c:762: Couldn't open /proc/acpi/button/sleep: Error opening directory '/proc/acpi/button/sleep': No such file or directory
[I] acpi.c:841: Processing sonypi display
[I] osspec.c:498: ACPI capabilities found
[I] osspec.c:506: Done synthesizing events
[I] osspec.c:461: Add callouts completed udi=/org/freedesktop/Hal/devices/computer
[I] hald.c:108: Added device to GDL; udi=/org/freedesktop/Hal/devices/computer

[...hangs here for 90 seconds...]

systemd: haldaemon.service operation timed out. Terminating.
[I] hald.c:372: Caught SIGTERM, initiating shutdown
systemd: Failed to start HAL Hardware Manager.
systemd: Unit haldaemon.service entered failed state
ReplyDelete
Replies
AnonymousMarch 19, 2013 at 8:12 PM
The patch works for me too! Thank you, thank you, thank you!!! Now I can watch Doctor Who, yay! Funny thing though, hald is not even running.
ReplyDelete
Replies
Luke HutchisonMarch 19, 2013 at 8:24 PM
I guess we still never figured out the difference between systems that work with fakehal and those that don't? Is it possible to instrument fakehal with some debug output so we can see exactly what the difference is between working and non-working systems?
ReplyDelete
Replies
AnonymousMarch 22, 2013 at 9:20 PM
MrErr how did you apply the patch? I was new to this and it took me some time to figure it out. Run strings /usr/sbin/hald | grep "hotplug_event_queue NULL, trying early finish" to be sure the patch worked correctly. Did you modify the fakehal.spec?
ReplyDelete
Replies
MrErrMarch 23, 2013 at 8:32 AM
OK looks i did not apply the patch properly. All i did was include the patch file in the SOURCES directory. I did not change the fakehal.spec file. I tried making changes to fakehal.spec file and the rpmuild it, but i get the following errors.

Patch #102 (hal-exclude-addons.patch):
+ /usr/bin/patch -p1 -b --suffix .exclude-addons --fuzz=0
+ /usr/bin/cat /root/rpmbuild/SOURCES/hal-exclude-addons.patch
patching file hald/linux/addons/Makefile.am
+ echo 'Patch #103 (hal-hack.patch):'
Patch #103 (hal-hack.patch):
+ /usr/bin/patch -p1 -b --suffix .hal-hack.patch --fuzz=0
+ /usr/bin/cat /root/rpmbuild/SOURCES/hal-hack.patch
patching file hald/linux/hotplug.c
/usr/bin/patch: **** malformed patch at line 5: GList *lp, *lp2;

error: Bad exit status from /var/tmp/rpm-tmp.uhtIcH (%prep)

RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.uhtIcH (%prep)
(10:24 root@Salem SPECS) >

Any ideas what to do different?
ReplyDelete
Replies
UnknownMay 16, 2013 at 9:30 AM
The instructions from Unknown worked for me on Fedora 3.8.12-100.fc17.i686.PAE. The patched rpms and instructions were spot on. Thanks to Warren and Unknown for this.
ReplyDelete
Replies
Allison S.July 12, 2013 at 9:03 PM
worked on my fedora 18 also. great comment from Unknown. One line missing is the "sudo semodule -i adobedrm.pp" but I think I remember seeing that back at the top of the post anyways...
ReplyDelete
Replies
Nick HuJuly 18, 2013 at 1:40 PM
Hi, is there any way one of you could prove a compiled rpm with that patch applied? I'm repackaging for Arch Linux, and I don't know how .spec builds work.
ReplyDelete
Replies
Allison S.July 26, 2013 at 10:55 PM
here are my built rpms with the fakehal patch.

https://www.dropbox.com/sh/afbrtsi9cwc2ahj/OHVai3uelV
ReplyDelete
Replies
Luke HutchisonJuly 26, 2013 at 11:42 PM
Progress! Thanks Allison, Adobe DRM was hanging partway through initializing, but now with your fakehal RPMs, it fully initializes, but I get an error:

Starts to get video metadata at Fri Jul 26 23:35:31 GMT-0700 2013
DRMContentData received on Fri Jul 26 23:35:31 GMT-0700 2013
authenticationMethod = anonymous
ServerURL = http://drmtest2.adobe.com:8080
license ID = 43345AEF-52FF-3F20-90FF-ABDC98A2E3E4

DRMErrorEvent dispatched by DRMManger received on Fri Jul 26 23:35:31 GMT-0700 2013
event type = drmError
Error Code = 3322 [DeviceBindingFailed]
Sub Error Code = 1107296263
Error Details =
drmUpdateNeeded = false
systemUpdateNeeded = false

I followed the steps in Unknown's comment, until the patching steps, then just used Allison's RPMs, and additionally added the "sudo semodule -i adobedrm.pp" step. Did I miss anything?

In particular, SELinux is disabled on my machine, do I need to be running in Permissive mode or something for fakehal to work, given the SELinux commands?

(BTW I have another solution for several media sources at least. It's a cop-out, but I just bought a ChromeCast device to plug into a spare HDMI port on my monitor... :) )
ReplyDelete
Replies
Luke HutchisonJuly 26, 2013 at 11:50 PM
Spoke too soon, after another "rm -rf ~/.adobe/Flash_Player/", it's working! My setup seemed to be the most stubborn and resistant to being fixed in earlier discussions, so this is amazing. Thank you everybody for the tips and solutions!

Allison, do your RPM packages include all the necessary selinux commands in the setup scripts, so that all the user has to do is issue "rm -rf ~/.adobe/Flash_Player/"?
ReplyDelete
Replies
Luke HutchisonJuly 27, 2013 at 3:00 AM
(As far as I know, the only difference with Allison's RPMs is that she applied all the patches in "Unknown"'s comments, and rolled new RPMs?)
ReplyDelete
Replies
BradleySeptember 16, 2013 at 2:48 AM
I got this to work (on a local Australian catchup service) - had to start haldaemon then when it failed looked at the error message and created the directories it was looking for (owned by haldaemon:haldaemon. Also chmod'd them a+rx, although that may not have been needed)

/usr/share/hal/{information,policy,preprobe} were needed, (This was a new laptop that started with F19, so never had HAL installed)
ReplyDelete
Replies
Über MommaJanuary 17, 2014 at 6:17 PM
In addition to the steps above, I had to remove the ~./macromedia directory in Fedora 17 32-bit to get protected content to play.
ReplyDelete
Replies
Bill McGonigleJanuary 17, 2015 at 9:18 PM
Thanks - I built and installed fakehal (f20), restarted Firefox (f35) and video played right away. No need to create nor delete any directories.
ReplyDelete
Replies

Add comment