2017-02-28 01:53 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002886MPDInput Plugins - Filepublic2011-03-19 21:21
Assigned Tocirrus 
Product Version0.15.x 
Target VersionFixed in Versiongit 
Summary0002886: Elapsed time starts from 2 for some files
DescriptionI'm using scmpc for last.fm scrobbling and I noticed it sometimes fails to detect song change event. Detection process involves polling every 1sec for server status and checking whether elapsed time is 0 or 1 (the problem with signal for song change in mpd api is that it does not detect playing the same song again). Unfortunately for some files (for me mostly flac files, but I managed to reproduce it for mp3 files also) elapsed time starts from 2. For test purposes I wrote simple program in C to poll status change every 100msec and start playing song few times. Here are results of elapsed time and few "starts":

(start playing from beginning)
Elapsed time: 0
Elapsed time: 2
Elapsed time: 3
(start playing from beginning)
Elapsed time: 2
Elapsed time: 3
Elapsed time: 2
Elapsed time: 3
(start playing from beginning)
Elapsed time: 1
Elapsed time: 2

As you can see in last pass elapsed time was 1 but only for 100msec so it's kind of race condition for scmpc to detect song change.
Additional InformationLinux 2.6.33
mpd 0.15.8 (both ao and alsa outputs affected)
TagsNo tags attached.
Attached Files




Avuton Olrich (administrator)

That behaviour is broken, imho. Polling shouldn't be encouraged, use of idle should. Furthermore, scmpc is completely unmaintained, I suggest use of mpdscribble and we close this bug.


cirrus (administrator)

Polling is broken, that's right so far - but still this bug report is valid, since switching to "idle" won't affect the result. I guess this is due to buffering; MPD checks which music chunks have been sent to the audio outputs, not which one is really being played.

However, this bug doesn't seem to important, since no client should rely on such close timings, it's no more than an minor inconvenience for the user. It will be fixed, but it's not top priority.

-Issue History
Date Modified Username Field Change
2010-04-29 13:15 atler New Issue
2010-04-29 13:15 atler Status new => assigned
2010-04-29 13:15 atler Assigned To => cirrus
2010-06-02 05:02 Avuton Olrich Note Added: 0005777
2010-06-02 05:04 Avuton Olrich Status assigned => feedback
2010-06-02 07:47 cirrus Note Added: 0005778
2010-06-02 16:06 Avuton Olrich Status feedback => assigned
2010-11-08 18:35 cirrus Status assigned => resolved
2010-11-08 18:35 cirrus Fixed in Version => git
2010-11-08 18:35 cirrus Resolution open => fixed
2011-03-19 21:21 Avuton Olrich Status resolved => closed
+Issue History