yomguy / DeeFuzzer

Light and instant media streaming client for web radios and TVs written in Python
https://github.com/yomguy/DeeFuzzer
GNU General Public License v3.0
143 stars 30 forks source link

losing Icecast connection after one second #49

Closed nim4n closed 9 years ago

nim4n commented 9 years ago

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?

achbed commented 9 years ago

What's the deefuzzer log say?

achbed commented 9 years ago

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.

nim4n commented 9 years ago

@achbed , yes It works, thanks a lot

achbed commented 9 years ago

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!

yomguy commented 9 years ago

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?

achbed commented 9 years ago

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.

yomguy commented 9 years ago

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?

achbed commented 9 years ago

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.

yomguy commented 9 years ago

Great!