losing Icecast connection after one second
nim4n opened this issue · 9 comments
Hi
I have some problem with running DeeFuzzer, the problem is I can see the my_station.mp3 for one second and after that for some reason I lose the connection and I don't know why! as you can see my xml file is:
<deefuzzer>
<log>/home/niman66/Temp/deeF/nima.log</log>
<m3u>/home/niman66/Temp/deeF/nima.m3u</m3u>
<station>
<infos>
<short_name>my_station</short_name>
<name>My best funky station</name>
<description>My personal best funky playlist ever !</description>
<url>http://localhost</url>
<genre>Various Funk Groove</genre>
</infos>
<server>
<type>icecast</type>
<host>localhost</host>
<port>8000</port>
<sourcepassword>admin</sourcepassword>
<public>0</public>
</server>
<media>
<dir>/home/niman66/Music/ebi/</dir>
<format>mp3</format>
<bitrate>192</bitrate>
<ogg_quality>7</ogg_quality>
<samplerate>44100</samplerate>
<voices>2</voices>
<shuffle>1</shuffle>
<m3u>/home/niman66/Temp/deeF/nima.m3u</m3u>
</media>
<rss>
<dir>/home/niman66/Temp/deeF/</dir>
<enclosure>0</enclosure>
<media_url>http://localhost:8000/media/</media_url>
</rss>
</station>
</deefuzzer>
and the icecast2 log is:
[2015-01-11 12:08:27] INFO connection/_handle_source_request Source logging in at mountpoint "/my_station.mp3"
[2015-01-11 12:08:27] INFO source/source_main listener count on /my_station.mp3 now 0
[2015-01-11 12:08:38] WARN source/get_next_buffer Disconnecting source due to socket timeout
[2015-01-11 12:08:38] INFO source/source_shutdown Source "/my_station.mp3" exiting
the strange thing is when I run "deefuzzer deefuzzer.xml" my nima.m3u file content change to this:
#EXTM3U
#EXTINF:-1,my_station - My best funky station : http://localhost
http://localhost:8000/my_station.mp3
am I missed something?
What's the deefuzzer log say?
I think I may see your problem - there are really two separate M3U files here. Line 3 is your output M3U with reference to the station. The M3U under Media is an input M3U file that should contain the media files to play. If they're the same, things will definitely blow up.
I suggest you change line 3 to <m3u>/home/niman66/Temp/deeF/nima-stream.m3u</m3u>
and see if that helps.
No problem! I'd highly suggest checking out the dev branch if you can. There's a lot of updates and fixes in there. I'm now using it for a production site that's running 24/7 with 15+ streams with a single instance of Deefuzzer. Performance has been great and it's running real smooth. I think we're getting close to launching a version 0.7 (we're still doing final testing but things are looking good).
Also, if your issue is fixed, please close the issue when you have a minute. Thanks!
Thanks for helping @achbed.
As too many people don't make the difference so much between the 2 fields, I think we could rename <media><m3u>
to <media><playlist>
. It could then handle M3U files as some other types, like simple text containing the paths to the media files. What do you think about that?
See #4, #21 and #47. We're moving away from separate <m3u>
and <dir>
options (with confusion when you specify both) to a single <source>
that is then handled automatically depending on if it's a folder or file. If it's a file it's assumed to be an M3U file currently. We are then set up to start detecting file type and handling things like CUE files.
Ah ok, <source>
is good like implemented in #47.
So to be clear, we can replace <dir>
and <m3u>
with <source>
and detect the type of it, right?
Yes - that's the intent. The actual effect in that patch is that we use the m3u
value as source
internally, override it with dir
, then override that with source
. This ensures that only one will be used, with a preference towards the newer names. Then at runtime it auto-detects based on whether the internal source
is a folder or a file.
Great!