kolossos4730 wrote: > Another question for Philippe, > > I often listen to Radio Paradise. Streaming works great for the 320 AAC > stream with codecs set to 'aac,pcm,mp3' and uncompressed format set to > 'wav' (no transcoding), but track information does not update after a > track change. The LMS web interface and JiveLite do pickup track changes > and even display the correct cover art. > > If I stop and start sq2upnp the current playing track info is displayed > and this is also visible in the logs. > > It's more a cosmetic thing but maybe there is an easy fix to have the > correct track info displayed while playing radio streams, but I wouldn't > put it high on your priority list ;)
This is unfortunately a consequence of using 'wav' as a format for some players. Let me try to explain why. During playbacks - LMS start sending audio data (from a track) to sq2u - sq2u starts buffering that data - as soon as 'enough' data has been received, sq2u starts sending these data to the player - the player itself buffers "enough" data and then starts playing audio all these steps continue in parallelel, until - LMS closes the connection with sq2u, that indicated that all audio data have been sent - when sq2u has sent all the *buffered* data to the player, it closes the connection to tell it that all have been sent - sq2u then tells LMS that it is ready to buffer the next track - if LMS has another track, the process described above starts again, but this time sq2u tells the player: 'this is for the 'next' track, whenever you finish the current one - the player continues to play until it has finished the current one, at which point it switches to the "next one" - sq2u detects that switch and tells LMS that the "next" track has started on the player, and the web UI is now synchronized The format between LMS and sq2u is one of the accepted ones in the "codecs" sections and normally, sq2u forward these data almost untouched (almost ...). When LMS sends uncompressed data to sq2u (aic or pcm - this in fact exactly the same, just a different byte order), there are 'raw' data: no header, nothing. In that case sq2u can wrap these into a wav or aiff format as some player do not accept 'raw' data. And this is where the pain is WAV or AIFF format are not really made to be streamed, they require a header that indicates the size of the whole file that will be transmitted. LMs never indicates the size of the audio data it will transmit (in fact it does not know in advance). So, for that special case, I have to cheat and create a 'fake' WAV or AIFF header with a gigantic file length. When I have received all data fro LMS (see process above), I close the connection with the player and, normally, even if he was expecting that "gigantic amount of data", he considers that this is the end of the stream, so he'll play what he bas buffered so far and then will move to the next track (if any sent by sq2u). Unfortunately, some players, although they happily receive the "next track" data from sq2u, they consider that these data are part of the expected "gigantic size", so they do not tell sq2u that they have moved track. Consequence are various, includig that sq2u cannot report to LMS the change and/or the player does not udpate its display witht the "next track" metadata. So far, I do not have a good solution against that, hence avoind the usage of wav and aiff between sq2u and the player is the best solution. FOr that, either have LMS transcoding to flac, or if your player supports "raw" uncompressed, only enable that LMS 7.7.2 - 5 radio, 3 Boom, 4 Duet, 1 Touch, 1 SB2. Sonos 2xPLAY:1, PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBMC, Foobar2000, XBoxOne (sort of) ------------------------------------------------------------------------ philippe_44's Profile: http://forums.slimdevices.com/member.php?userid=17261 View this thread: http://forums.slimdevices.com/showthread.php?t=102496 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
