default io implementation makes mmsx painful

[spiff]

hi,

this can't really be classified as a bug, but i will try to argue for my patch :)

the mmsx wrapper provides a very convenient interface for applications. however, i have found one issue with it that makes it pretty much useless. this wrapper is a 'try mms, if failed, try mmsh' strategy. i'm proposing changing this to a 'try mmsh, if that fails try mms'. a lot of servers running mmsh streams, seems to use a long time (minutes) to refuse a mms-over-tcp connect attempt. since the default io implementation is sync, this makes for pain in user application.

my patch is based on the observation from some 10-20 streams (mainly mmsh, but also a few some mms-over-tcp). it seems the mms-over-tcp servers immediately refuse mmsh connect attempts. in addition mmsh seems to be the norm these days.

for now i have hacked the client app i''m working on (xbmc).
please consider this for inclusion. feel free to refuse and call me an idiot if there's something i'm missing :)

cheers,

spiff

[Goga777 (igor7)]

thanks a lot
very useful patch
with it xbmc is opening problem mms streams as this mms://stream03.rambler.ru:80/keksfm?WMContentBitrate=150000
in 2-3 seconds

[Hans de Goede (j-w-r-degoede)]

Thanks for the patch, I've fixed this with a slightly different patch, but the end result (try mmsh first) is the same.

Note: moving to launchpad did not completely play out as planned, as the current only active developer for this projects (me) prefers git over bzr libmms has moved back to sf.net.

The patch fixing this is included in the latest upstream release:
http://downloads.sourceforge.net/project/libmms/libmms/0.6/libmms-0.6.tar.gz

Closing this bug.