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
