Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#13 Failed to connect to mms:// stream

v1.0 (example)
closed-fixed
nobody
None
5
2014-04-04
2012-04-28
No

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

Related

Bugs: #13

Discussion

  • Hans de Goede
    Hans de Goede
    2012-04-28

    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

     
  • GstBlub
    GstBlub
    2013-12-11

    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.

     
    Attachments
  • Hans de Goede
    Hans de Goede
    2013-12-12

    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.

     
  • GstBlub
    GstBlub
    2014-01-02

    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.

     
  • GstBlub
    GstBlub
    2014-02-24

    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:

      Any news? It's been over two months...


      [bugs:#13] Failed to connect to mms:// stream

      Status: open
      Created: Sat Apr 28, 2012 12:44 PM UTC by Ernst Martin Witte
      Last Updated: Thu Jan 02, 2014 03:02 PM UTC
      Owner: nobody

      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


      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/libmms/bugs/13/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/

       

      Related

      Bugs: #13

  • GstBlub
    GstBlub
    2014-03-19

    Sounds like this project is dead. I'd be happy to step in and maintain it...

     
    • Hans de Goede
      Hans de Goede
      2014-03-19

      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

       
  • Tom B
    Tom B
    2014-04-04

    • status: open --> closed-fixed
    • Group: --> v1.0 (example)
      This should be fixed in 0.6.3
     
    Last edit: Tom B 2014-04-04