Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Cannot Reproduce
    • Affects Version/s: current
    • Fix Version/s: 2.2.0
    • Component/s: mp3
    • Labels:
      None
    • Environment:

      Operating System: Linux
      Platform: PC

    • Issuezilla Id:
      278

      Description

      Environnment : Linux (Ubuntu 8.04) / intel / JRE build 1.6.0_10-beta-b25

      In some rare cases, the audiofiles are truncated after a commit(). I managed to
      reproduce this few times (this is not always reproductable) in following
      conditions :

      • Access to a remote mp3 file located on a SMB NAS service thought wifi
      • MP3 without any tag
      • Tag creation + tag filled up with all available data (genre, )

      My code was :
      AudioFile audioFile = AudioFileIO
      .read(new File(
      "/media/nas/01.mp3"));
      Tag tag = audioFile.getTag();
      if (tag == null)

      { tag = audioFile.getTagOrCreateAndSetDefault(); }

      tag.setAlbum("Foo");
      tag.setArtist("Bar");
      tag.setGenre("a genre");
      tag.setYear("2000");
      tag.setTrack("1");

      audioFile.commit();

      As a result, see the provided sample file.

      After some searches, I may have a clue : RandomAccessFile are instanciated in
      "rw" mode. So my feeling is that in very seldom conditions, the temporary file
      may not be actually flushed before being renamed to the final file. I changed
      all occurences of new RandomAccessFile(..,"rw") to new
      RandomAccessFile(..,"rws") to force synchronous writing of tags.

      What do you think about it ?

      I'll continue testing but for now, I didn't observed the problem (of course,
      I'll keep you in touch if I reproduce this again despite my patch).

      1. 01.mp3
        0.1 kB
        bflorat
      2. 01.mp3
        0.1 kB
        bflorat

        Activity

        Hide
        elstensoftware added a comment -

        I've been looking at this from a different angle: performance. I was running some profiling on FLACs and the calls to RAF.write appear to be amongst the more expensive calls.

        Pertinent to this bug, given a temp file is being written to, is it not enough to open as "rw" and upon close() the bytes will have been written?

        I also say that because according to the javadocs, "rws" won't guarantee writes on network storage anyway:

        The "rws" and "rwd" modes work much like the force(boolean) method of the FileChannel class, passing arguments of true and false, respectively, except that they always apply to every I/O operation and are therefore often more efficient. If the file resides on a local storage device then when an invocation of a method of this class returns it is guaranteed that all changes made to the file by that invocation will have been written to that device. This is useful for ensuring that critical information is not lost in the event of a system crash. If the file does not reside on a local device then no such guarantee is made.

        http://docs.oracle.com/javase/6/docs/api/java/io/RandomAccessFile.html#RandomAccessFile(java.io.File, java.lang.String)

        Show
        elstensoftware added a comment - I've been looking at this from a different angle: performance. I was running some profiling on FLACs and the calls to RAF.write appear to be amongst the more expensive calls. Pertinent to this bug, given a temp file is being written to, is it not enough to open as "rw" and upon close() the bytes will have been written? I also say that because according to the javadocs, "rws" won't guarantee writes on network storage anyway: The "rws" and "rwd" modes work much like the force(boolean) method of the FileChannel class, passing arguments of true and false, respectively, except that they always apply to every I/O operation and are therefore often more efficient. If the file resides on a local storage device then when an invocation of a method of this class returns it is guaranteed that all changes made to the file by that invocation will have been written to that device. This is useful for ensuring that critical information is not lost in the event of a system crash. If the file does not reside on a local device then no such guarantee is made. http://docs.oracle.com/javase/6/docs/api/java/io/RandomAccessFile.html#RandomAccessFile(java.io.File, java.lang.String)
        Hide
        paultaylor added a comment -

        Seeing as this change didnt fix the problem anyway, and both yourself and http://www.jthink.net/jaikozforum/posts/list/7060.page have reported performance issues Ive reverted this chnage.

        Show
        paultaylor added a comment - Seeing as this change didnt fix the problem anyway, and both yourself and http://www.jthink.net/jaikozforum/posts/list/7060.page have reported performance issues Ive reverted this chnage.
        Hide
        paultaylor added a comment -

        Fixed

        Show
        paultaylor added a comment - Fixed
        Hide
        paultaylor added a comment -

        reopened for further testing to try and identify original issue.

        Show
        paultaylor added a comment - reopened for further testing to try and identify original issue.
        Hide
        paultaylor added a comment -

        Unable to Reproduce

        Show
        paultaylor added a comment - Unable to Reproduce

          People

          • Assignee:
            paultaylor
            Reporter:
            bflorat
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: