Loading ...
Sorry, an error occurred while loading the content.

19974Re: filenames containing international charaters

Expand Messages
  • ivar.hamrin
    Oct 19, 2007
    • 0 Attachment
      --- In nslu2-linux@yahoogroups.com, "ralphqramden" <ralphqramden@...>


      > I *do* believe that the problem is a Windows problem. You might like
      > to see my
      > post in the forum for Reciva based wifi radios at:
      >https://www.reciva.com/index.php?option=com_joomlaboard&Itemid=77&func=view&id=8648&catid=3#msg8648

      Will do that seriously. Had a look but realized that it will take me a
      while to understand ;-)

      > Basically I think (at least I can't find a way) to tell Window$ to
      > automatically
      > default to UTF-8, which is the Linux standard, even though it
      > understands it. It
      > will always stick with ISO 8859-1 *until* it finds a character that
      > doesn't
      > overlap with UTF-8 like å and ø. Only then will it fall over to UTF-8.

      I'll give it a go. However, since both mine and my girlfriends
      computers are ment to be connected to the slug (and to the rest of the
      world which is, against the best of knowledge, Windows based)the most
      logical way to solve this is to make an effort to correct the faulty
      link the the chain, in this case the Slug. If I tell my XP machine to
      default to UTF-8, the char's will be correctly decoded on it. But not
      on the other one except if I do the same thing of that one. What will
      the happend when I (or my girlfriend) connect to fx. a ftp server,
      will char's be coruppted again?

      >
      > Now my problem with GTKpod was easily solved by telling it (and samba)
      > to work
      > in ISO 8859-1. However, I couldn't tell my Linux based Reciva radio to
      > "work" in
      > ISO 8859-1 just as we can't seem to tell a slug to do the same thing
      > without
      > moving off away from uNSLUng. Sorry to say I ended up going through my
      > 5000 odd
      > MP3's and removing all offending diacritics and other characters.

      Sounds like a huge job going through all mp3's! Will not undertake
      that one until I absolutely have to. But I still think there's a way
      to make the Slug work in ISO-8859-1. There is char code kernel file
      available cp850 (West Europe/Latin 1), why could'nt there be one for
      iso-8859-1? Perhaps just a matter of cross comipling? I don't know
      yet, but I'll try to find out. The SoundBridge use to be connected
      directly to the Windows machines using another server (in that case
      Firebird) and all the chars looked ok. So in my case the only issue is
      the Slug. In your case the Reciva must have been another separate
      problem, perhaps unsolveable.

      > If you could get all the files renamed on a Linux box and *then* put
      > them on the
      > *native* slug disk, that might do the trick.

      Yes, certainly. But the problem will still persist: since new files
      will be added in the feature, and that from the Win machines, the only
      way is to make them default to UTF-8 or cp850. Which in return will
      make it hard to copy files from someone elses computer than ours. In
      that case, we'll have to "recode" all filenamnes. Still, it seems like
      the only logical solution is to make the Slug talk iso-8859-1, or am I
      wrong?

      >I want those characters
      > too, so I
      > will be working on it.

      Me too. Let's stay in touch and keep this discussion alive. Perhaps in
      another thread? The problem can't be limited to filenames of mp3's,
      there's got to be more people interested in solving this issue!

      > Any other thoughts from anyone?

      In that case, please respond! Still unable to sleep! ;-)


      > And perhaps since you mentioned it you might tell me how you make
      >out with Mediatomb. I have trouble with it telling me the
      >mediatomb.db file is corrupted on restart. It works fine for me when
      >I start it and use it, but once it is shutdown and restarted it says
      >the database is corrupted (which I have confirmed with
      >"sqlite3_analyzer.exe". I changed emails with one of the authors and
      >he feels that perhaps the .db file is getting saved in 'flash' which
      >is a problem. He thought perhaps moving it to a mounted disk
      >location, perhaps in with the music files might fix it, but I haven't
      >tried yet. Sorry for the length of this post, and if you care to talk
      >about Mediatomb, perhaps begin another thread?

      No problem talking about MediaTomb, seems like a very good piece of
      software once you figure out how to script it, not as easy as it
      seems, not to me anyway ;-) But I'm shure there's another forum
      specific for it.

      Have'nt had the time to dig deeper in to it yet, and I'm not shure
      that I'll be able to give you a good answer. You should try out that
      solution. But, correct me if I'm wrong, if there's no db file, won't
      sqlite build a new one? I think so. In that case, simply delete the
      file and in that way force it to do so. Might work. Otherwise,
      reinstall all of MediaTomb. I'm quite shure you have a reason for your
      choice of a flash disk, and I'll probably be your last and least
      wanted option to move it to another disk.

      //Ivar
    • Show all 6 messages in this topic