I have miniDLNA 1.0.21 running on a stock Ubuntu 10.04 LTS. It is correctly scanning all the relevant folders and finding all the files.
Requests to serve MP3 files for playback (typically http://server:port/12345.mp3) are succeeding as expected.
Requests to serve WMA files for playback (typically http://server:port/12345.wma) are failing to complete on some devices.
- On some connected devices (XBOX360, PURE Evoke Flow) the device hangs and then aborts saying it can't play the file (error code on the XBOX is 19-04-8007032)
- The XBOX will play the same file if it's on a USB device attached to the XBOIX
- Using Google Chrome, the beginning of the file will sometimes play, and then it hangs. The network developer tool suggests the browser is getting the file completely from miniDLNA.
- Using Firefox , the entire file plays as expected
- On a Nokia N900 the entire file plays as expected
- Using WGET, the entire file is retrieved and plays as expected
My conclusion is that there's something in the way the HTTP server in miniDLNA is responding to requests, but I've no idea how to fix the problem? Any help or suggestions very much welcomed.
I'm not an expert on dlna or minidlna so I could be off base with my advice. I would be seriously surprised if Chrome has a dlna client. Did you just paste the minidlna url into the tool bar? or the wget command line? That approach may lead to chasing the wrong problem.
First is wma streaming supported by XBOX and PURE Evoke Flow and Minidlna. I can't answer because I don't have any .wma but I've run across .wmv with wildly different playback experiences. Is their one .wma file that works when served by minildna or do all fail? If some work and some don't then your have to dig into what makes them different.
Another thought just occurred to me - are these .wma Audiobooks? Has the digital rights management been removed (that would explain the difference between usb files and dlna streams). A puzzler.
Hello ccoupe - thanks for the reply.
I'm just posting the relevant URL into the different browers and devices, rather than using a DLNA client directly. As I understand it, it's mandatory for DLNA sources (and devices) to support HTTP transport, so that should work correctly.
The XBOX will play the .wma file if it's provided as a file on a USB Mass Storage device directly connected to the XBOX, but won't play it at all if it's trying to retrieve it using HTTP from the server.
The .wma files are entirely unprotected, constant bitrate files at between 128kbps and 192kbps, using Windows Media v9. codecs.
All .wma files behave the same way. (All the mp3 files work correctly on all the devices).
So I'm stumped. I have narrowed it down to the HTTP transport provided by miniDLNA, but I can't see closely enough the differences between requests made by Chrome/XBOX/PURE (which fail) and those from the N900/Firefox/WGET (which succeed).
Yes, DLNA does use http FOR TRANSPORT. DLNA is a protocol that uses http. You really need to use DLNA clients to talk to a DLNA server in a meaningful way. You are trying to use http in a way that DLNA servers don't like. Minidlna works just fine for quite a few people It's http does work for DLNA.
I'd concentrate on why the XBOX dlna client can't play the .wma files. Does the xbox see the server, browse the server folders and song titles, play one of them, pause, stop, repeat, etc.
You might want to enable debugging output in the minidlna log file and see what it says about the xbox requests and your attempts using web browsers.
If you have a lot of time and patience, you can install wireshark on Ubuntu and watch the protocol in action. Not for the faint of heart, but very educational.
The XBOX is successfully discovering all the meta-data about the file - navigation and listing is all correct. It is correctly playing back MP3 files. I don't know why MP3 files always play but .wma files never play on some devices. The .wma files will play if they're on a USB Mass Storage device directly attached to the XBOX, so I'm confident it's not a problem with the .wma file or its contents.
The standard minidlna.log file isn't giving much information. I've turned on verbose debugging to the console window, and can see all the XML passing between the server and the client, and it's correct.
I can see in the console debug the incoming HTTP GET request from the XBOX, and it's asking for the correct item, which the server says it is serving. However, the XBOX waits in silence for 2-5 seconds before failing, marking the item with a failed play icon. Clicking on the icon displays the error message that it can't play the file, and the error code 19-04-8007032.
The only thing I have been testing in the browsers is the HTTP GET request for the media element itself. I've run both Chrome and Firefox in their developer modes where you can see the traffic passing between the browser and the server (and it's less pain than wiresharking), and there are some minor variations in the HTTP headers passed to the server, but none that should affect the transfer of the file.
My next step is to diff the HTTP headers that Chrome (which fails) is sending and Firefox (which works) is sending. Then I'll have to wireshark the IP port to find out what the XBOX is asking for.
Other people (via google search) are having that error code problem using many different servers/configurations. That's where I'd start my research. What does that code mean.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.