When calling Amarok via the command line with amarok --queue <url>, it just appends given urls to the playlist. Reproducible: Always Steps to Reproduce: 1. Call amarok with amarok --queue <url> Actual Results: The current behaviour apparently is just a copy of the --apend (-a) option. Expected Results: I expect Amarok to: 1) look for the actual song/url on the current playlist, or appending that song to the playlist if not found; and 2) queue that song The behaviour should be OK for some situations, but it's broken for most of them, like if the playlist is automatically sorted or the track order is random, it's basically useless, as the appended song will not be the "next in line".
I'm working on this bug.
Actually, according to in-source documentation: Append = 1, ///< inserts media after the last item in the playlist Queue = 2, ///< inserts media after the currentTrack Unique = 16, ///< don't insert anything already in the playlist But the this Unique enum doesn't seem to be used, should I just accept a -unique argument as well?
Thanks Anmol for working on this bug! Just dropping a wild thought here: why is the "Queue" argument inserting media after the currentTrack instead of using the built-in queuing system? As a user, when I read "queue" docs, I expect it to really use that feature as I have the auto-sorting thing, which screws up the insertion order as far as playback concerns.
You're welcome :) And as for your question, I believe that is the current behavior, the inserted tracks should be sorted. Did you check it?
I've looked a bit into this bug. It's a regression that has been there for a while, and it does not only affect command line functions. The whole append-and-play logic is broken for any media that does /not/ come from the "Local Collection" tab. If you double-click on a file in the "Files" tab it doesn't play, and it also doesn't work for radio streams.
Double clicking on a file from the Local Collection also just appends it to the playlist, though looking at the code, it is apparently supposed to append and play. I might not be able to do much for now though, practical exams and all at college.
Here we can see why it's not playing. The URL we put into EngineController is empty: amarok: [Playlist::Controller] engine playing?: false amarok: BEGIN: void Playlist::Actions::play(const int) amarok: BEGIN: void Playlist::Actions::play(const quint64, bool) amarok: BEGIN: void EngineController::play(Meta::TrackPtr, uint) amarok: BEGIN: void EngineController::stop(bool, bool) amarok: [EngineController] slotTrackFinishedPlaying( "Armin van Buuren" - "Mirage" - "Coming Home" , 0.00673421 ) void Phonon::MediaObject::setCurrentSource(const Phonon::MediaSource&) 5 QUrl( "" ) "" amarok: END__: void EngineController::stop(bool, bool) [Took: 0.008s] amarok: [EngineController] play: bounded is QObject(0x0) current "04 The Last Rose Of Summer.mp3" amarok: [EngineController] Just a normal, boring track... :-P amarok: BEGIN: void EngineController::playUrl(const KUrl &, uint) amarok: [EngineController] URL: KUrl("") "" amarok: [EngineController] Offset: 0 void Phonon::MediaObject::setCurrentSource(const Phonon::MediaSource&) -1 QUrl( "" ) "" Trying to set an invalid MediaSource -> ignoring. amarok: END__: void EngineController::playUrl(const KUrl &, uint) [Took: 0s] amarok: END__: void EngineController::play(Meta::TrackPtr, uint) [Took: 0.008s] amarok: END__: void Playlist::Actions::play(const quint64, bool) [Took: 0.008s] amarok: END__: void Playlist::Actions::play(const int) [Took: 0.008s]
It seems to try to play the track before it's loaded. Playing from the FileView works if you use BlockingLoading for the directory loader. So maybe we can introduce a cachedUrl?
@Anmol: Yep, that could be the problem. Matej has more clue about this code than me, though, let's ask him. @Matej: Do you have an idea why this happens? If the bug report is unclear, let us know.
Turns out there is already a cached url field, but it's not being used: /* don't return d->url here, it may be something like * amarok-sqltrackuid://2f9277bb7e49962c1c4c5612811807a1 and Phonon may choke * on such urls trying to find a codec and causing hang (bug 308371) */
(In reply to comment #5) > The whole append-and-play logic is broken for any media that does /not/ come > from the "Local Collection" tab. If you double-click on a file in the > "Files" tab it doesn't play, and it also doesn't work for radio streams. Mark, this is an entirely different (but existing) problem. The cause is introduction of MetaProxy::Track a year ago so that track loading is not blocking the UI. The solution is to introduce some RAII class (perhaps DelayedPlayer?) to watch on a Meta:Proxy track and play it once it becomes playable (with some timeout, 5 or 10 seconds).
Reverting to the original and more accurate title. (was changed by Myriam after the bug was reported to something I believe is misleading)
(In reply to comment #11) > The solution is to introduce some RAII class (perhaps > DelayedPlayer?) to watch on a Meta:Proxy track and play it once it becomes > playable (with some timeout, 5 or 10 seconds). So we create this DelayedPlayer every time the EngineController receives a Proxy Track with a blank playable url?
(In reply to comment #13) > So we create this DelayedPlayer every time the EngineController receives a > Proxy Track with a blank playable url? Nonono, just the method that calls trackForUrl() and immediately plays it (command line handling) should use DelayedPlayer. (which should be coded in a way that it plays the track immediately if it is already playable)
Git commit ecf6557cd611d442653719a266ca304aff2f6e14 by Matěj Laitl. Committed on 12/05/2013 at 00:30. Pushed by laitl into branch 'master'. PlaylistController: fix inability to play just loaded tracks ...that was caused by asynchronism of playlists and MetaProxy::Tracks. Now that we have TrackLoader which will magically solve all our problems. :-) This fixes Amarok not playing tracks passed to it via command line. BUGFIXES: * Fix `amarok --play file.mp3` option didn't actually start playback. @Anmol, now you can fix the "core" part of the bug 317385 as I outlined in http://git.reviewboard.kde.org/r/110362/ (please reopen the review). @Ralf, this is the "recommended" way to handle asynchronism in tracks and playlists now. CCMAIL: Chris <cjd@internode.on.net> DIGEST: Amarok fixes playing of tracks passed on command line M +1 -0 ChangeLog M +56 -31 src/playlist/PlaylistController.cpp M +2 -1 src/playlist/PlaylistController.h http://commits.kde.org/amarok/ecf6557cd611d442653719a266ca304aff2f6e14
(In reply to comment #15) > @Ralf, this is the "recommended" way to handle asynchronism in tracks > and playlists now. Oh, this should have been @Markey, too furious when writing commit message.
Git commit 6a3f1c67f761803479f87a3080415057e61c49be by Matěj Laitl. Committed on 16/05/2013 at 16:46. Pushed by laitl into branch 'master'. Playlist{Actions,Controller}: refactor code, fix queueing The actual fix for bug was to remove the isPlayable() check in TrackNavigator, however this fixes more potential problems (like the queueing being affected by the current playlist filter) and cleans up the code. BUGFIXES: * Fix `amarok --queue` which didn't actually queue the tracks. FIXED-IN: 2.8 M +1 -0 ChangeLog M +13 -11 src/playlist/PlaylistActions.cpp M +12 -2 src/playlist/PlaylistActions.h M +44 -64 src/playlist/PlaylistController.cpp M +1 -13 src/playlist/navigators/TrackNavigator.cpp M +0 -1 src/playlist/navigators/TrackNavigator.h http://commits.kde.org/amarok/6a3f1c67f761803479f87a3080415057e61c49be
Thanks for fixing this :) Sorry for not getting to it sooner.