LiveCode Forums.

Hi! I'm using LiveCode 6.1 under Ubuntu 13.04, writing an alarm clock stack among other things, and for the life of me, I can't get a player object to stream Internet audio.

I have a couple of favorite streams:

Radio Paradise: h t t p : / / w w w . r a d i o p a r a d i s e . c o m / m 3 u / m p 3 - 1 2 8 . m 3 u
KUOW (National Public Radio): h t t p : / / s h o u t c a s t . k u o w . o r g : 8 0 0 2 /

I've tried playing these streams as follows:

set the filename of player "Player" to "h t t p : / / f o o "
start player "Player"

And since these URLs are really playlists, I've tried playing the URLs within the playlists as well.

The closest I've come was getting a short blast of audio of less than a second. I don't remember how I did that. Apart from that one result, all I've gotten is silence.

I've seen mention of mplayer, a Linux multimedia player, in connection with streaming problems, so I installed that too, but no luck.

Can anyone help? Thanks.

Hi,

I was unable to play both URL's in QuickTime on Mac OS X and Windows, but the VLC plug-in knows how to handle the m3u URL. Perhaps you can install VLC on Linux, including the plug-ins for FireFox, and open the URL in a browser. You might also be able to open the URL directly in VLC. Since VLC can be used as a command line app, you might even be able to play the music without making VLC visible, but I haven't tried that.

The other URL isn't media that can be played. It is a website.

Kind regards,

Mark

vlc and smplayer will both open the stream sent from the command line. You can do in LiveCode, for example:

get shell("vlc 'http://www.radioparadise.com/m3u/mp3-128.m3u'") or use smplayer. Note the use of inner (single) quotes around the URL and the double quotes around the entire command to be passed to shell().

vlc buffered and opened the stream much faster than smplayer. mplayer connected but then failed to open the stream here. ffplay does not work.

You can use 'cvlc' to play the stream without an interface.

Shell is blocking, which may matter to you. In that case, you might want to experiment with making this a separate standalone process, using 'open process' which is not blocking. You can make this invisible in the stack settings. You'll need to kill the standalone and vlc separately, although you can kill vlc as part of a shutdown routine of the standalone player process. Closing these processes may require some experimentation, it's not necessarily as simple and intuitive as you might want it to be. I recommend 'shell()' and 'killall'. One important gotcha is that even though 'close process' might not actually end a process, you still have to issue the command in order to use 'open process' again for that command, even though you might have ended that process using another method.

Hi,

Instead of the shell, you might use the open process command. This shouldn't be blocking and you might be able to interact with the process from within LiveCode. If not, you can still use LiveCode's kill command to stop playing.

Best,

Mark

Hi all,

Thanks for your responses so far.

I'm sorry I wasn't clear when I asked for help. I am interested in LiveCode as a way to create an all-in-one alarm clock app. I already have a solution cobbled together out of KAlarm, shell and Perl scripts, Gambas 3, cvlc, and moc. I don't need LiveCode as yet one more component in my Frankenalarm, making system calls to cvlc and what not. I need to be able to stream Internet audio directly with LiveCode, or (at least for this project), it's no good to me. It says it can on the box, so why do so many people have problems with this functionality?

By the way, neither of the URLs I gave is a "website". Both point to stream playlists that I can open with VLC.

Any further help that anyone can provide with opening Internet audio streams directly with LiveCode stacks will be gratefully accepted.

Hi,

LiveCode sees a website, no matter whether you think it is a website or not.

The problem with Linux (still) is that you need to use a combination of tools to get something done. The good thing with LiveCode is that it allows you to build a nice GUI for all those bits and pieces.

Best,

Mark

I had had problems passing parameters in "open process" in the past and didn't even consider it here, but I see that and work. I notice that quoting the URL makes it fail, and this might have been my problem in the past.

Thanks for opening my eyes, Mark!

Mark wrote:Hi,

LiveCode sees a website, no matter whether you think it is a website or not.

