Nice job!

2005-03-08
2013-04-17
  • I like being able to easily use basic file transfer capability without booting into windows, thanks for this effort!

    I have noticed a couple annoying bugs that I didn't see mentioned anywhere. When I select multiple folders of files and drag them to  copy them to my ifp-799, click "Yes to all" to confirm, it does copy all the folders but also creates a duplicate of each file in the parent directory I dragged to. The last directory copied doesn't have duplicates.

    To word it another way:
    If I copy a single folder at a time, it works fine. If I copy 2 folders, the first one has it's contents repeated one directory level up. If I copy 3 folders, the first 2 have their contents repeated, and so on.

    The other bug is with long filenames. If filenames are over a certain length, ifp-gui pegs the CPU and effectively freezes and I have to kill it. The file it was about to copy exists on the player with zero length. If I delete that and rename the source file to be shorter it works fine. This is 100% repeatable on long filenames but I haven't taken the time to find out exactly how many characters are too many.

    Thanks again, and I hope you will continue to develop ifp-gui!

     
    • Jim Campbell
      Jim Campbell
      2005-03-10

      Thank you

      I will get these bugs fixed.

      Long file names:
      The maximum length for the filename is 128 characters
      The maximum length for the file path is about 128 characters.  The path is the directory on the iFP device not including the filename (for example "\music\artist\album\")

      --
      Jim

       
    • First of all thank you for this easy way to use my iRiver with Linux.

      About the "long" filenames: It seems that eg.

      //Rage Against The Machine - Rage Against The Machine (1992)/02 - Rage Against The Machine - Killing In The Name.mp3

      is already to long and causes ifp_gui to freeze.

      Furthermore it would be great if you could add support for letters like , , ,  ...

       
    • I've done some debugging and I know why the crash is happening with long file names (names much less than the 128 limit)

      The cause seems to be in progressdlg.cpp, in either setFileName or truncateFileString (I didn't identify the exact line).

      If a filename is long enough that even with removing all the extra path and "\" characters it still doesn't fit within the dialog space, it seems to go into an infinite loop.

      simply changing setFileName to be only
        lblFilename->setText(fileName);
      fixes the problem, although the progress dialog has text in it that is too long and looks ugly.