I have a number of tracks where once played the last played time is not updated (this is not connected to bug 335763). The tracks used to update but I've played one track 3 times in the last 24 hours and it still has a last played date of Dec 2013 - and lastfm (I use the plugin) also isn't showing the track as played. Looking at the output from debug I see amarok: BEGIN: void EngineController::play(Meta::TrackPtr, uint, bool) amarok: BEGIN: void EngineController::stop(bool, bool) amarok: [EngineController] slotTrackFinishedPlaying( "calle ciega" - "Nueva Era" - "Nueva Era" , 0 ) amarok: [SqlRegistryP] obtained max_allowed_packet is "1048576" amarok: [lastfm] scrobble(): refusing track "/home/robert/Music/media-b/Music/Ilia/Musica/SalsaYMerengue/calle ciega - Daria mi vida merengue.mp3" - played time ( 251 * 0 s) shorter than 30 s amarok: END__: void EngineController::stop(bool, bool) [Took: 0.027s] The track properties aren't showing the length as zero (length is 4:11) and the progress bar moves normally during track play. The date on that mp3 (from ls -l) is back in 2007 so it doesn't appear to have changed. Looking further back in --debug there's lots of amarok: found 0 timecodes on this track is this the issue? I initially thought this might be a backend issue (having updated to kubuntu 14.04 between Dec 2013 and now) - in case that's still a possibility Phonon Version: 4.7.1 Phonon Backend: VLC (0.7.1) I can give more of the output from --debug if needed. The tracks where this behaviour happens are repeatable.
Just to make sure: that track is part of the collection and the file and location have write rights?
Yes it's in the local collection, I've got rwx permissions on that file and I've just created another (dummy) file in that directory and also successfully touched that mp3 file. I've just opened that mp3 in audacity and the track length is consistent with what amarok shows
Thank you for the fast feedback :)
Mind you, to be shown as played, you need to play more than 50% of the track length, so less than 30 seconds is not enough to increase the play count.
Though in this case I'd played all the track, the playedFraction parameter (of zero in slotTrackFinishedPlaying) appears to be incorrect. mutagen-inspect for this track gives a length of 253.74 that's 2 sec longer than 4m11sec that both amarok & audacity think (I've no idea whether this is relevant or not).
This bug also appears to be a problem with amarok's interaction with vlc, like bug 338029 if I use gstreamer the problem no longer occurs. Suggests these 2 are duplicates
(In reply to robert marshall from comment #6) > This bug also appears to be a problem with amarok's interaction with vlc, > like bug 338029 if I use gstreamer the problem no longer occurs. Suggests > these 2 are duplicates wasn't the other one only happening with aac files?
Though bug 338029 was only happening with aac and vlc - I think my comments about the stdout (mimetype audio/aac) there are irrelevant. This bug has some tracks not getting the last played time being updated, the other bug has all aac not being updated (and both only happen with vlc) so I think that one is contained within this bug.
*** Bug 338029 has been marked as a duplicate of this bug. ***
I've also encountered this bug with both 2.8.0 and the newer git version 3d549a32e1315e12af6663bdbc9c4c7fba883935. Same symptons as in the original report. Track gets played over and over but is never counted as played because played time is detected as too short. Even though the full track is played, for some reason playedFraction is 0. I noticed that for me this is only happening when playing from a dynamic playlist. Once I stop dynamic mode and clear the playlist, add the affected track back manually and then play it, everything works as expected.
(In reply to Heinz Wiesinger from comment #10) > ... > > I noticed that for me this is only happening when playing from a dynamic > playlist. Once I stop dynamic mode and clear the playlist, add the affected > track back manually and then play it, everything works as expected. Now that is definitely an important information, Robert, ca you confirm this is specific to the use of the dynamic playlist?
Interesting but I've not noticed it happening recently (and I almost always have dynamic mode enabled), the track I reported it for has a last played date of Nov 2016 which suggests it is now being updated. On my work install of amarok I can see this behaviour on certain tracks (predictable and always .ogg) but it doesn't happen on the home install I was wondering if it was something to do with the backends. (I've also moved machines at home from a 32 bit to a 64 bit install - as another data point, but work - where I can see it is a 64 bit install)
hm, there are a lot of things parsed by the backends, be this stream length or file type, but the "last played" part normally is a database item. Strange you have different results on different machines.
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Yes still happening - particularly with ogg format files
This is now fixed in the recent joe yasi builds
Reopening as I'm still seeing this, the problem (only noticed with ogg files) appears sporadically. I had a track 3 days ago marked as played - then - but today replaying it and other ogg files doesn't update the last played time.
*** Bug 488210 has been marked as a duplicate of this bug. ***
Git commit e3dd77951ea229a183b3e246ad29db0747c76e4a by Tuomas Nurmi. Committed on 19/06/2024 at 12:18. Pushed by nurmi into branch 'master'. Use our own progress for track if phonon reported position seems wrong At least phonon-vlc seems to commonly claim position is 0 when stopping playback / when backend prepares the next track to be played gapless. This causes the track progress on stop to be 0, which further causes the track scrobbling and playcount updates get skipped (at least sometimes), it seems. Related: bug 406701 M +2 -0 ChangeLog M +7 -1 src/EngineController.cpp https://invent.kde.org/multimedia/amarok/-/commit/e3dd77951ea229a183b3e246ad29db0747c76e4a