Bug 169926 - Tracks streaming from an Ampache service stop randomly
Summary: Tracks streaming from an Ampache service stop randomly
Status: RESOLVED FIXED
Alias: None
Product: Phonon
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.2 (KDE 4.1)
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Matthias Kretz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-27 12:26 UTC by Sérgio Gomes
Modified: 2010-12-05 21:36 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 4.4.1


Attachments
Amarok runtime log (133.74 KB, text/plain)
2008-09-01 15:27 UTC, Sérgio Gomes
Details
New log, with new Amarok (115.13 KB, text/plain)
2008-09-01 17:13 UTC, Sérgio Gomes
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sérgio Gomes 2008-08-27 12:26:11 UTC
Version:           SVN revision 853114 (2008-08-27) (using Devel)
Compiler:          gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) 
OS:                Linux
Installed from:    Compiled sources

When streaming a track from my Ampache server with Amarok, playback stops randomly into the track (20 seconds, 24 seconds, 40 seconds, etc.).

Until then, the track plays fine. After that, the time bar freezes at that point. Stopping the track works. However, after that, no more ampache tracks will start playing until Amarok is restarted -- they all stay at 00:00 until stopped.

Could this be because I'm streaming over HTTPS?

This is a recent SVN version of Amarok (revision 853114, 2008-08-27). Operating system is Ubuntu Gutsy, running KDE 4.1 compiled from source (recent SVN, post 4.1.0).

Ampache server is latest stable and works fine with the web interface and flash player.
Comment 1 Mark Kretschmann 2008-08-27 12:31:28 UTC
I can't reproduce this problem with http, so it could indeed have to do with https.

At any rate, this would probably be a Phonon issue then, so I'm reassigning.
Comment 2 Sérgio Gomes 2008-08-27 12:41:47 UTC
Thanks for the speedy replies. A quick look through the log seems to confirm it:

amarok(23759)/phonon (xine backend) Phonon::Xine::XineStream::xineOpen: xine_open failed for m_mrl = https://sgomes.com/ampache/play/index.php?song=18&uid=-1&sid=0beb0374c96c45ca4c505ce31615f838&name=/Air%20-%20Le%20Voyage%20De%20Penelope.mp3
amarok(23759)/phonon (xine backend) Phonon::Xine::XineStream::error: 1 "Cannot find input plugin for MRL [https://sgomes.com/ampache/play/index.php?song=18&uid=-1&sid=0beb0374c96c45ca4c505ce31615f838&name=/Air%20-%20Le%20Voyage%20De%20Penelope.mp3]"

Although in this case it's odd that it does play back a bit before stalling... Any ideas?
Comment 3 Matthias Kretz 2008-09-01 14:34:05 UTC
can you please attach the full debug output? I guess xinelib itself can't handle https but Phonon then does a fallback to KIO's https.
Comment 4 Sérgio Gomes 2008-09-01 15:27:18 UTC
Created attachment 27167 [details]
Amarok runtime log

Started, opened Ampache library, loaded an album, played the last track, error happened, pressed stop, killed the Amarok process.
Comment 5 Sérgio Gomes 2008-09-01 15:28:12 UTC
I'm attaching the full output for a new run I did just now. Amarok is compiled with full debug, but Phonon might not be. Let me know if you need me to recompile anything else with full debug.

Thanks!
Comment 6 Sérgio Gomes 2008-09-01 17:13:59 UTC
Created attachment 27168 [details]
New log, with new Amarok

The last log didn't come from the latest Amarok, this one does.
Comment 7 Myriam Schweingruber 2009-11-08 11:24:19 UTC
This is the relevant part of the output:

amarok: BEGIN: void CurrentEngine::stoppedState() 
amarok: END__: void CurrentEngine::stoppedState() - Took 0.00028s 
amarok: BEGIN: void CurrentTrack::dataUpdated(const QString&, const QHash<QString, QVariant>&) 
amarok(22892) CurrentTrack::dataUpdated: CurrentTrack::dataUpdated
amarok: END__: void CurrentTrack::dataUpdated(const QString&, const QHash<QString, QVariant>&) - Took 0.0003s 
amarok: BEGIN: void CurrentEngine::resultReady(const QString&, const Meta::AlbumList&) 
amarok: END__: void CurrentEngine::resultReady(const QString&, const Meta::AlbumList&) - Took 4.4e-05s 
amarok: BEGIN: void EngineController::slotStopFadeout() 
amarok: END__: void EngineController::slotStopFadeout() - Took 0.00012s 
amarok(22892)/phonon (xine backend) Phonon::Xine::Backend::disconnectNodes:
amarok(22892)/phonon (xine backend) Phonon::Xine::Backend::disconnectNodes:
amarok(22892)/phonon (xine backend) Phonon::Xine::Backend::connectNodes:
amarok(22892)/phonon (xine backend) Phonon::Xine::AudioOutput::graphChanged:
amarok(22892)/phonon (xine backend) Phonon::Xine::XineStream::event: 

Do you still experience this with KDE 4.3.3?
Comment 8 Sérgio Gomes 2009-11-10 14:38:43 UTC
I'm afraid it will be a while before I can test this out with 4.3, since I'll need to compile it from source on a Hardy install, which won't be easy...
Comment 9 Myriam Schweingruber 2009-11-30 13:36:46 UTC
Sergio, instead of compiling on Hardy, why not just upgrade to Karmic?
Comment 10 Sérgio Gomes 2009-11-30 14:35:11 UTC
Believe me, I would love to upgrade to Karmic, but unfortunately I'm forced to keep this machine in the Hardy LTS release...

I'll try to find the time to set up a VM with Karmic for the purposes of testing this bug, though, if that's OK. My guess is that the problem, if still present, would be pretty much independent of distro and (virtual) hardware configuration?
Comment 11 Myriam Schweingruber 2009-12-11 22:29:30 UTC
If it is indeed a Phonon bug, then the version matters a lot, since Hardy still uses a previous version. Current version is KDE 4.3.x, and 4.4 is out soon, while Hardy ships 4.1.x which uses Phonon 4.2 IIRC
Comment 12 Myriam Schweingruber 2010-02-09 23:07:39 UTC
Can somebody reproduce this with current KDE 4.4?
Comment 13 Myriam Schweingruber 2010-03-18 22:18:02 UTC
Closing for lack of feedback. It certainly works fine here.