This is for Max OS 1.14.5 (Mojave) and I have both Java 12 and Java 1.8 installed. When SoftSqueeze was released Java was at 1.4, that is a real long time ago.I've found a fix for this that's a little involved. I think now will start looking deeper into the Mac Java environment on the client. I am attaching a few other decoded raw bitmaps captured from the grfe command while trying different fonts on the player (all looked bad on the player). The raw display bitmap (320x32 dot) being sent from LMS is this: Here is an example of what the player display looks like: The results indicate all the raw display bitmap data being sent from LMS is completely clean, for every available display font. Else if the bitmap from LMS is clean, it points to the player. My thinking was if the bitmap from the server looks messed up the same as the player, then LMS is the cause. I wrote a program to capture the raw bitmap data coming from LMS to SoftSqueeze ( slim protocol "grfe" command) and render it into a graphical image. I have found something new which is making me thing it's the player side (SoftSqueeze). rw-rw-r- 1 root admin 8248 threeline.3.font.bmp rw-rw-r- 1 root admin 8248 threeline.2.font.bmp rw-rw-r- 1 root admin 8248 threeline.1.font.bmp rw-rw-r- 1 root admin 13132 standard_n.2.font.bmp rw-rw-r- 1 root admin 9568 standard_n.1.font.bmp rw-rw-r- 1 root admin 13132 standard.2.font.bmp rw-rw-r- 1 root admin 9568 standard.1.font.bmp rw-rw-r- 1 root admin 3872 small.2.font.bmp rw-rw-r- 1 root admin 3872 small.1.font.bmp rw-rw-r- 1 root admin 3804 medium.2.font.bmp rw-rw-r- 1 root admin 3192 medium.1.font.bmp rw-rw-r- 1 root admin 4418 logoSB2.2.font.bmp rw-rw-r- 1 root admin 10096 light_n.2.font.bmp rw-rw-r- 1 root admin 9700 light_n.1.font.bmp rw-rw-r- 1 root admin 10096 light.2.font.bmp rw-rw-r- 1 root admin 9700 light.1.font.bmp rw-rw-r- 1 root admin 5640 large.2.font.bmp rw-rw-r- 1 root admin 8632 huge.2.font.bmp rw-rw-r- 1 root admin 8248 high.2.font.bmp rw-rw-r- 1 root admin 18940 full.2.font.bmp rw-rw-r- 1 root admin 135724 corefonts.bin rw-rw-r- 1 root admin 266 blockanimateSBG.1.font.bmp rw-rw-r- 1 root admin 856 blockanimateSB2.1.font.bmp rw-rw-r- 1 root admin 477820 FreeSans.ttf Could that be the issue?Ĭode: /MacMini:/Library/PreferencePanes/Squeezebox.prefPane/Contents/server/Graphics: which I think are all bitmapped fonts (.bmp files). PS: FWIW, when I go to LMS settings and select the player display options, Fonts, the only choices I see are ones like full_n, standard_n, high, light, threeline etc. I am not even sure whether I should be investigating the player side (SoftSqueeze) or this is an LMS server issue. The player is showing up in LMS as "Player Model: SoftSqueeze, Firmware: 2"Īny pointers would be appreciated. Differences in the Perl packages bundled with the OS? The LMS server is v7.9.0 running on OS X 10.11.2 - EN - utf8, x86_64 arch, perl 5.18.2. My hunch is that this problem could have crept in when I upgraded my Mac OS from Mavericks to El Capitan - a long time ago. The LMS Graphics directory seems intact with no font files missing or altered. I've confirmed it's not the missing Font::FreeType problem others have reported with display issues. And I've spent many hours already trying to get to the bottom of what the problem is. I know SoftSqueeze isn't supported any more but originally it worked fine, and apart from this, still continues to work like a charm in all other areas. I recently found the display on my software player (SoftSqueeze) has become completely garbled when rendered in small sizes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |