Dear libmms-Team,
I just noticed that libmms (and thus applications using libmms such as KRadio4, gstreamer, totem, ...) seems to fail to connect to certain mms:// streams (or servers). VLC plays those well. One such streams is:
mms://roquette.94fm.rj.gov.br:8000/
The debug output with the environment variable LIBMMS_DEBUG set is:
mmsh: trying to connect to roquette.94fm.rj.gov.br on port 8000
mmsh: connected
mmsh: first http request
mmsh: send_command:
GET / HTTP/1.0
Accept: */*
User-Agent: NSPlayer/4.1.0.3856
Host: roquette.94fm.rj.gov.br:8000
Pragma: no-cache,rate=1.000000,stream-time=0,stream-offset=0:0,request-context=1,max-duration=0
Pragma: xClientGUID={c77e7400-738a-11d2-9add-0020af0a3278}
Connection: Close
mmsh: answer: >HTTP/1.0 503 Service Unavailable<
mmsh: http status not 2xx: >503 Service Unavailable<
mmsh: connect failed
mms: trying to connect to roquette.94fm.rj.gov.br on port 8000
mms: connected
mms: send command 0x01
mms: error reading packet header
mms: unexpected response: 00 (0x01)
A TCP-Stream analysis shows that the stream gets terminated (tcp FIN) by the remote side after the connect header has been sent. libmms seems to have two tries, VLC seems to have a third try (the first two fail similarly as in libmms) with a higher Version number in the connect header (NSPlayer 7.10.0 instead of 7.0.0). But I'm not sure if this is the only reason.
If you need any more information, please let me know.
Best regards and many thanks,
Martin
Hi,
Thanks for the detailed buig report! Can you try rebuilding libmms so that it immediately tries with a version of "NSPlayer 7.10.0" when falling back from mmsh to plain mms, and see if that helps?
Thanks & Regards,
Hans
Changing the version does not help. This is actually a bug in mmsh.c in get_header(). A call to interp_asf_header(this); is missing there. What is happening is that get_header() is reading the CHUNK_TYPE_ASF_HEADER chunk and then it is reading a CHUNK_TYPE_DATA chunk. However, because interp_asf_header() is not called until get_header() returned, processing the first CHUNK_TYPE_DATA chunk fails because asf_packet_len is still 0, so get_header() fails. The attached patch should fix this issue.
Thanks for the patch. I've not had much time for libmms lately (otoh there has not been much need for work to be done there either). I'll try to make some time to review and merge this soon-ish. But don't count to much on it happening really soon.
I know you're busy, but any chance you could review this fix? There's quite a few products affected by this flaw, especially anything that's based on gstreamer.
Any news? It's been over two months...
I'd like to step in and make a release, but the ugly truth is that I
no longer have any idea about how the current release process works,
not to mention testing. I'm afraid my release would do more harm than
good. Søren?
On 24 February 2014 16:05, GstBlub gstblub@users.sf.net wrote:
Related
Bugs:
#13Sounds like this project is dead. I'd be happy to step in and maintain it...
Hi,
It is not completely dead, it is more or less on life support, I'm still trying to maintain it as time permits. I was actually planning on adding the fix for this bug + various other bugs filed here at sf.net, and do a new release one of these days. The problems is time does not really permit this.
So I'm very much interested in your offer to become a co-maintainer. The only problem I have, and please don't take this personal, is that you seem to lack a proven track record in contributing to other FOSS projects.
Now everywhere needs to start somewhere, so that is fine, but that makes me somewhat reluctant to grant you admin rights here on the sf.net libmms project right away.
I would like to propose that you create a git tree with all the patches we want to add to a new 0.6.3 release + updated changelog, etc. All ready for a new 0.6.3 release, and then push this somewhere where I can review it (ie github) and then I'll do a quick review, and if everything looks good I'll make you an admin of the sf.net libmms project and you can do a new release.
Does that sound like a plan ?
Thanks & Regards,
Hans
This should be fixed in 0.6.3
Last edit: Tom B 2014-04-04