Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Currently the user-agent is set to just_audio and version, I have a requirement that it needs a custom header.
Describe the solution you'd like
Set the UserAgent in AudioPlayer Constructor or an optional argument in setUrl
Yes i also want it thank you
I have implemented a proxy-based solution in the latest commit. There are still unresolved issues with the the position<=duration constraint being violated, although this is regarding a separate PR and I'm working on a fix for that.
Note that the proxy-based solution I implemented does not yet recursively apply headers to items in playlist formats like m3u8 but it should work for simple URLs like .mp3. The solution should also work for Android, iOS, macOS, but not web (a separate solution will be needed for this platform).
The unrelated issue with the duration is now resolved.
Let me know if the headers parameter works for you, or whether you need this to work for playlist formats like m3u8.
Hi I am setting Header like below
Map<String,String> header = {'user-agent' : 'testheader'}
In the request I am seeing the header as user-agent: Dart/2.8 (dart:io), testheader, Is it possible to remove the extra and keep only the xxx as user-agent.
Ah, interesting. Yes I can take a look at that tomorrow.
This should be fixed in the latest commit.
This is now available in the 0.2.0 release.
Hi @ryanheise
I have noticed couple of issues with 0.2.0
Getting below exception while trying to play some url's
E/flutter (15845): [ERROR:flutter/lib/ui/ui_dart_state.cc(157)] Unhandled Exception: HttpException: Invalid response line, uri
E/flutter (15845): #0 _HttpParser._doParse (dart:_http/http_parser.dart:459:15)
E/flutter (15845): #1 _HttpParser._parse (dart:_http/http_parser.dart:328:7)
E/flutter (15845): #2 _HttpParser._onData (dart:_http/http_parser.dart:850:5)
E/flutter (15845): #3 _rootRunUnary (dart:async/zone.dart:1192:38)
E/flutter (15845): #4 _CustomZone.runUnary (dart:async/zone.dart:1085:19)
Also noticed that IcyMetaData is not updating anymore.
I meant whenever I set the custom header in setUrl call IcyMetaData will stop updating.
Hi @getmmg
Regarding the Icy Metadata, to help me test, can you try including the following header in your request?
{ 'Icy-MetaData': '1' }
Hi @ryanheise,
I did set it, I didn't see any change. What should I be looking?
Hi @getmmg
I have hopefully fixed the missing icy headers issue in the latest commit. You should not need to pass the icy header manually now, that will be done by the plugin, so you can try just sending your user agent.
I am not sure about the other error though (the parse error) since I wasn't able to reproduce it.
Let me know how it goes.
Hi @ryanheise,
Yes IcyHeaders are working now Thanks.
This is running fine
and this is the user-agent added by android exoplayer User-Agent: just_audio/1.0.15 (Linux;Android 7.1.2) ExoPlayerLib/2.11.4
When I run the same with the Proxy Server and set the same useragent its failing giving the error
First call don't produce whereas the second one produce error.
Thanks for these test cases, it will be really useful. It is getting quite late here (3:45am!), so I will look into this tomorrow.
The reason for the parse error is because http://109.169.23.22:28976/ is giving a HTTP/0.9 response which is unfortunately not supported by The Dart HTTP libraries.
I can implement a solution that will work for Android only if that will address your immediate needs.
In terms of iOS, there are several options from easiest to hardest:
Another stream on the same server works since it uses HTTP 1.0 (http://109.169.23.22:36263/1). Do you know if there is any way to request the version of HTTP that your stream uses?
Hi @ryanheise,
Android only solution is fine, since I am not building anything for ios at least for now.
Http 1.0 stream you mentioned is a different different stream which I am not interested.
Being a little crazy, I decided on implementing what I thought was the hardest option :-) It turned out to be easier than expected because Dart's HTTP API allows me to detach the socket and implement and handle this exceptional case.
Anyway, I've committed this latest change. Let me know if it works for you.
Hi @ryanheise,
Works perfectly!! Thanks.
Awesome. happy to hear it worked :-)