Send intent - http url as audio/* - possible with Automagic, Not tasker

[Michal Bogdanowicz]

So this week I've been trying to force Tasker to send an intent that will launch my music player. The catch is the music stream is an http url but must be passed as a mimetype of audio/* to be picked up by the ServeStream app. I know it can be done because currently Automagic can send this type of intent.

What I want to do with my intent:

action: android.intent.action.VIEW

receiver: activity

data type: audio/*

data:    http://MyFavoriteMusicStreamingSite.org/id/somemusicstreamhere

Now Tasker limits the user to either entering the "Data" field or the "DataType/MimeType" field, but Not both. 

Since my data is a url, the browser always catches the intent and then launches the ServeStream app that handles the stream. I don't want the browser to appear at all, because it acts as a middle man to convert this web url to web url as type audio/*.

Now in automagic I can set both the data and the data type. The information is the same as listed in the bold text.

Why is Tasker limiting the user to types of intents but Automagic provides me with the options that I need to get this to run.

Is this a bug or intended. If it's intended can someone provide me with a solution?

[bdanders]

Have you tried using the "browse url" action in tasker? If there is an app associated with a particular url type (imdb for example), "browse url" will cause that app to open instead of the browser.

[Michal Bogdanowicz]

the URL starts with http://thestreamingsite.com.

Nothing about the url, says or even hints that's it's going to be an audio stream, so again the browser will intercept the intent which is not what I want.

Again the ServeStream app won't even be on the list of app that's can answer this intent if the URL is not cast as audio/*.

[GermainZ]

Use the Run Shell action to launch your intent instead. Type 'am' in a terminal emulator for the command's help. An example (I'm using this to launch the Play Store with the Busybox installer app open):

am start -a android.intent.action.VIEW -d market://details?id=stericson.busybox

Check the 'am' command help for the flags you need. Just type 'am' in a terminal emulator.

[Michal Bogdanowicz]

Thanks this method works, but does require Root.

 I think the send intent function of Tasker should be fixed, so we don't have to have root to send proper intents.

--
You received this message because you are subscribed to a topic in the Google Groups "Tasker" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tasker/mtqk60DpdCA/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to tasker+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Pent]

I replied to your other thread about this.

Pent

[Matt R]

Just for veracity, the "am" shell commands dos not require root.

Matt

[Michal Bogdanowicz]

Can you explain your logic here? Of course you need root.

I made a quick task for Tasker to run this shell script, and it didn't run or do anything until I checked "root".

Also correct me if I'm wrong but android runs on linux(however you want to debate that), from a single user perspective, and the 'am' command is within the /system path which doesn't allow regular user access.

@Pent, ugh, I started a thread yesterday but because it was from my cell, I assumed I lost connection when I posted and everything was lost. I'll try to find it, but can you link me here as well? It'll benefit both threads.

[Matt R]

Try "am start -a android.intent.action.MAIN" without root.  It should pop up a list of apps to use to complete the action, but that will prove that it works.  Works on my phone without root.

Matt

[Matt R]

And here's the link to the other thread: https://groups.google.com/d/topic/tasker/t4bLXDCl0uo/discussion

Matt

[Michal Bogdanowicz]

Oh man this thread just became a double win, because I actually had some suggestions for your App!

q) "Can you explain what you ended up doing to get this to work?

a) Since Taskers send intent is currently broken (You cant set data and mime type at the same time), do this instead

In Tasker choose "Run shell" and type this as the command. The URL you see as the sample, is a stripped down URL, down to the actual Audio stream for the Polish Radio station http://www.rmfmaxxx.pl/

am start -a android.intent.action.VIEW -d http://217.74.72.10:8000/rmf_maxxx -t audio/*

Note how even though this intent is passing a simple URL, the "audio/*" cast makes all the audio apps pop up as possible receivers rather than all my browsers installed.

Ok now I love the ServeStream app, because it's simple, and gets the job done. However I feel the way it handles internet streams could be improved! My suggestion is to improve the hysteresis of when the player decides to stop playing an internet stream and when it picks up again.

Correct me if I'm wrong, but I quickly glanced at your Github source William an noticed you decide to play/pause audiostreams based on logical combination of checks dependant on the carrier network + wifi network connections. I believe, correct me if I'm wrong, but if both sources drop and there is no fallback then the stream stops. Whats more annoying is throughout my morning commute, I often lose my internet connection several. The annoying part I found is that sometimes the stream won't come back at all, until I either hit 'Forward' or 'Play/Pause' again...

My suggestion William is as follows, and should be trivial, as you probably already do some buffering of the stream. The rules for when to play/pause would be as simple as checking the length of the audio stream buffer:

Play when: The buffer reaches X size.

Stop playing when the buffer reaches Y size.

Y will most likely be 0, or some small buffer size value.

X should most likely be a high buffer length such that the stream can continue to play without an internet connection for Z amount of minutes. To compute Z figure out the stream quality and multiply by amount of time to buffer.

This is a big improvement, because 1, we don't care about the state of our internet connection, if we buffer and 2 we should always be trying to automatically reconnect to the stream, and not force the user to hit play/pause/forward. If anything this suggestion could be an advanced option, although I personally don't mind listening to a radio stream that's 5 minutes behind so long as the stream is stable.

On Wednesday, May 8, 2013 10:56:44 PM UTC-4, William Seemann wrote:

Michal, I had another ServeStream user wanting to launch ServeStream directly using tasker. Can you explain what you ended up doing to get this to work? Thanks - William (ServeStream developer)

[TomL]

+1000.  Wow.

Tom