Announce: Whitebear Media Server v2.2 Released

[)p(]

Ok. Now I understand you.


From what you say, you are referring to case D). => Is that correct?

Correct. The jrmc library. Using Play To a SqueezePlayer (by Whitebear) no artwork. Using Play To a SqueezePlayer (by LMS) yes artwork.

So there seems to be slight difference how lms and whitebear handle the artwork when they play to a sqeeuzeplayer as a renderer.

It would be great if whitebear could also handle nonembedded artwork like lms. But its not a big issue. I can embed them. Its way more important that whitebear seems way more stable in going from song to the next song then lms.

[AndrewFG]

So there seems to be slight difference how lms and whitebear handle the artwork when they play to a sqeeuzeplayer as a renderer.

Correct.

The reason is that Whitebear is a stand alone external application, that can only talk to SBS/LMS via its open public interface, and this interface has no command for displaying album art when playing tracks from a third party (non SBS/Whitebear) server. On the other hand the LMS DLNA plug-in is installed as an integrated internal part of the server code, and it can therefore use proprietary function calls to access the internal server code and thus can display album art for third party tracks.

In theory I could also create a plug-in that would enable Whitebear to access the proprietary internal server code, but to be honest it is not that high on my to-do list (sorry).

[Aztek]

Installed onto my low spec Win 7 desktop running Squeezeboxserver v7.4.1. Runs fine through my WDTVLive box and my PS3. Only thing I noticed was that the first 10 seconds of the first .flac file stuttered. After that initial stutter - that file and all following .flac files in that album played flawlessly. No probs with mp3's.

Nice job. Keep up the good work.

Merry Xmas
Mike

[AndrewFG]

... my low spec Win 7 desktop
... the first 10 seconds of the first .flac file stuttered. After that initial stutter - that file and all following .flac files in that album played flawlessly.

The former would probably explain the latter...

Probably either your renderer or your control point don't support flac natively and this thus requires transcoding into raw pcm (pcm is the baseline lossless format that all UPnP/DLNA devices have to support). The first play of the first flac track has to load up the transcoder application image before doing the actual transcoding, and this consumes a bit more resources. Whereas for subsequent plays, the transcoder application image is already "warm loaded", so it will get going faster.

In other words, you are quite close to the borderline of what your PC can handle, so you may want to try stopping other non essential applications when you want to play music.

[AndrewFG]

Correct. The jrmc library. Using Play To a SqueezePlayer (by Whitebear) no artwork.

Hi )p(

Can you please let me know what track format are you Playing To the Squeezeplayer?
Is JRMC set to "always convert" or "don't convert" to mp3 or alternatively to raw/l16/pcm (lossless)?

[)p(]

Hi )p(

Can you please let me know what track format are you Playing To the Squeezeplayer?
Is JRMC set to "always convert" or "don't convert" to mp3 or alternatively to raw/l16/pcm (lossless)?

Hi Andrew,

JRMC is set to "never convert" for audio. I only send flac and mp3 to the squeezebox devices from jrmc.

[AndrewFG]

JRMC is set to "never convert" for audio. I only send flac and mp3 to the squeezebox devices from jrmc.

Do your flac or mp3 tracks actually contain the album art embedded as tags in the files themselves? Or do you have something like a "cover.jpg" file located in your album folders?

[)p(]

Do your flac or mp3 tracks actually contain the album art embedded as tags in the files themselves? Or do you have something like a "cover.jpg" file located in your album folders?

Some may have embedded ones but they all have them as separate files. That is what I have jrmc set to when importing artwork. They are put by jrmc in the album folder with the music files as "Folder.jpg".

UPDATE: I embedded a cover for a flac album in the individual files and it did also not show on the touch with whitebear.
UPDATED2: I embedded some mp3 and they work when embedded. Also I have to investigate further but its seems like whitebear won't play files from jrmcs library that are on a shared drive accessed by a shared drive letter. (I have some music in d:\music that is referenced in the jrmc library as x:\ It works when I add it to the library as \\SERVER\music\ )

[AndrewFG]

UPDATE: I embedded a cover for a flac album in the individual files and it did also not show on the touch with whitebear.
UPDATED2: I embedded some mp3 and they work when embedded.

Good news! This is a very interesting observation! Thank you.

Obviously when JRMC is streaming MP3 files (mediated by Whitebear) to a Squeezeplayer, it is sending the original file, which includes the embedded native ID3v2 tags. And in such cases it seems SBS is able to parse the ID3v2 tags on the fly and update its player meta data including album art.

But apparently when JRMC is streaming FLAC files (mediated by Whitebear) to a Squeezeplayer, something is going amiss. There could be two possible things going on:

1) JRMC may be transcoding the FLACs, and streaming them in PCM form to Whitebear, and then Whitebear may be trancoding them back to FLAC for SBS and the player. (I know this sounds odd. Don't ask.) But anyway in this case it would be no big surprise that the PCM file would have no metadata in it, and so meta data (including art) would/could not be supplied further to the player.

or,

2) JRMC may be sending the FLACs as they are, including their embedded native FLAC tags. But perhaps SBS may not able to read the FLAC tags on the fly in the same way that it can read ID3v2 tags.

As mentioned before, in LMS own UPnP/DLNA implementation they built in an internal special protocol handler within the plug-in that can handle both cases 1) and 2) -- but unfortunately I am not able to go down that road with Whitebear.

However I think I may have found an alternate way for Whitebear to restore the missing meta data (including art) by using ICY tags. This should work at least for the case 1) and it might even work for case 2). However before I proceed with developing code, it would certainly help me to know which of case 1) or 2) is actually happening in your case. => Could you please turn on logging of "Http Server" in Whitebear, and record what happens when you do a "Play To" command from JRMC?

Also I have to investigate further but its seems like Whitebear won't play files from jrmcs library that are on a shared drive accessed by a shared drive letter. (I have some music in d:\music that is referenced in the jrmc library as x:\ It works when I add it to the library as \\SERVER\music\ )

This sounds like a problem in JRMC, and not in Whitebear. But again, if you do a log of "Http Server" in Whitebear for such a (failed) transaction, I may be able to say more about this after.

[)p(]

Good news! This is a very interesting observation! Could you please turn on logging of "Http Server" in Whitebear, and record what happens when you do a "Play To" command from JRMC?

Ok here are some logs. just let me know if you need more.

1) mp3 with folder.jpg artwork. No artwork on sbtouch.
http://www.i-modernist.com/temp/whit...mp3 folder.txt

2) flac with folder.jpg artwork. No artwork on sbtouch.
http://www.i-modernist.com/temp/whit...lac folder.txt

3) flac with embedded artwork. No artwork on sbtouch.
http://www.i-modernist.com/temp/whit...lac inside.txt

note: flac plays ok but the progress bar in jrmc keeps jumping back to zero.

This sounds like a problem in JRMC, and not in Whitebear. But again, if you do a log of "Http Server" in Whitebear for such a (failed) transaction, I may be able to say more about this after.

Playing mp3 with embedded artwork with network path set to x: from original local d: does not work:
http://www.i-modernist.com/temp/whit...twork path.txt

Thanks for looking into this