Bugzilla – Bug 4091
??? displayed instead of track date on Web UI and also date on SB/SS
Last modified: 2008-12-18 11:12:53 UTC
SlimServer Version: 6.5b2 - 9626 - Windows Server 2003 - EN - cp1251 Perl Version: 5.8.7 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt The proper fonts are installed; Unicode (cyrillic) information is displayed corectly both in Web UI and on the SS/SB. Except for the date: Here is what is shown in the WebUI (song info): ... File Length: 1,697,515 BytesBitrate: 615kbps CBR Sample Rate: 44.1 kHz Location: G:\Audio\Kenny Burrell - At The Five Spot Cafe (1959) [FLAC] {JRVG}\01 - Introduction by Kenny Burrell.flac (Download) Date Modified: ??????? 8. ???????? 2006, 17:41:14
Created attachment 1515 [details] Screenshot of Web UI
Created attachment 1516 [details] Screenshot of Softsqueeze
Yuly would it be possible for you to attach an affected track to the bug?
The second screen capture shows the DateTime screensaver, so it's not an audio file that is the problem. What is the language setting for Windows in this case? system time character set is most likely problem.
Thank you for noticing that, KDF!
The local time settings is set to Russian. The date in the system tray of the server is displayed also in Russian. However, the SlimServer is probably trying to display the date in Latvian - this was the setting of my system when I first installed the Slimserver on it (version 6.2 then). Since then I have changed the local time settings to Russian, but somehow the slimserver continued to display the latvian version of it. v6.2 and v6.3 managed to do it correctly. It was after I installed 6.5 that I started to get question marks. I have made a tests - just now changed the local time settings to English US and restarted the server - it had no effect. So the first question is - how do I make Slimserver forget whatever the date format was at the installation time, and read it again from the system?
Did you install an application to modify how the time is displayed? If so, perhaps it can be removed and re-installed. Is this a special version of Windows?
You have slimserver set to use EN, so most of the browser text will be english. Date Modified, however, would be somethign from the filesystem, so you would need the browser set to be able to display utf8. In the case of Firefox, this is under View->Character Encoding. For the player display, that's harder to explain as the required font is included and the windows builds should also have the required GD library for using the font. However, it may be an interraction problem between the EN server setting and the non-EN system setting. I don't know if the server is handling mixed character sets when the setitng is EN. I have a feeling that it does, which is why this is hard to explain.
Perhaps the required display font has actually gotten corrupted or deleted? You don't support this is yet another manifestation of bug 2475 do you?
c:\program files\slimserver\server\slim.exe --d_graphics that should confirm GD status, and the font loading. The 'Date Modified' issue alone could hint at bug 2475, but the DateTime would seem different. However, this is running through the utfdecode_locale() function. I'm curious to know if this date formatting problem also occurs with hardware. I'm not sure how directly teh fonts are handled by softsqueeze. It may be some sort of emulation that isn't working right.
It looks like my problem lies somewhere in the system configuration and the way slimserver is installed. I stopped the server (it runs as a service), and started it manually with the d_graphics. The output is below, but interesting thing that after that the date showed up correctly in both WebUI and softsqueeze! C:\Program Files\SlimServer\server>Slim --d_graphics 2006-09-13 09:04:26.0333 fontfile entry: blockanimateSB2.1.font.bmp 2006-09-13 09:04:26.0416 fontfile entry: blockanimateSBG.1.font.bmp 2006-09-13 09:04:26.0435 fontfile entry: full.2.font.bmp 2006-09-13 09:04:26.0673 fontfile entry: high.2.font.bmp 2006-09-13 09:04:26.0783 fontfile entry: huge.2.font.bmp 2006-09-13 09:04:26.0891 fontfile entry: large.2.font.bmp 2006-09-13 09:04:26.0954 fontfile entry: light.1.font.bmp 2006-09-13 09:04:26.0993 fontfile entry: light.2.font.bmp 2006-09-13 09:04:26.1015 fontfile entry: logo.font.bmp 2006-09-13 09:04:26.1128 fontfile entry: medium.1.font.bmp 2006-09-13 09:04:26.1206 fontfile entry: medium.2.font.bmp 2006-09-13 09:04:26.1227 fontfile entry: small.1.font.bmp 2006-09-13 09:04:26.1311 fontfile entry: small.2.font.bmp 2006-09-13 09:04:26.1454 fontfile entry: standard.1.font.bmp 2006-09-13 09:04:26.1475 fontfile entry: standard.2.font.bmp 2006-09-13 09:04:26.1602 fontfile entry: threeline.1.font.bmp 2006-09-13 09:04:26.1678 fontfile entry: threeline.2.font.bmp 2006-09-13 09:04:26.1819 fontfile entry: threeline.3.font.bmp 2006-09-13 09:04:26.2644 Retrieving font data from font cache: C:\Program Files\ SlimServer\server\Cache\fonts.bin 2006-09-13 09:04:26.2853 Trying to load GD Library for TTF support: ok 2006-09-13 09:04:26.3133 Using TTF for Unicode on Player Display. Font: [C:\Prog ram Files\SlimServer\server\Graphics\arialuni.ttf] Then I stopped it again, and started it normally, through the tray icon. The date returned back to the ???. What should I do next? Probably, I would need to start the service with some debug options initially, but how do I do it on Windows? I tried to add startup parameters in the service properties, but this does not work.
KDF likes to look at the debug options from the command line, but the way support usually does it is to have the user go to the Slimserver web interface -> Server Settings -> Debugging, and check the box(es) for the logs you want to see, in this case d_graphics. Then, to view the log, direct your browser to http://localhost:9000/log.txt
Chris, the problem is that the relevant info gor d_graphics in this case happens during startup. By the time the user enables debug options from the web UI, it's too late. I don't know how (if such a way exists) to pass debug options to the windows service for startup. If that can be done, then the log.txt view would be perfect. There is an open request for persisting debug options across restarts, which would be one thing that would help here.
Ah I didn't grasp that message only appears at startup :(
Well, I have managed to make the service start with --d_graphics, by modifying the registry (Hkey_local_machine\system\controlset001\services\slimsvc\imagepath="C:\Program Files\SlimServer\server\slim.exe" --d_graphics) I have verified this by looking at the slim service - it does take the path from the registry. However, even now the log.txt is empty. Probably the web log mechanism isn't ready by the very startup time?
in that case, try adding "--logfile c:\mylog.txt" to the end of that registry entry. That should then have the output in c:\mylog.txt.
Problem solved! First, adding --logfile option still did not produce any output. However, it appeared to me that the difference between the automatic and manual startup was in user credentials: service was using a local system account, and manually the service was started under administrator. So I tried to configure the service to use the administrator account and bingo! date was correct. Next I discovered a nice checkbox in Windows Regional settings, that applies changes to all accounts, including local one. I did that, and now slimserver starts under local account and shows date correctly. So now the system displays date correctly - when computer date is set to russian. This solves my problem. But in general the problem is still there - when computer date is set to latvian, Slimserver gives ??? . This was my next test - I set up the system time format to latvian (including local account), and started the server. The debug output looks normal: C:\>"C:\Program Files\SlimServer\server\slim.exe" --d_graphics 2006-09-14 00:32:09.3333 fontfile entry: blockanimateSB2.1.font.bmp 2006-09-14 00:32:09.3484 fontfile entry: blockanimateSBG.1.font.bmp 2006-09-14 00:32:09.3523 fontfile entry: full.2.font.bmp 2006-09-14 00:32:09.3636 fontfile entry: high.2.font.bmp 2006-09-14 00:32:09.3743 fontfile entry: huge.2.font.bmp 2006-09-14 00:32:09.4019 fontfile entry: large.2.font.bmp 2006-09-14 00:32:09.4164 fontfile entry: light.1.font.bmp 2006-09-14 00:32:09.4287 fontfile entry: light.2.font.bmp 2006-09-14 00:32:09.4329 fontfile entry: logo.font.bmp 2006-09-14 00:32:09.4422 fontfile entry: medium.1.font.bmp 2006-09-14 00:32:09.4499 fontfile entry: medium.2.font.bmp 2006-09-14 00:32:09.4541 fontfile entry: small.1.font.bmp 2006-09-14 00:32:09.4598 fontfile entry: small.2.font.bmp 2006-09-14 00:32:09.4665 fontfile entry: standard.1.font.bmp 2006-09-14 00:32:09.4707 fontfile entry: standard.2.font.bmp 2006-09-14 00:32:09.4811 fontfile entry: threeline.1.font.bmp 2006-09-14 00:32:09.4973 fontfile entry: threeline.2.font.bmp 2006-09-14 00:32:09.5112 fontfile entry: threeline.3.font.bmp 2006-09-14 00:32:09.5768 Retrieving font data from font cache: C:\Program Files\ SlimServer\server\Cache\fonts.bin 2006-09-14 00:32:09.6074 Trying to load GD Library for TTF support: ok 2006-09-14 00:32:09.6116 Using TTF for Unicode on Player Display. Font: [C:\Prog ram Files\SlimServer\server\Graphics\arialuni.ttf] ... ,but the date is againg ???
I admit I don't know much Latvian. :) Does it also use the Cyrillic alphabet or does it have other characters that might not be in our unicode font?
Created attachment 1540 [details] date in latvian
I have attached the screenshot of what date in latvian looks like. It uses mainly latin characters; some can be accented (or whatever its called). In v6.3 the latvian date was displayed OK, except for those characters - they were substituted by smth else I believe.
All those characters should definitely be in the font.
If I set Windows codepage ControlPanel->RegionalAndLanguageOptions->Advanced->LanguageForNon-UnicodePrograms to Hebrew (cp1255), the date/time screenserver shows up with question marks in some parts If I set it to English (cp1252), the date/time screenserver is ok I have the arialuni.ttf under graphics and all is well font-wise except for this bug
I've created a patch for bug 2726 (https://bugs-archive.lyrion.org/show_bug.cgi?id=2726) which will allow to overwrite the system locale with the language you selected in SlimServer. Does this change the behaviour in your case?
Created attachment 2005 [details] Log from the manual scanner run on the test dir
Comment on attachment 2005 [details] Log from the manual scanner run on the test dir Wrong attachement for a wrong bug id! please ignore
Yuly, Michael's change has been checked in which we hope will fix the problem. Have you checked this behavior lately?
(In reply to comment #26) > Yuly, Michael's change has been checked in which we hope will fix the problem. > Have you checked this behavior lately? I don't know how is this supposed to work now. The Slimserver was set to English; locale on the server was set to English; the date on SB3 was displayed in English. Now I have changed the system locale to Russian, and restarted the Slim server. Date on SB3 is still in English. So far so good (if I got it correctly, the patch makes the date follow the language setting in the Slimserver, and not the system locale). Next I have changed the Slimserver interface to Hebrew and restarted it. The UI and SB menus have changed to Hebrew, but the date on the Sb3 is stil in English. Is this how it was supposed to work? Running SlimServer Version: 6.5.5 - 13817 - Windows Server 2003 - EN - cp1251 Server IP address: 192.168.11.6 Perl Version: 5.8.8 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt
I would say that setting the UI to Hebrew and getting a clock display in English is not right. Note to myself: make sure the Hebrew clock strings have been localized. See if the clock in other languages still appears as English.
Chris - there's nothing to be translated. The date/time string is delivered by the operating system. Yuly - after you've changed your system's locale to Hebrew, does it display dates in Hebrew in eg Windows task tray?
...and do you still see the question marks in the web interface?
Ah that's good to know; thanks Michael.
(In reply to comment #29) > Chris - there's nothing to be translated. The date/time string is delivered by > the operating system. > Yuly - after you've changed your system's locale to Hebrew, does it display > dates in Hebrew in eg Windows task tray? It's easier for me to try with russian on this system. The locale is currently set to russian (was english before). Date in the system tray is in russian. The server was restarted afterwards. In web ui, the dates are in english, as before the locale change. Same with SB/SS date display. It looks to me that the server remembers the locale settings from the first install, and keeps them.
Make sure you set Russian (or whatever you expect) as the default language for your system. There's a small checkbox on somewhere in that Windows dialog.
It seems to work correctly now, except for the Hebrew case. The date in SB is displayed in the same language that I select inside Slimserver (Michael's patch). This works for every language, except Hebrew (probably, date in Hebrew is not implemented yet). The original issue (question mars) is long gone. VERSION INFO SlimServer Version: 6.5.5 - 15454 - Windows Server 2003 - EN - cp1251 Server IP address: 192.168.11.6 Perl Version: 5.8.8 MSWin32-x86-multi-thread MySQL Version: 5.0.22-community-nt
Thanks for the feedback. I remember having seen other issues with Hebrew on a system which was installed in a non-Hebrew language (EN-US in that other case). But which did not show up on 100% Hebrew systems. I don't know exactly what the problem is though. Just stop switching between Russian, English, Hebrew and Letvian ;-). Thanks for the feedback.
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.