1696 – and extended characters in media path

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #1987
    Anonymous
    Inactive

    Hello, everyone.

    I usually run a recent nightly in my system, and (as a whole) have had no serious problems.

    Now I have the feeling that 1696 has stopped working. I’m quite sure that it *did* work for some tme, and I’ve made no significant changes in my computer (… that I am aware of, and I have certainly not made any to Firely configuration). But for the last few days the server does not seem to “find” my music files. This is the last log:


    Log file: firefly.log

    2007-11-28 18:12:51 (8b0900a3): Firefly Version svn-1696: Starting with debuglevel 2
    2007-11-28 18:12:51 (8b0900a3): Plugin loaded: w32-event/svn-1696
    2007-11-28 18:12:51 (8b0900a3): Plugin loaded: ssc-wma/svn-1696
    2007-11-28 18:12:51 (8b0900a3): Plugin loaded: ssc-ffmpeg/svn-1696
    2007-11-28 18:12:51 (8b0900a3): Plugin loaded: rsp/svn-1696
    2007-11-28 18:12:51 (8b0900a3): Plugin loaded: daap/svn-1696
    2007-11-28 18:12:51 (8b0900a3): Starting rendezvous daemon
    2007-11-28 18:12:51 (8b0900a3): Building drive mapping table from C:Program FilesFirefly Media Servermapping.ini
    2007-11-28 18:12:51 (8b0900a3): Error: enum_begin failed (error 1): Misc SQL Error: no such table: config
    2007-11-28 18:12:51 (8b0900a3): Can't get db version. New database?
    2007-11-28 18:12:51 (8b0900a3): Initializing database
    2007-11-28 18:12:51 (8b0900a3): Error: enum_begin failed (error 1): ?
    2007-11-28 18:12:51 (8b0900a3): Error: enum_begin failed (error 1): ?
    2007-11-28 18:12:51 (8b0900a3): Full reload...
    2007-11-28 18:12:52 (8b0900a3): Starting mp3 scan
    2007-11-28 18:12:52 (8b0900a3): iconv error: unknown (0)
    2007-11-28 18:12:52 (8b0900a3): Starting playlist scan
    2007-11-28 18:12:52 (8b0900a3): Updating playlists
    2007-11-28 18:12:52 (8b0900a3): Scanned 0 songs in 0 seconds
    2007-11-28 18:12:52 (8b0900a3): Starting web server from C:Program FilesFirefly Media Serveradmin-root on port 9999
    2007-11-28 18:12:54 (8b0900a3): Registering rendezvous names
    2007-11-28 18:12:55 (8b0900a3): Serving 0 songs. Startup complete in 3 seconds
    2007-11-28 18:13:41 (912ac5ff): Thread 0: Entering ws_returnerror (302: Moved)
    2007-11-28 18:13:57 (8b0900a3): Rescanning database
    2007-11-28 18:13:57 (8b0900a3): iconv error: unknown (0)
    2007-11-28 18:13:57 (8b0900a3): Starting playlist scan
    2007-11-28 18:13:57 (8b0900a3): Updating playlists
    2007-11-28 18:13:57 (8b0900a3): Scanned 0 songs (was 0) in 0 seconds
    2007-11-28 18:22:57 (8b0900a3): Rescanning database
    2007-11-28 18:22:57 (8b0900a3): iconv error: unknown (0)
    2007-11-28 18:22:57 (8b0900a3): Starting playlist scan
    2007-11-28 18:22:57 (8b0900a3): Updating playlists
    2007-11-28 18:22:57 (8b0900a3): Scanned 0 songs (was 0) in 0 seconds

    I have uninstalled/reinstalled, tried rolling back to previous nightly… nothing: The folder is “scanned” in an instant and nothing is found; I have about 60.000 music files.

    Other than that: I am running Firefly on a Vista PC (Home Premium, Spanish language version). Media is stored in a different, fixed, HD in the same PC (Firefly server is in C:, media files in M:). … but that has been so for a long time, and everything worked.

    Am I missing something?

    Thanks in advance and greetings from sunny Madrid,
    -Enrique

    #14876
    Anonymous
    Inactive

    It’s working now.

    In Spanish/Windows, the default music folder is [……Mi Música], and for some reason that “ú” is not being taken correctly. Apparently everything goes fine when selecting “Mi Música” during install, and “Mi Música” is listed OK in the configuration app (… in a first stage). But not in the web interface page, where the “ú” is replaced by a funny character. When I corrected the “media folder” path using the web interface and restarted the server a full scan started.

    However, there seems to be a problem somewhere, as the way the path is listed in the (icn tray) configuration app *and* the way it appears in the web page are different and inconsistent; it might have to do with my system’s configuration (?) or with the way extended characters are handled by Firefly’s installer and/or server (?).

    Also, and what’s worse, there is a big “unstability” in this respect: the way “Mi Música” is transcribed seems to change within a few minutes, as if some of the entries were revised or retouched by the dark forces of the system, and when that happens the server freezes or refuses to start or finds no files in the scan – until the folder name is (again) manually corrected.

    In short: I’ve done some testing, and having the “ú” in the media path makes the server very unstable. Actually, when I’ve changed that path from “M:Mi Música” to just “M:” nightly-1696 scans, and works, fine; that has been my “final solution” to the problem, at least for now.

    I must add that I have not changed the paths or folder names for many months, and that those problems did not appear before now. It is true that the accented characters in path name appeared somewhat “distorted” when seen in the web interface, but everything worked. Not now.

    Sorry again for my crappy desription and crappier English, but I hope this helps others.

    Best from Spain,
    -Enrique

    #14877
    rpedde
    Participant

    @enriquep wrote:

    It’s working now.

    In Spanish/Windows, the default music folder is [……Mi Música], and for some reason that “ú” is not being taken correctly. Apparently everything goes fine when selecting “Mi Música” during install, and “Mi Música” is listed OK in the configuration app (… in a first stage). But not in the web interface page, where the “ú” is replaced by a funny character. When I corrected the “media folder” path using the web interface and restarted the server a full scan started.

    However, there seems to be a problem somewhere, as the way the path is listed in the (icn tray) configuration app *and* the way it appears in the web page are different and inconsistent; it might have to do with my system’s configuration (?) or with the way extended characters are handled by Firefly’s installer and/or server (?).

    Also, and what’s worse, there is a big “unstability” in this respect: the way “Mi Música” is transcribed seems to change within a few minutes, as if some of the entries were revised or retouched by the dark forces of the system, and when that happens the server freezes or refuses to start or finds no files in the scan – until the folder name is (again) manually corrected.

    In short: I’ve done some testing, and having the “ú” in the media path makes the server very unstable. Actually, when I’ve changed that path from “M:Mi Música” to just “M:” nightly-1696 scans, and works, fine; that has been my “final solution” to the problem, at least for now.

    I must add that I have not changed the paths or folder names for many months, and that those problems did not appear before now. It is true that the accented characters in path name appeared somewhat “distorted” when seen in the web interface, but everything worked. Not now.

    Sorry again for my crappy desription and crappier English, but I hope this helps others.

    Best from Spain,
    -Enrique

    This is it:

    2007-11-28 18:12:52 (8b0900a3): iconv error: unknown (0)

    I changed some of the code that was home-rolled for changing codepage formats to iconv, since that should allow for better flexibility with codepage changes.

    Clearly something broke, though.

    If you wanted to email me at [email protected], I could let you know when I think I have something on that. It’s hard for me to test internationalization, as there are lots of points of breakage, and my machine isn’t very internationalized. :/

    So if you wanted to help work through those issues, it would be very helpful to me.

    — Ron

    #14878
    Anonymous
    Inactive

    @rpedde wrote:

    This is it:

    2007-11-28 18:12:52 (8b0900a3): iconv error: unknown (0)

    I changed some of the code that was home-rolled for changing codepage formats to iconv, since that should allow for better flexibility with codepage changes.

    Clearly something broke, though.

    If you wanted to email me at [email protected], I could let you know when I think I have something on that. It’s hard for me to test internationalization, as there are lots of points of breakage, and my machine isn’t very internationalized. :/

    So if you wanted to help work through those issues, it would be very helpful to me.

    Ron,

    Thanks for your time.

    I am relatively used to problems caused by extended characters in some programs (in Spanish we frequently use á, é, í, ó & ú – and occasionally ü or the uppercase versions of all these. Apart from “ñ” as in “España”, of course!). That made me suspicious :roll:.

    Take into account that, in this case, the flaw is “empowered” by the fact that the default media path will contain one of these letters in all Spanish-language-Win-systems. Bad luck, and a toast to Mr. Gates.

    I’ll be glad to help in the future, and am sending you an email right now.

    Saludos desde España,
    -Enrique

    #14879
    Anonymous
    Inactive

    Any fix for this yet? Can’t try r1699 untill this is fixed (I to have a whole bunch of files with international characters, and Firefly is crashing ‘all over the place’…

    #14880
    rpedde
    Participant

    @turbo wrote:

    Any fix for this yet? Can’t try r1699 untill this is fixed (I to have a whole bunch of files with international characters, and Firefly is crashing ‘all over the place’…

    I don’t have a buildable tree yet to even work on this. I’ve got pieces of the db strewn all over the place, and everything is pretty much completely gutted.

    I’m hoping I remember how all the source code goes back together, or it’ll never work again.

    :/

    — Ron

    #14881
    Anonymous
    Inactive

    @turbo wrote:

    I have a whole bunch of files with international characters, and Firefly is crashing ‘all over the place’…

    Turbo,

    Also I have many, many files with int’l characters in their names (and in their tags), and in my case 1699 seems to work OK – as long as none of those characters are present in the selected media path.

    Just my experience, in any case.

    Best from Madrid,
    -Enrique

    #14882
    Anonymous
    Inactive

    @enriquep wrote:

    Also I have many, many files with int’l characters in their names (and in their tags), and in my case 1699 seems to work OK – as long as none of those characters are present in the selected media path.

    I couldn’t get r1699 to create the DB (sqlite3). Looking at the code, it seems like a lot of the stuff have been removed. Using sqlite instead, didn’t work either… I downgraded to r1696 instead. That works much better…

    #14883
    rpedde
    Participant

    @turbo wrote:

    @enriquep wrote:

    Also I have many, many files with int’l characters in their names (and in their tags), and in my case 1699 seems to work OK – as long as none of those characters are present in the selected media path.

    I couldn’t get r1699 to create the DB (sqlite3). Looking at the code, it seems like a lot of the stuff have been removed. Using sqlite instead, didn’t work either… I downgraded to r1696 instead. That works much better…

    I think he meant 1696. SVN is completely broken right now. I’ve only just now got itunes working against the new db backend, and that with sqlite2 only, and no query/browse support.

    On the other hand, I’ve written a couple thousand lines of code without being able to test is from an actual media player, so now that it’s working against a real media player, I ought to be able to move faster now.

    — Ron

    #14884
    Anonymous
    Inactive

    @rpedde wrote:

    I think he meant 1696.

    Right, sorry. I was a little confused jsut around the time when I started to use SVN version(s) and didn’t notice that part… I got a SVN version checked out, and that crashed about the time it noticed a file with international characters, so I jumped the gun and assumed it was the same problem. I later noticed that it was something else (can’t remember what now).
    @rpedde wrote:

    On the other hand, I’ve written a couple thousand lines of code without being able to test is from an actual media player, so now that it’s working against a real media player, I ought to be able to move faster now.

    Nice! So given a couple of days, we’ll get a much improved Firefly with more functionality to test? Oh, what joy (really! :)!
    Just commit what you have (with a WARNING file) so we can test/help. I get payed to work on this, so… 🙂

    #14885
    rpedde
    Participant

    @turbo wrote:

    @rpedde wrote:

    I think he meant 1696.

    Right, sorry. I was a little confused jsut around the time when I started to use SVN version(s) and didn’t notice that part… I got a SVN version checked out, and that crashed about the time it noticed a file with international characters, so I jumped the gun and assumed it was the same problem. I later noticed that it was something else (can’t remember what now).
    @rpedde wrote:

    On the other hand, I’ve written a couple thousand lines of code without being able to test is from an actual media player, so now that it’s working against a real media player, I ought to be able to move faster now.

    Nice! So given a couple of days, we’ll get a much improved Firefly with more functionality to test? Oh, what joy (really! :)!
    Just commit what you have (with a WARNING file) so we can test/help. I get payed to work on this, so… 🙂

    it’s committed, and compiles right now, at least on mac. Probably will compile on linux. probably not on windows or *bsd or solaris.

    at a first pass it won’t do anything it didn’t do before. only possibly slower or buggier.

    I hope to speed it up to the point that it’s faster than the current db, and this setup should let me do neater things, like the “top n” queries, and queries with specific sorting, and properly sorting band names with “The”.

    That sort of thing.

    — Ron

    #14886
    HellerMD98
    Participant

    This may be a bit premature but what is mt-daapd’s support for phonetic characters?

    We are using it in our Language Lab and have entered the characters using iTunes on a Mac. This is with build 1586 as we couldn’t get a new version to run (Mac OS X 10.5.1 client).

    The characters look fine on the Mac with the iTunes library, but either don’t show up on a client to mt-daapd (iTunes from another computer) or for the ones that have accents over the phonetic character, they show up as two characters. I don’t mean é or ö but rather phonetic characters like É™ or Éœ. (For more examples, some HTML phonetic entities can be seen at http://tlt.its.psu.edu/suggestions/international/bylanguage/ipachart.html)

    Thanks in advance for any suggestions!

    #14887
    rpedde
    Participant

    @HellerMD98 wrote:

    This may be a bit premature but what is mt-daapd’s support for phonetic characters?

    We are using it in our Language Lab and have entered the characters using iTunes on a Mac. This is with build 1586 as we couldn’t get a new version to run (Mac OS X 10.5.1 client).

    The characters look fine on the Mac with the iTunes library, but either don’t show up on a client to mt-daapd (iTunes from another computer) or for the ones that have accents over the phonetic character, they show up as two characters. I don’t mean é or ö but rather phonetic characters like É™ or Éœ. (For more examples, some HTML phonetic entities can be seen at http://tlt.its.psu.edu/suggestions/international/bylanguage/ipachart.html)

    Thanks in advance for any suggestions!

    It should work fine… iTunes should save them as UTF-8, which mt-daapd shouldn’t have a problem reading at all. There are some problems (as mentioned) with non-latin1 codepage characters in file systems that aren’t utf-8, but that shouldn’t affect a mac at all.

    Should just work. Is it possible that the remote machines don’t have a font that will display those characters?

    Do you have an example mp3 that you could mail me at [email protected]?

    — Ron

    #14888
    HellerMD98
    Participant

    Thanks Ron! As requested, I’ve shared an MP3 with you via email. Thanks for all your hard work on mt-daapd!!

Viewing 14 posts - 1 through 14 (of 14 total)
  • The forum ‘Nightlies Feedback’ is closed to new topics and replies.