Jump to content

carmen

Members
  • Posts

    2
  • Joined

  • Last visited

Everything posted by carmen

  1. Here are some additional thoughts: 1-I "solved" the problem temporarily by creating another account under XP (pro version, don't know if it makes a difference), and running JUST this app there. (I.e., running just the jar and the firefox localhost page, no other programs, no other tabs/windows in firefox.) It gets its own temp dir and the "recent"-checking code should be OK there. The app continues to run even after switching back to another account. 2-I suspect that the reason the "recent" code was created was to speed up the search of the TEMP directory. I thought that shouldn't be too much of a problem. I looked at my TEMP directory and found almost 1000 files there. Even that many may not be much of a problem, I don't know the timings involved. But, it was very easy to delete most of the files there without affecting anything, reducing any potential problem. So, people might take a look at their TEMP directories and clean things up. 3-The orginal joinMp3s() might be OK with a slightly different isFileRecent() function. Instead of: private static boolean isFileRecent(File file) { Date now = new Date(); Calendar calendar = Calendar.getInstance(); calendar.setTime(new Date(file.lastModified())); calendar.add(Calendar.HOUR, 3); return now.before(calendar.getTime()); } How about something like: private static boolean isFileRecent(File file) { static Calendar calendar_to_compare = NULL; static Calendar calendar_this_file = Calendar.getInstance(); boolean bool_return_value = TRUE; if ( calendar_to_compare == NULL ){ calendar_to_compare = Calendar.getInstance(); calendar_to_compare.add(Calendar.HOUR, -1); } else { calendar_this_file.setTime(new Date(file.lastModified())); bool_return_value = ( date_to_compare.compareTo(calendar_this_file) < 0 ); } return bool_return_value; } (My java's probably not correct, but hopefully you get the idea.) This will "break" if Pandora ever starts up and waits over an hour to create the plugtmp directory, but should limit the number of files inspected.
  2. Here's a bug (I think) for someone to look into. In Mp3Processor.java, in function joinMp3s, the accumulated file array might be wrong. The "for" loop exits with a 'LOG.debug("no more mp3 found in dir"); return;' when a non-directory, non-mp3, non-recent file is found. If that happens before the plugtmp (or plugtmp-x) directory is processed in the "for" loop, the function doesn't recurse and process that directory. That can be seen in the log file output when the same file is saved multiple times with the wrong filename and tagging. The determination of "non-recent" is in isFileRecent, where it appears that "recent" is within 3 hours. When you delete the plugtmp (and/or plugtmp-x) directory and start clean, you can see the problem happen 3 hours into the running of the program. Until fixed, I think stopping the program, cleaning up, restarting, should eliminate that problem. Comments? Am I all wet?
×
×
  • Create New...