@ckyang wrote:
After replace firefly.exe:
2006-08-21 15:03:53 (ad2cf70a): Starting with debuglevel 0
2006-08-21 15:03:53 (ad2cf70a): Error loading plugin C:Prog/rsp.dll: ?????????w???????C
2006-08-21 15:03:53 (ad2cf70a): Error loading plugin C:Prog/w32-event.dll: ?????????w???????C
2006-08-21 15:03:53 (ad2cf70a): Error loading plugin C:Prog/ssc-ffmpeg.dll: ?????????w???????C
2006-08-21 15:03:53 (ad2cf70a): Error loading plugin C:Prog/ssc-wma.dll: ?????????w???????C
2006-08-21 15:03:53 (ad2cf70a): Starting rendezvous daemon
2006-08-21 15:03:53 (ad2cf70a): db_sqlite2_open: unable to open database: C/songs.db (C/songs.db)
2006-08-21 15:03:53 (ad2cf70a): Error opening db: Misc SQL Error: unable to open database: C/songs.db
Was this from a working installation of current nightlies? Because it doesn’t look right. Did it start and run properly (aside from not finding some files) when you ran it before you copied over the .exe?
So I copy C:Program FilesFirefly Media Serverplugins*.* to C:Prog
But still cannot scan songs.
Again, this doesn’t look like a multi-byte issue, this looks like a configuration issue.
Try installing the nightly as normal. Start firefly, make sure it works. Once you have that working, stop the server, drop the .exe from the zip file on top of the existing firefly.exe (not in a new directory — overwrite the executable that you just installed from the nightly). See if that works.
I’m almost certain it will.
1. Firefly is built with multibyte character set. So when TChinese XP read file with Chinese filename, it will get MBCS (Multi-byte character set) encoded filename.
2. In this function os_readdir_r(), it uses UTF8 to UTF16 conversion. It may cause wrong conversion.
3. His suggestion is to use Windows API “MultiByteToWideChar” instead of UTF8-to-UTF16.
Hrm. I tend to not want to, as it is not portable to non-windows systems. Also, I’m not sure that this conversion is wrong.
The os_readdir_r functions are all all in the os-win32-u.c file, with is compled with UNICODE support turned on. Which means I should get filenames etc in UTF-16, not multibyte. A UTF-16 to UTF-8 conversion (and back again) shouldn’t lose any data, as both utf-8 and utf-16 can represent the whole unicode set, including those characters above the BMP.
It still might be the case that the log file prints out crap, since thats all utf-8, and your text editor might assume either codepage or utf-16, but that’s just the log file. Internally, all the file open, stat, and other operations are done with utf-16 filenames, using the windows W functions.
It’s possible that there is still a function somewhere that is mangling filenames, but I thought I got the last one last night.
In fact, I was able for the first time last night to index songs with traditional chinese file names using the same binary I uploaded to you.
So I’m thinking maybe it’s a configuration issue.