Re-sending an initial handshake if no data has been received
Bug #517007 reported by
Nicola
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libmms |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Please look at this gstreamer bug:
https:/
seems there is a bug in libmms that doesn't resend an initial handshake if no data has been received on an established
connection for a while,
can you test the public url:
mms://scry.
to verify the issue?
thanks
Nicola
I've just tried this, and when using this URL: scry.dubuque. k12.ia. us:1755/
mmsh://
It works fine under Fedora (+ rpmfusion libmms packages). note that rpmfusion's libmms contains a whole bunch of libmms patches, done by me (one of the libmms devs). Since libmms was moved to launchpad I no longer have commit access. I've send my patches to Soren quite a while ago but they have yet to be applied.
With this URL things indeed do not work: dubuque. k12.ia. us:1755/
mms://scry.
For some reason rather then timing out in the connect and falling back to mmsh, the connection just hangs. Note that the
order of first trying mms and then mmsh for mms URL's is being discussed in launchpad bug 512089.