Re: [Musicpd-dev-team] audio format information timing with idle
On 2013/01/07 14:11, Timur Aydin t...@taydin.org wrote: Hi, I have an application that listens to mpd status changes using idle and writes the current mpd status onto a hardware display. After issuing a play command, mpd immediately notifies the player status change. At that point, I read the status of the player, but the status does not include any audio format information. But mpd just told me that it started playing. If I wait 1 second after receiving the player status change notification, then the status includes the audio format information. I have tested with both internet radio stations and with stored audio files, same result. I think that's a bug, and the event should be delayed until MPD knows all the details. Please write a ticket. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] audio format information timing with idle
On 01/07/13 15:54, Max Kellermann wrote: I think that's a bug, and the event should be delayed until MPD knows all the details. Please write a ticket. Hello Max, I have entered a bug report into mantis. I will work on this and provide a patch for review. -- Timur -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] audio format information timing with idle
On 01/07/13 16:13, Timur Aydin wrote:
Hello Max, I have entered a bug report into mantis. I will work on this
and provide a patch for review.
Max, it looks like the spot where the audio format is available is in
the player_check_decoder_startup function in player_thread.c. The patch
below causes an additional changed: player notification:
@@ -376,6 +376,8 @@ player_check_decoder_startup(struct player *player)
player-play_audio_format = dc-out_audio_format;
player-decoder_starting = false;
+idle_add(IDLE_PLAYER);
+
if (!player-paused !player_open_output(player)) {
char *uri = song_get_uri(dc-song);
g_warning(problems opening audio device
This, of course, results in two consecutive changed: player
notifications. The first signals that play has been initiated, and the
second signals that decoding is now being done and that metadata
information is available.
Actually, both of these statuses are valid and valuable. The first can
be interpreted and displayed as a buffering... and the second can be
displayed as playing. So it seems it would be better if we add a new
player state called buffering. This way, a client can
deterministically know what MPD is doing and display its status
accordingly. Let me know what you think about this...
--
Timur
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
___
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
Re: [Musicpd-dev-team] audio format information timing with idle
On 2013/01/07 21:00, Timur Aydin t...@taydin.org wrote: Actually, both of these statuses are valid and valuable. The first can be interpreted and displayed as a buffering... and the second can be displayed as playing. So it seems it would be better if we add a new player state called buffering. This way, a client can deterministically know what MPD is doing and display its status accordingly. Let me know what you think about this... Yes, that sounds like a good idea. Though there should not be a special state buffering, as this reveals too much of MPD's internals (which may change at any time). It's enough to be aware that while MPD starts playback, the audio format may not be available until playback initialization has completed. Clients should also not rely on getting two notifications, because the two PLAYER events will be merged when the client is slow. That's a feature, not a bug. If you don't ever see the state playing, but no audio format yet, that's perfectly ok. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
