After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 310053 - User-agent problem and asf stream is not recognized
User-agent problem and asf stream is not recognized
Status: RESOLVED DUPLICATE of bug 375867
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks: 138435
 
 
Reported: 2005-07-11 19:30 UTC by Rob Bank
Modified: 2009-09-09 17:04 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
download from server (2.40 KB, application/octet-stream)
2006-01-12 19:08 UTC, Andy Wingo
Details

Description Rob Bank 2005-07-11 19:30:07 UTC
Please describe the problem:
There are actually 2 problems:

1) After lots of testing using strace and mplayer it seems that the streaming
server doesn't know about the gnome-vfs User-Agent header. In this case the
streaming server gives back the playlist instead of the stream. 
If i set the user-agent through the  GNOME_VFS_HTTP_USER_AGENT environment
variable i will get the stream. 

2) When i get the stream, the spider does not seems to  recognize the stream,
causing the following error:

ERROR: from element /pipeline0/spider0/sink_ident: Could not determine type of
stream.


Steps to reproduce:
1.export GNOME_VFS_HTTP_USER_AGENT='NSPlayer/4.1.0.3856' (ripped this user-agent
from mplayer trace)
2. gst-launch-0.8 gnomevfssrc
location=http://www.garnierstreamingmedia.com/asx/radio538.asp ! spider ! volume
! audioscale ! audioconvert ! $(gconftool-2 -g
/system/gstreamer/0.8/default/audiosink)
 


Actual results:
I get the following error:
ERROR: from element /pipeline0/spider0/sink_ident: Could not determine type of
stream.


Expected results:
I expect that the spider recognizes the stream

Does this happen every time?
yes

Other information:
I tested this with different streams from the same streams provider, they all
have the same symtoms.
Comment 1 Ronald Bultje 2005-07-16 14:44:09 UTC
I still get the playlist with that environment variable set...
Comment 2 Christoph Burghardt 2005-08-10 19:46:56 UTC
I can reproduce the bug as described above. Spider and decodebin give both the
same error message. I use current cvs BRANCH_GSTREAMER_0.8
Comment 3 Luca Ognibene 2005-09-19 18:52:47 UTC
I get the playlist too.. dunno..
Comment 4 Andy Wingo 2006-01-12 19:06:15 UTC
I get the playlist as well. Using wget on the url in the playlist while setting the user agent I get about 2 kb of data, but neither gst-typefind-0.10 nor gst-launch-0.10 nor gst-typefind-0.8 tell me anything. Does not appear to be a GStreamer issue. Attaching the data I get just to see if anyone knows anything.
Comment 5 Andy Wingo 2006-01-12 19:08:00 UTC
Created attachment 57244 [details]
download from server

Length: 2,461 (2.4K) [application/vnd.ms.wms-hdr.asfv1]
Comment 6 Andy Wingo 2006-01-27 14:49:04 UTC
Making this block the playback tracker, but it might not be a bug. Need someone else's input on this. Filing under base since it's a typefind function issue.
Comment 7 Tim-Philipp Müller 2006-07-10 17:13:19 UTC
Of all players I've tried only one player plays the above URI and that is VLC, and it somehow (magic? s/http/mmsh/ if there's the MSWMExt stuff?) seems to end up with a mmsh:// URI, namely:

  mmsh://81.23.249.5/radio538?MSWMExt=.asf

which we play fine as well.

So it seems to be mostly a playlist parsing issue. No idea whatsoever what the binary blob is that we get when we pass the user agent stuff though.
Comment 8 David Schleef 2008-08-19 02:20:02 UTC
This works in the totem mozilla plugin, but not in the standalone player.  Is it even relevant that playbin doesn't handle URLs like this?
Comment 9 Edward Hervey 2009-03-11 08:05:29 UTC
The playlist handling is done by applications and not by GStreamer.

Shoudl this bug be closed ?
Comment 10 Sebastian Dröge (slomo) 2009-09-09 17:04:09 UTC

*** This bug has been marked as a duplicate of bug 375867 ***