Roku DLNA Media Playback Gets Stuck at 13%

Earlier in the year, I wrote about configuring Kodi to act as a DLNA Media Source for a Roku Streaming Stick, using Roku Media Player to access and play a local media library.

This setup worked quite well for me until recently, when I suddenly found that media would no longer play.

I could browse the media library but attempting to play anything resulted in a loading wheel which got stuck at 13% before eventually showing a timeout message.

Although the cause, in my case, was specific to my network, it seemed worth writing about because 13% seems to be quite a common failure point and, as we'll see, is actually quite misleading.

Background

It's fairly easy to run into this issue: after launching Roku Media Player, choose a DLNA source, browse to some media and hit play.

If you're unlucky, after a few moments you'll be greeted with

Eventually it'll stop trying and tell you that video playback timed out.

Cause

It's the error message that tells us the true cause: Roku wasn't able to fetch the media file at all.

Although it might appear that the file was 13% loaded, this isn't the case. The media player was 13% of the way through the process of starting playback:

• It's identified the source URLs in the DLNA server's response
• (if necessary) it's resolved the hostname
• It's attempted to connect and fetch the media player

13% is a common failure point (also here and here) because it's the point at which the Roku first tries to retrieve the media itself.

So, if you're getting stuck at 13% you need to look a whether the Roku can actually fetch the media from the media source at all.

Media Source

It's quite possible that, like me, you've assumed the media source must be OK: after all, you navigated a bunch of menus that were fetched using DLNA, so there must be connectivity.

However, that's not necessarily the case.

As well as a URL for DLNA playback, Kodi's DLNA responses include the original source URL for each item:

<item id="videodb://movies/genres/3/4?genreid=3" parentID="videodb://movies/genres/3/" restricted="1">
    <dc:title>Big Buck Bunny</dc:title>
    <dc:date>2008-10-08</dc:date>
    <upnp:genre>Action</upnp:genre>
    <upnp:genre>Comedy</upnp:genre>
    <upnp:albumArtURI dlna:profileID="JPEG_TN">
        http://192.168.3.91:1139/%25/b694b533380ca2edf55b32452642b166/ptURGAFktibhk7DEAbMazlmNqWa.jpg
    </upnp:albumArtURI>
    <dc:description>Bloody Squirrels</dc:description>
    <upnp:longDescription>
        A bunny is trying to enjoy his day only for a bunch of squirrels to go out of their way to ruin it. 
        How will Big Buck deal with his nut-munching foes?
    </upnp:longDescription>
    <upnp:rating>Rated PG</upnp:rating>

    <!-- Playback URLs here -->
    <res duration="00:10:00.000" protocolInfo="http-get:*:video/x-msvideo:DLNA.ORG_PN=AVI;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000">
        http://192.168.3.91:1139/%25/fe7fd915868f83a6a3106629627e7d52/big_buck.avi
    </res>
    <res duration="00:10:00.000" protocolInfo="xbmc-get:*:video/x-msvideo:DLNA.ORG_PN=AVI;DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000">
        http://nas.home:80/Action/big_buck.avi
    </res>
    <!-- Playback URLs end -->

    <res protocolInfo="xbmc.org:*:fanart:*">http://192.168.3.91:1139/%25/c858a22a20597229eece5a6cdc6966ba/swyPgOP2lffHfMjeZKNnNFR9P88.jpg</res>
    <res protocolInfo="xbmc.org:*:poster:*">http://192.168.3.91:1139/%25/b694b533380ca2edf55b32452642b166/ptURGAFktibhk7DEAbMazlmNqWa.jpg</res>
    <upnp:class>object.item.videoItem.movie</upnp:class>
    </item>

In the middle of this block we can see two <res> items detailing playback URLs: one for playback via Kodi's DLNA interface and the other direct from the fileserver.

Roku Media Player seems to consistently choose whichever is listed last - in this case the original URL - and, for whatever reason, doesn't appear to be capable of failing over between the two.

My Issue

In my case, the Roku was attempting to connect but not getting anything back

This proved to be because of a years old and defunct firewall rule

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 600M 3365G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  127  7620 DROP       all  --  *      *       192.168.3.168/29     0.0.0.0/0            /* Disallow Windows VMs *

The Roku's IP (192.168.3.172) falls within 192.168.3.168/29), so it's connection attempts were being ignored.

At the root of the issue was that I hadn't assigned the Roku a static IP - when I first set it up it used a completely different IP and dodged this rule. At some point it gained a lease for .172, and playback broke as a result.

So the fix here was to remove a firewall rule that I should have removed years ago.

Conclusion

It's easy to assume that a percentage indicator is showing how much of a file was loaded before it got stuck, but that's not always the case: it's often also an indicator of how far through the process of loading something is.

Roku Media Player appears to first try to load a media file at 13%, which is why so many DLNA playback issues mention that figure. If the Roku's getting stuck at that point, it should be taken as a sign that it's failing to fetch the media - checking connectivity is almost always going to be the first step in resolving that.