Version: 1.3.0 (using KDE KDE 3.3.0) Installed from: Gentoo Packages Compiler: 3.4.1 OS: Linux On my Gentoo AMD64 system Arts 1.3.0 does not play mp3 streams correctly, starting a stream from noatun or amarok (w/ arts plugin) plays fine until the end of the mp3. At this point arts does not "return" so the player sits as if the song were playing but nothing happens, in both players you can hit the FF/RW buttons because that signals arts to start a new song. It seems like artsd freezes but since you can advance to the next track it seems stranger than I expected. Running arts -l0 from the cmd line I get this at the end of the run: ----------------------- UnixManager: got notifyIO socketconnection created, fd = 10 findPort(outleft) have 4 ports done result 74 connect port outleft to left findPort(outright) have 4 ports done result 74 connect port outright to right search streamplayobject, mimetype = audio/x-mp3 creating akodeMPEGPlayObject to play file akode: opening input-stream creating packet receiver findPort(left) have 3 ports done result 10 connect port left to inleft findPort(right) have 3 ports done result 10 akode: No media loaded akode: No media loaded (The previous message was repeated 1 times.) connect port right to inright akode: play akode: process_indata warning: leaving MCOP Dispatcher and still 22 object references alive. - Arts::SampleStorage - Arts::Synth_MULTI_ADD - Arts::Synth_MULTI_ADD - Arts::Synth_PLAY - Arts::StereoVolumeControl - Arts::StereoEffectStack - Arts::Synth_BUS_DOWNLINK - Arts::SoundServerV2 - Arts::Synth_AMAN_PLAY - akodeMPEGPlayObject - Arts::FlowSystemReceiver - Noatun::StereoVolumeControl - Arts::Synth_BUS_UPLINK - Noatun::StereoEffectStack - Noatun::Session - Noatun::StereoEffectStack - Noatun::Equalizer - Noatun::StereoEffectStack - Arts::AudioManagerClient - Arts::MidiManager warning: leaving MCOP Dispatcher and still 443 types alive. Killed ----------------------- At the line "akode: process_indata" there is no activity until the process is killed. Both oss and alsa seem to behave the same way. When I hit ^c to kill arts noatun will then begin playing the next track on a new artsd instance. This does not happen with arts 1.2.2 which I can run manually and the noatun from kde 3.3 will behave normally, the way 3.2's did. I am new to reporting KDE bugs, anything else I can do I would be glad to.
From a decoding point-of-view it is just a stream, and there could always appear more data that would need to be decoded. It is upto the application to shut the decoding down when the source of data ends. I will look into where this should happen, but I would like to know if this worked in KDE 3.2?
In KDE 3.2 the applications (noatun for sure) behaved the way I expected they should, when the song "ends" the player continues onto the next track. In fact, since I still have 3.2 & an older version of arts installed, I can run the old artsd from the cmd line and noatun 2.6.0 (KDE 3.3.0) will play like the older (2.4.x) version did running from the 3.2 environment. I discovered this when attempting to listen to streams from magnatune.com so I've been using this album http://magnatune.com/artists/music/Electronica/Magnatune%20Remixed/Ridin%20the%20Faders/ to test since it has some very short tracks. But this also happens to songs that I ripped myself and are streamed off a gnump3d server, these mp3s play normally from the harddrive with both versions of artsd running.
CVS commit by carewolf: Close streams if EOF is reached. BUG: 88092 M +13 -12 akodePlayObject_impl.cpp 1.27 --- kdemultimedia/akode/arts_plugin/akodePlayObject_impl.cpp #1.26:1.27 @@ -459,7 +459,7 @@ void akodePlayObject_impl::process_indat } -void akodePlayObject_impl::processQueue() { +void akodePlayObject_impl::processQueue() +{ while (!m_packetQueue->empty()) { - long freespace = m_bytebuffer->space(); @@ -475,4 +475,5 @@ void akodePlayObject_impl::processQueue( return; } + if (instream.eof()) m_bytebuffer->close(); }