UPnP/DLNA, Samsung Galaxy S, and Broken Streaming

[Michael Pedersen <mythtv@…>]

I recently bought a Samsung Galaxy S. It supports DLNA out of the box. As I've read elsewhere that DLNA is a strict subset of UPnP, I was quite excited to try it out streaming data from Myth.

Things have not gone well, though I suspect user error somewhere in this. I just don't know where else to look.

I grabbed a video from YouTube?. It's an MP4 file, with H.264 video, and AAC audio. I went for a low resolution version to make it more likely to stream properly over wifi (for now), so the resolution is 480x270. The video itself is 3m47s long.

Tests I have run:

1. Stream from the phone to my PS3 via DLNA: Works.
2. Stream from my MythBackend? to my PS3 via UPnP: Works.
3. Browse MythBackend? from phone to see video in video list: Works.
4. Download video from MythBackend? to phone, and play from internal memory: Works.
5. Stream video from MythBackend? to phone: Fails.
6. Place an alternate DLNA server elsewhere on my network, and download from that: Works.
7. Place an alternate DLNA server elsewhere on my network, and stream from that: Works.

Alternate DLNA Server: minidlna, downloadable from sourceforge. Project page is at ​http://sourceforge.net/projects/minidlna/

Everything else works. It works everywhere else. It just can't stream from the mythbackend to the phone for some reason.

I decided to dig into the actual communications. I am attaching three files to this ticket. These files are all tcpdumps of sessions between the phone and the server. The phone is at .134, my myth server is at .133, and my desktop (where I installed minidlna) is at .110.

1. minidlna-stream.dmp: A portion of the successful stream from minidlna to the phone.
2. mythtv-stream.dmp: The (short) file which shows what happens when the stream fails from mythtv.
3. mythtv-download.dmp: A portion of the downloaded stream from mythbackend to the phone.

The part that is most interesting to me in the comparison is the GET request that is sent by the phone in each of these cases. Using the download option, this GET request is sent:

GET /Myth/GetVideo/Id100017 HTTP/1.1

Using stream, the following get requests are sent:

GET http://192.168.1.133:6544/Myth/GetVideo/Id100017 HTTP/1.1
GET http://192.168.1.110:8200/MediaItems/17.mp4 HTTP/1.1

In the dump, you can see that Myth (at .133) returns a 404 for that GET request, while minidlna handles it just fine.

From my perspective, it looks like Myth is not set up to strip out the IP address from a GET request (along with protocol and port) before attempting to resolve the file.

This is probably some sort of user error on my part, though I don't know how to fix it.

The version of MythTV is v0.23, as comes from Ubuntu 10.04, so the full version is named "0.23.0+fixes24158-0ubuntu2". Note that I applied the patch in #8643, thinking it might have been a mime type issue. To do so, I used the following steps:

apt-get source mythtv
apt-get build-dep mythtv
cd mythtv-0.23.0+fixes24158/
patch -p1 <patch.txt 
dpkg-buildpackage
cd ..
dpkg -i libmyth-0.23-0_0.23.0+fixes24158-0ubuntu2_amd64.deb libmyth-python_0.23.0+fixes24158-0ubuntu2_all.deb \
    mythtv-backend_0.23.0+fixes24158-0ubuntu2_amd64.deb mythtv-backend-master_0.23.0+fixes24158-0ubuntu2_all.deb \
    mythtv-common_0.23.0+fixes24158-0ubuntu2_amd64.deb mythtv-database_0.23.0+fixes24158-0ubuntu2_all.deb \
    mythtv-frontend_0.23.0+fixes24158-0ubuntu2_amd64.deb \
    mythtv-transcode-utils_0.23.0+fixes24158-0ubuntu2_amd64.deb
restart mythtv-backend

[Michael Pedersen <mythtv@…>]

Failed stream from mythtv-backend tcpdump

[Michael Pedersen <mythtv@…>]

I'm sorry the other two files aren't attached. I'm still truncating them down to the 512K limit. I will fix ASAP.

[Michael Pedersen <mythtv@…>]

Download from MythTV Backend

[Michael Pedersen <mythtv@…>]

minidlna with successful streaming, for comparison

[Michael Pedersen <mythtv@…>]

Corrected download packet capture. I chopped too early on the previous file, this includes the first few successful packets of the download

[beirdo]

Adding myself as a CC. I may take this bug if dblain isn't looking into it.

[beirdo]

Patch to potentially fix - v1

[beirdo]

Please try that patch (made against trunk, but hopefully will work for you in 0.23-fixes), and let me know if it fixes the issue.

[Michael Pedersen <mythtv@…>]

Minor alteration of 0001-Attempt-to-fix-8678.patch that completes the fix

[Michael Pedersen <mythtv@…>]

I've just updated the patch. Being an idiot, I forgot to enable logging, and then to check it. My updated patch shows the final URL being requested (uncomments a logging line). It also changes how the QRegExp is made, since the pattern '​http://.*?/' is valid Perl regex, but invalid to get minimal, according to ​http://doc.trolltech.com/4.6/qregexp.html#notes-for-perl-users

This uses the QRegExp to go minimal. Tested with this patch, and it is confirmed to work for me. It might not meet coding guidelines, though, so please validate and adapt as necessary. I'll rebuild and re-run if need be to verify again.

[beirdo]

Ah yes. Silly qt regexps. I should have double-checked that :) Thanks.

[beirdo]

(In [25390]) Strip out the leading ​http://host:port/ from UPnP requests before parsing out the method.

Fixes #8678

[Michael Pedersen <mythtv@…>]

Not trying to reopen, so I apologize if I do. Just wanted to say thank you for your quick turn around on all of this: Initial response, and putting the final patch into the trunk.

It's very appreciated. Thank you.