Streaming issues

Hi all,


I'm trying to play streaming mp3 here on local net.
I got the server (ampache) delivering the mp3 from the collection.
I set the AWeb to launch the tunenet with "-browser -p5 -playlist %f".
The playlist is loaded fine, but when first item finishes playing is starts again.
Is there any option that should be taken care off?
Selcting different playlist doesn't do nothing untill I quit tunenet.
I could overcome this by making a script that fisrt kills the tunenet and then launches a new instance, but I prefer a more elegant way if possible.

Also (not really tunenet related):
I can't see tags of the streamed file (when the file si played in non-streamed mode it can disply it).
"Mplayer -streamdump" on the file's url results in dump with the same contents as the original file.
Is there anything I can do?


TIA,
Jack

@Jack

Stream with Tunenet and everithing goes fine.

@MamePPCA1

I guess you're streaming shoutcast or its like stream.
Here I made the server to stream the actual mp3 file without any additional transcoding.
(I want the file to be streamed on demand, the server acts as a local music storage).
So my the stream is not a shoutcast data
(not a header with metadata containing the location of the next metadata point with the music between them,
but simple streaming of mp3 file).
Something prevents from tunenet catching the tags.
Same happens with mplayer pointed to the files url: no tags are detected unless the file is played from filesystem intead being a url.

Very frustrating. The reason for dioing these acrobatics (while I can access the files via with samba) is that the server provides an option to submit data to lastfm.
If tunenet had a possibility to hook to a script after completeng playback of one file, then the scrobbler is obvious (already have the code waiting for that option to materialize).

Jack

@Jack

Really I don't understand this very well.
The docs can help you too.
If not extract info on the Internet

Javi

Looks like I found the reason: traced the srever and it definitely closes the connection once file is done.
Tunenet starts again the same playlist entry instead of skipping to the next one.
Imho, the correct behaviour should be to skip to the next entry (or at least some config option for behaviour swithching).


Jack