0002886: Elapsed time starts from 2 for some files

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

Project

Category

View Status

Date Submitted

Last Update

0002886

MPD

Input Plugins - File

public

2010-04-29 13:15

2011-03-19 21:21

Reporter

atler

Assigned To

cirrus

Priority

normal

Severity

minor

Reproducibility

always

Status

closed

Resolution

fixed

Platform

OS Version

Product Version

0.15.x

Target Version

Fixed in Version

git

Summary

0002886: Elapsed time starts from 2 for some files

Description

I'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 Information

Linux 2.6.33
mpd 0.15.8 (both ao and alsa outputs affected)

Tags

No tags attached.

Attached Files

Relationships

Notes
(0005777) Avuton Olrich (administrator) 2010-06-02 05:02	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.

(0005778) cirrus (administrator) 2010-06-02 07:47	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