It is weird that I can't find @phenning post now. It seems just vanished. I have seen this kind of disappearing post several times, but I mostly forgot it. Your post is the proof that you have read phenning's post before it disappear. Maybe forum's problem?
@phenning : Thanks to your simple html which host the mp3 and you say you can play the music directly using google play music. I have tested it out, and we don't need 3rd party app to play the sound. Simply put the url link to your remote webserver in the action "sound". Something like
Automagic will download the file and play (stream) the mp3 immediately, much better. To stop the song, use stop action sound.
But if you need to use 3rd party app, such as play music, you can still stop the sound using action Control Audio Player, choose Media Button Stop, send to specified app, pick play music
However using sound to play remote url file will always redownload the file at every play. This will waste your emmc write cycle. So if you need too play the same file again and again, and still want to be able to keep adding file, better instruct the remote client to download the mp3 first, and play it locally. Or you can also upload the file to the remote client, move the file to directory and play it. Upload takes much more config though.
@BoBo : I learnt so many things this week. I just discovered my phone support ramdrive all the time using tmpfs created by default in /storage/self. I now have temporary super high speed disposable space to process my temporary file. This ramdrive can be used to hold the temporary stream mp3 file without reducing my emmc write cycle. I have to modify a lot of my "PC link" flows to use this RAM drive instead. Copying and processing temporary file will be much easier then.
Back to your topic, playing audio file remotely. You don't need any other app to do it, Automagic can do it all. Now let's give name to each device.
Device A, your phone. it has the mp3 file, it has Automagic and can send the file to the remote device
Device B, your tablet. It is passive, it has automagic, the trigger HTTP request should be enabled in all method and waiting command from the phone A.
There are several methods to do it.
1. Stream method
The same as phenning method above.
Phone A : act as webserver, Automagic Http request trigger enabled. Add Action write HTTP Response file, point to your mp3, example song1. To have multiple files choices, you need to create map object to store the naming. But let's leave that first and use only single file.
Tablet B : act as webserver too, but only to receive command. HTTP request trigger enabled and action Sound.
Phone A then use another flow to use HTTP request to Tablet B IP, example
http://192.168.101:8080/automagic/playsong1. Tablet B react to this command, take the playsong1 command and use action Sound to play the remote file at phone A, example
http://192.168.1.100:8080/mp3/song1. Phone A react back to this sound action and give the mp3 stream of song1. (remeber to encodeurl if url has space or special char).
Phone A can use another command using HTTP request to Tablet B,
http://192.168.101:8080/automagic/stop. Tablet B react and use stop action sound, which stop playing the sound.
This method require Phone A to act as webserver too. And the downside is tablet B will always redownload the song at every play, wasting bandwidth and reduce the tablet's emmc lifespan. Use this method only if you play different file everytime. I don't recommend this method.
2. Download method
Similar to 1. Stream method. But Tablet B don't use action sound directly. It first check to the song folder in the tablet, example exists("/sdcard/Automagic/song/song1.mp3"), if it already has the song1 file, it directly use action sound to play. But if not, then it use Download files to download from Phone A, store it in the song folders as song1, then use action sound to play it.
This method still require phone A to act as webserver too. It only download the song if it doesn't have the song yet. This will save bandwidth and reduce unnecessary emmc write. But the tablet memory will keep filled up.
3. Upload method
This method is different that 1 and 2.
Phone A : doesn't need webserver. It only has to have the files.
Tablet B : still have the webserver standby
Phone A use HTTP request to Tablet B. Tablet B check if already have the file, directly play it. If not, then it response to Phone A, it doesn't have the file yet. Phone A continue the flow and use HTTP reqeust again, use POST method, Content Type : Form Data File Upload, choose the mp3 to upload. At the Tablet B, it will receive the file as temporary name, store in the path of variable {file_upload_field}. Rename the file to {http_params} (real file name from phone A). Then use action sound to play the file.
This method has the plus side that Phone A now doesn't have to enable the web server anymore. It only need to send the request and upload the file. I prefer this method, but it need more configuration than other method.
4. Upload method with FTP
This is similar to 3rd one, but it require the tablet to have FTP server. MiXplorer can create FTP server with password. It is redundant compared to method 3, but maybe you already have FTP server always enabled on the tablet.
Same as method 3, but instead of HTTP request using upload method, you use action FTP upload and you can copy directly to the proper path, You don't have to deal with the http params anymore.
This method has downside of additional FTP server, which might not be suitable if you want to keep the resource at minimum.
PC version.
With PC, windows or linux, you can use binary curl to post the request or upload the file. For Windows, you can use eventghost with python script to send the request or upload file, just like what I am using. That's why I need temporary storage path to save these kind of files.
It takes a while to create a proper flow with mutilple files choices and map object. (i only have proof concept with single file). I maybe only can create it tomorrow. So meanwhile, see which method suit you the best. I still prefer method 3 though.
Sorry!
