I tried to use the “Unknown Tag” feature to remove the non-compliant NCON tag from my old MusicMatch-tagged mp3 tracks, which I have in a single folder.
When I “Saved changes”, Jaikoz reported that it was unable to load a bunch of files.
Well, in fact, it had deleted half dozen random files, and then renamed others to the names of the deleted files. Then it reported being unable to load the files it renamed (it could no longer find the original-named files).
I can understand your disappointment, but I have never seen this behaviour myself despite comprehensive testing.
There must be some sort of problem , but it may not be exactly as you describe. For example you mention that some files are deleted, but don’t mention that you marked any files for deleted. I am sure no files would be deleted unless you marked them for deletion so I would be very grateful if you could send me your log files so that i can investigate on the behalf of my other users as well as yourself.
To be clear, I marked nothing for deletion. I was testing one specific function … locating and deleting “Unknown” tags – specifically the NCON tag that an old version of MusicMatch (8.x Jukebox Pro) added to many of my tracks.
Before deleting these unknown tags, I played around with columns, and sorting by various columns ascend/desc. I hid display of most columns except a few like Status, Version, Artist, Title, Art, Unknown. Possible a few others. I sorted by each remaining col at least a few times, before starting to delete the unknown NCON tags.
Here’s the log that resulted:
error log
Once I noticed these “severe” errors and the impact they were having on my test folder (started with 173 tracks, mixed artists & albums, which dwindled to 164 or so, with random tracks taking on the filename – but not the tags – of files that went missing), I deleted Jaikoz from my system.
To Jaikoz’s credit, I’ve reinstalled today to attempt to reproduce this behavior. I am completely unable to reproduce this behavior … even on the exact same folder/files which I restored yesterday from backup. I’ve been trying for 2 days to reproduce the behavior from a couple days ago. I am unable.
So, at most this seems to be a rare unknown failure. Hopefully you’ll pick something up from that log.
Hi, thanks for the error log (jaikozdebug0-0.log0 but could I also have the jaikozuser0-0.log as well.
This shows the problems happening early on the 16th … an unrecognizable .mp3 file. That may have triggered the subsequent problems. If you’d like to have this file, please let me know how to transfer. It also shows my subsequent (unsuccessful) attempts to reproduce the errors.
It actually seems that the “Add File” function may have a problem, which may have kicked off my other problems. This file reported as unrecognizable, is in fact a valid mp3 (at least according to winamp, dbpoweramp, helium mm & similar). It could be that just about any mp3 will cause this error on Add File.
Yes , I noticed the substring problem, it may/not be related, but it would be useful if you could send me the breeders song. Just email it to support at jthink.net.
[quote=Anonymous]
It actually seems that the “Add File” function may have a problem, which may have kicked off my other problems. This file reported as unrecognizable, is in fact a valid mp3 (at least according to winamp, dbpoweramp, helium mm & similar). [/quote]
This problem has been fixed, in Jaikoz 1.6 released today 
Ive checked the code but have not been able to find a cause of this problem
From the log this is what seems to have happened:
Loaded 176 files, made some modification and then elected to save changes, four files were saved without any errors issued. Then some more changes made including changes to the files that had just been saved, and save was performed again. When saving Jaikoz reopens the corresponding file on the filesystem and then save its with the new changes, but it was unable to find the files that had previously been saved, however it did save 8 more files that had been modified. Then another attempt was made to save changes and this time it was unable to find any of the 12 files that had been saved.
Files are not being deleted randomly, but it appears that in this case the files are disappearing despite the fact that Jaikoz make no attempt to delete any files, Delete is only called in one circumstance when the user has marked a file for deletion but there is no evidence of this from the logs.
I dont quite understand this line, you seem to be saying the files do not exist, but have been replaced by others files with the same name:how do you know that isnt the original file.
I am making some changes so that additional information is added to the log files and console but I am at a complete loss to how this has happened. I can simulate the error by saving the files in Jaikoz, then externally using File Explorer on another application removing the files from the folder then if I tried to save the changes again the error you describe would occur. Now Im sure you didnt fo this interactively, but can you think of any application that might be automtically doing something to files once they have been updated ?
I dont quite understand this line, you seem to be saying the files do not exist, but have been replaced by others files with the same name:how do you know that isnt the original file.[/quote]
Years ago, I ripped/tagged using MusicMatch Jukebox Pro (before Yahoo! moved in). Now I rip with dbPowerAmp & tag with Helium Music Match.
The problem is, HMM doesn’t allow quick deletion of non-standard IDv2.x tags like MMJBP’s NCON tag. So I wanted to use Jaikoz to quickly delete these bogus tag elements.
My point is, any track can be identified by 3 sources, all of which were perfectly in sync before I tested Jaikoz: filename, tag elements, and encoded track; file “Song A.mp3” had tags for “Song A” and sounded like “Song A” when I played it. I’ve confirmed this with dbPA and HMM.
After testing Jaikoz, however, and losing some files, I checked tags through HMM. That’s when I noticed the filename “Song A.mp3” suddenly had the tags for “Song B” and sounded like “Song B” when I played it. In fact, “Song A” had disappeared and in it’s filename place, I have “Song B” renamed to “Song A.mp3”.
10 files disappeared. 10 of those that remained now had the wrong filename (although the contents were still healthy). Continuing the example above, the real “Song A.mp3” disappeared, replaced with “Song B” with the filename of “Song A.mp3”. I used HMM to restore the 10 renamed files to their correct name (renamed them based on the correct tag info – “correct” because the tags still matched the sound, although Jaikoz had moved them to “Song A.mp3”).
===
I’m still trying to reproduce my original error. I do notice strange, but different behavior if I try to load a large folder (176 files), but then click the “Finish” button while it’s still loading. I do remember clicking this button, almost certainly at the wrong time, during my first test. Really I think this button should say “Cancel” rather than imply something more like “OK, Jaikoz has finished loading; User can click here to continue”.
I still can’t reproduce the prior bad behavior, but clicking “Finish” while Jaikoz is still loading leaves the app in a weird state. For example, if I Close Files and then try to immediately reload the same folder with 176 tracks after interrupting the first folder load, it refuses, saying some of the same files are already loaded – even though I did “Close files” between loads, and the bottom status bar reported “0 files loaded” after I Closed Files.
I think things are wrong with the load, close, “Finish” routines. A simple test like I’ve tried to report above leaves the app in an invalid state. That could have resulted in this mishandling of file contents and file names.
I hope that helps.
[quote=Anonymous]
I still can’t reproduce the prior bad behavior, but clicking “Finish” while Jaikoz is still loading leaves the app in a weird state. For example, if I Close Files and then try to immediately reload the same folder with 176 tracks after interrupting the first folder load, it refuses, saying some of the same files are already loaded – even though I did “Close files” between loads, and the bottom status bar reported “0 files loaded” after I Closed Files.
I think things are wrong with the load, close, “Finish” routines. A simple test like I’ve tried to report above leaves the app in an invalid state. That could have resulted in this mishandling of file contents and file names.
I hope that helps.[/quote]
Thanks, I will review the Finish code maybe something is not being initilized properly, although I cant see the error so far.
There does seem to be bug with Close Files whereby files that are closed are not removed from the list of open folders used by ‘Add Files’ and ‘Add Folders’, I think this must be the problem you encountered. You wouldnt have hit the problem if you had reopened the files using the ‘Open Folder’ button, Ill get this fixed though this in itself wouldnt cause the invalid state.
I note you’ve added a review to download.com, maybe you would consider toning it down a little - it seems rather harsh.
Agreed. I’ve requested deletion; that’s the only option as editing isn’t possible (?!?). I’ll add a new review once the latest version of Jaikoz is on dowload.com.
I have found a problem which can occur in rare circumstances.
If you ‘open some files’, then ‘close files’ then ‘add files/add folder’ and then immediately save changes to some files without closing any first, there is a possibility that data could be written to the wrong file, I am working on a fix that should be released today.
This problem can only occur if you have done the above combination of open/close/add/save, even then it is unlikely to occur. It will not happen in any other circumstance, no files are actually deleted if this happens.
This release (1.6.1) is now available for download