The problem with Linux (still) is that you need to use a combination of tools to get something done. The good thing with LiveCode is that it allows you to build a nice GUI for all those bits and pieces.

It sounds like what you are saying is that LiveCode on Linux cannot by itself play streaming Internet audio. Am I reading you right?

Hi,

Not exactly. LiveCode has no problems with playing a mov stream over the rtsp protocol using QuickTime on Windows or Mac OS X for example. Linux is just a little more complicated and this m3u stream just happens to be something QuickTime seems to have problems with. I don't know exactly what mplayer and smplayer are capable of, but there are probably a few formats and protocols that work. Just not the streams you posted. The m3u stream seems to be the wrong format and the website is not being redirected by the server when you set the filename of a player control to the URL of that website.

Best,

Mark

Thanks, Mark. That's actually quite helpful. It sounds as though it would bear experimenting with the various other formats provided by both sites (and other sites, as well).

I guess the one thing about this enterprise I really still want to know is, are there any documented instances of the Linux version of LiveCode streaming audio directly, in any format?

I'm not being snarky. I really want to know. I don't want to spend my time and energy trying something impossible. I'd rather move development of this project to Android, for example. It does seem that people have got streaming working on Android.

[edit] Of course, Android is Linux underneath too, but it uses a different kind of player object.

The player will play streaming audio under Linux. Saving http://www.radioparadise.com/m3u/mp3-128.m3u to a file reveals that it contains several URLs that are the actual sources of the stream:
http://scfire-m26.websys.aol.com:80/rad ... p3_128kbps
http://scfire-d15.websys.aol.com:80/rad ... p3_128kbps
http://scfire-a78.websys.aol.com:80/rad ... p3_128kbps
http://scfire-a32.websys.aol.com:80/rad ... p3_128kbps
http://scfire-n15.websys.aol.com:80/rad ... p3_128kbps

This is what caused ffplay, mplayer and the LiveCode Player to choke on your URL.

Setting one of those URLs as the source for the LiveCode player object does work, although not automatically with good control. As soon as you set the source it loads the cache buffer and starts playing, and is blocking. There are probably ways around that...

I should probably add that LiveCode uses mplayer so that needs to be installed, and I'm producing this somewhat clumsy result on openSUSE. For some reason if I issue 'killall mplayer' from the terminal LiveCode dies along with mplayer. If I end the mplayer instances in the process viewer, LiveCode remains open and blocked. Good luck!

Hi wsamples,

Yeah, I know. Didn't you read the part of my original post where I wrote, "And since these URLs are really playlists, I've tried playing the URLs within the playlists as well"?

I was never able to get one of these internal URLs to work, either, but I'm not sure I tried one after installing mplayer. I'll try again.

If LiveCode player objects require mplayer on Linux, the documentation should really say so. If the docs don't explain that, the installer should pull it in as a dependency. Maybe now LiveCode is GPLed, this kind of thing will get a little love...

Oh, yes, but it obviously slipped my mind as I continued to read through the thread but in this case my poor short-term memory enabled me to find a solution I otherwise wouldn't have looked for Setting one of those URLs as the source does work here. (Also allows mplayer and ffplay to work, too.) I couldn't say why it didn't work for you.

I have found that supressing messages before setting the source prevents automatic playback and allows you to use 'start player 1" and 'stop player 1' to control playback. This leaves LiveCode is no longer blocked and also allows me to issue 'killall mplayer' without the side affect of killing LiveCode. This could all be irrelevant in a finished app, depending on how you implement it, but could be useful information during development.

While this has caused you some frustration, your project isn't without hope. Good luck!

Thanks for the extra details (suppressing messages and so on). I will look into them.

The differences so far might arise from using different distros, or different versions of the same distro. The important thing to me is that now I can reasonably expect some variant of what's been suggested to work, so I won't give up. Thanks, folks.

[edit] Moreover, now people can google this discussion. That's useful.